From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Notmuch Mail <notmuch@notmuchmail.org>
Subject: Re: [PATCH] test thread breakage when messages are removed and
 re-added
In-Reply-To: <1459445693-3900-1-git-send-email-dkg@fifthhorseman.net>
References: <1459445693-3900-1-git-send-email-dkg@fifthhorseman.net>
User-Agent: Notmuch/0.21+74~gb409435 (http://notmuchmail.org) Emacs/24.5.1
 (x86_64-pc-linux-gnu)
Date: Fri, 01 Apr 2016 19:27:03 -0300
Message-ID: <8737r5dky0.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
 micalg=pgp-sha512; protocol="application/pgp-signature"
Precedence: list

--=-=-=
Content-Type: text/plain

On Thu 2016-03-31 14:34:53 -0300, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
> ghost-on-removal
> ----------------
>
> We could unilaterally add a ghost upon message removal.  This has a
> few disadvantages: the message index would leak information about what
> messages the user has ever been exposed to, and we also create a
> perpetually-growing dataset -- the ghosts can never be removed.
>
> ghost-on-removal-when-shared-thread-exists
> ------------------------------------------
>
> We could add a ghost upon message removal iff there are other
> non-ghost messages with the same thread ID.
>
> We'd also need to remove all ghost messages that share a thread when
> the last non-ghost message in that thread is removed.
>
> This still has a bit of information leakage, though: the message index
> would reveal that i've seen a newer message in a thread, even if i had
> deleted it from my message store

One more proposal along these lines:

track-non-ghost-count-per-thread
--------------------------------

If each thread had a count of all the non-ghost messages associated with
it, and that count was properly maintained by the database, then upon
message deletion you would decrement the count.  when that count reached
zero, you could destroy the thread.

This has the same metadata leakage as
ghost-on-removal-when-shared-thread-exists, but i think it might be more
efficient, if we can cope with the denormalized database.

This does have the downside of needing a database transition, though:
we'd have to add this count to all threads in a database upgrade.



What do people think of the different options?  what do you prefer?  is
there some better approach that i've missed?

     --dkg

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQJ8BAEBCgBmBQJW/vW3XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFREIyRTc0RjU2RkNGMkI2NzI5N0I3MzUy
NEVDRkY1QUZGNjgzNzBBAAoJECTs/1r/aDcKBFwP/3fiBCcA2W5KWe4R02JtO7qg
IuekGdsb95+HfauCrfdY5QQgSRmd6uIMniJkyZ9Zj4ccKEjPLDJ3nqn2M2xBHOzM
4j0b4CHmnhDZkNZAKgQCBjMMJVJ1qm4tTV380p1GOyChvQdxEHAelM3tT18rK/22
ynmBJ8bCzMJ4RjG1rfLWqc9DA78AZCVxPj2Ikc+jKBRFc6UvdtOq5/dCgkykOfTV
lXFvO1BWwkH/6E9xijg7bl6sMGUsJzdLq0Jc5pTRYCyAMMv5DQlj1JllvQAXKYCO
9v8ZVYCOPHrCF4BMrBldmOhK+aghbzYYzhLG77PKqwr0l2XsOtvwwD6A1L4Lo26O
vCY8sZUVWfzzL7hnvRaJhLxCiiTObjhN8GtpG/QpsQmOLw7uxbtIWx8OnDRmdQMJ
pWjjNyDFdvbw/3fogUoGpUHxB28cyDQ/rvASNDgE1pOQWkD1BM7fMShcc7F0g+tn
mpxpmmawFqrWA1pYiral/NL6MyPSIGWLZNfL0fYJbgX0aKB2Dpl4l+Pa4ZmbIxX1
bKkMahrQdoTPZOD4LmUov2aRSl4vMXjnJIlaHRqX70xk/E/dpkRA64XMNSAKtaCt
h5kYUNF4XnUUsEiknZYALCZfPmbMNfLw8GTJ+lGjEJRfGUBqBmh884SEcAklpOxi
JGbYC7K7Dr/IY75zMVMj
=TWtC
-----END PGP SIGNATURE-----
--=-=-=--