[tahoe-lafs-trac-stream] [Tahoe-LAFS] #795: add-only sets

[Tahoe-LAFS]

#795: add-only sets
------------------------------+-----------------------------------------
     Reporter:  warner        |      Owner:
         Type:  enhancement   |     Status:  new
     Priority:  major         |  Milestone:  undecided
    Component:  code-mutable  |    Version:  1.5.0
   Resolution:                |   Keywords:  newcaps revocation research
Launchpad Bug:                |
------------------------------+-----------------------------------------

Comment (by nejucomo):

 We're chatting about use cases during Tesla Coils & Corpses.  These use
 cases imply slightly different semantics and I imply this by the
 capability names in environment variables:

 #. **syslog case**

     * install tahoe, then run `tahoe syslog-collector $APPEND_ONLY_CAP`
     * elsewhere someone can do `tahoe get-records $READ_RECORD_CAP` (-note
 this is not a byte-oriented read.)
     * Even when the syslog host is compromised, the attacker cannot remove
 "sufficiently" written records.

 #. **backup case**

     * `tahoe backup` - Similar to syslog, except the records refer to
 immutable directories.  Also, maybe ordering is less important?

 #. **drop inbox**

     * A directory-like thing where multiple writers may add new entries,
 but never overwrite entries.
     * For example, the names are universally unique opaque identifiers
 which fit into users' notions of filesystem names so they can "naturally"
 do things like `ls`, `tar`, `cp` etc...
     * This could be used to have a grid-wide publication capability
 distributed next to the introducer furl.  (This ignores storage accounting
 issues.)

 (I've missed many spoken use cases while writing this.)

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/795#comment:15>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage