[tahoe-dev] Deletion in the Elk Point cap protocol

[Zooko O'Whielacronx]

I think there are too many possible features, with associated costs
and interactions, for most of us (with the possible exception of
Brian) to keep track of.  Let's update
http://allmydata.org/trac/tahoe/wiki/NewCapDesign to list all features
that we would want if we could afford them, and link to discussions
such as this one about how it could be implemented and what it would
cost in complexity.

By the way, something that I want which is closely related to this
"Deletion" feature but which is *not* this Deletion feature is
Revocation of Further Writes:

http://allmydata.org/pipermail/tahoe-dev/2009-June/001995.html

Revocation of Further Writes is something that I strongly want, from
my own personal experience using Tahoe-LAFS (recounted in that mailing
list post) and because I think that it could be valuable to a lot of
people.  Revocation of Further Writes is very simple from the
perspective of the cap crypto structure because it can be implemented
without any changes to the cap crypto structure!  It can be
implemented as a new layer that sits above mutable caps and below
directories.

However, Revocation of Further Writes has a potential problem from a
rollback attack, like the Deletion feature does (and like mutable caps
do in general).  Also I happen to know that the Cassandra distributed
database has a similar problem even though they don't try to account
for the malicious case: they want to make sure that servers gossiping
with one another don't accidentally resurrect a file that has been
deleted, so they have a "tombstone" protocol similar to the protocol
that David-Sarah suggested to "remember that the share at a given
storage index has been deleted".

David-Sarah: will you please add Deletion
http://allmydata.org/trac/tahoe/wiki/NewCapDesign ?

Regards,

Zooko