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 _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
