[tahoe-dev] Tahoe 'Shortcuts'

Greg Troxel gdt at ir.bbn.com
Tue Jul 2 13:54:22 UTC 2013


Mark,

I put some thoughts in the ticket.  (Perhaps tahoe-dev should get all
ticket updates?  It seems better to have the conversation in the ticket,
so it's organized, but it risks leaving out people.)

  From: "tahoe-lafs" <trac at tahoe-lafs.org>
  Subject: Re: [tahoe-lafs-trac-stream] [tahoe-lafs] #2010: Implement
          shortcuts to caps
  Cc: tahoe-lafs-trac-stream at tahoe-lafs.org
  Date: Tue, 02 Jul 2013 13:52:27 -0000 (1 minute, 4 seconds ago)
  Reply-To: tahoe-dev at tahoe-lafs.org

  #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
  _______________________________________________
  tahoe-lafs-trac-stream mailing list
  tahoe-lafs-trac-stream at tahoe-lafs.org
  https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-lafs-trac-stream



More information about the tahoe-dev mailing list