[tahoe-dev] Tahoe 'Shortcuts'

[Mark Berger]

Thanks for the comments Greg! Could you expand upon what you mean by
"predictable semantics"? I'm not sure what that entirely entails.

-Mark Berger

PS: Here are some more comments I left on the ticket.
-------------------

Comment (by markberger):

 * I agree that the feature should be at the protocol level. That was my
 original idea but I forgot to explicitly state that.
 * When I was talking about sharing, I had the idea of sharing via a
 publicly accessible gateway, similarly to how the tiddly wiki works. If a
 user is running their own client, shortcuts should be able to be used with
 the WUI, but I agree that it is not the way to share files.
 * You're right in that there are serious issues with the flat namespace.
 If accounting were implemented a user could have their own namespace for
 their respective shortcuts.

On Tue, Jul 2, 2013 at 9:54 AM, Greg Troxel <gdt at ir.bbn.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20130702/d6473d24/attachment-0001.html>