[tahoe-lafs-trac-stream] [tahoe-lafs] #2010: Implement shortcuts to caps

[tahoe-lafs]

#2010: Implement shortcuts to caps
-----------------------------+--------------------------------------------
     Reporter:  markberger   |      Owner:
         Type:  enhancement  |     Status:  new
     Priority:  normal       |  Milestone:  undecided
    Component:  code         |    Version:  1.10.0
   Resolution:               |   Keywords:  usability, newurls, introducer
Launchpad Bug:               |
-----------------------------+--------------------------------------------

Comment (by gdt):

 This is a major architectural change, to add a new namespace.  Before it
 happens, I think it needs a a complete written architectural design and
 protocol explanation.  A few concerns:

  * Absent a really good reason, the feature should be at the protocol/WAPI
 level, not at the WUI level.  I think you meant that, but I'm not sure.
  * This is basically an extension to the aliases file, with a grid-wide
 shared namespace.  So perhaps having an aliases.public that is published
 would make sense.
  * One needs to have unpublish if there is publish, probably.
  * Synchronization of aliases should have predictable semantics.  Re-fetch
 on miss does not satisfy this.
  * I think sharing by pointing at a foreign WUI is bad practice; that's a
 hack for a web server with a tahoe backend filesystem.    Sharing by a cap
 that allows the reader to find an introducer and speak the protocol is
 another matter.
  * It seems clear to me from reading your examples that there are serious
 issues with a flat namespace in a grid with multiple people.
  * The mechanism could be abused to store (small amounts) of data without
 write authorization, but perhaps that's not incrementally a bug.  Once
 there is write authorization in place, this will be a bug.

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2010#comment:1>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage