[tahoe-dev] Read only (client/gateway only) Introducer furls?

[Garonda Rodian]

Hmmm... I don't think I've been able to give a clear description.  This comment has nothing to do with actual file/directory/cap permissions, nor about storage space per client, nor even uploading data; this comment is solely relating to restricting who is allowed to offer storage/be a storage node; i.e. who is allowed to contribute space to the grid, because they can also take that space away.

While #467 does relate to what I'm thinking of here in that each client would be able to choose their own list of storage nodes to use (and, therefore, not use any nodes offered to the grid after they make their choices), #666 as I read it has no bearing on this particular scenario - I'm assuming by "brian" you mean "nejucomo"?

Perhaps an example to clarify the miscommunication and/or my misunderstanding:
Introducer (RW) furl is all we have now, so we give RWfurl to Bob, Jane, and Eve.
Bob, Jane, and Eve all contribute 4 storage nodes, for a 12 node stable grid.  All three of them have RW dircaps, and can thus upload and download both.

Alice is also given the (RW) furl so she can use the grid, and is given RO dircaps; she is not expected to contribute storage, and cannot upload due to the capabilities provided.

Alice then decides to contribute 108 nodes to the grid, which the Introducer allows.  
Alice lets them run for awhile, and as she owns 90% of the nodes on the grid, she collects at least 8 out of 10 shares of quite a few new uploads, assuming they're mostly done using 3/7/10 defaults (k=3, h=7, N=10).
Alice takes her storage nodes offline, permanently.   With it goes quite a few new uploads.

What I'm proposing is that the introducer furls also include capabilities, and thus Alice, intended to be a client only, would be given a "RO" introducer furl that does not allow her to provide storage nodes to the grid.  Bob, Jane, and Eve would have "RW" introducer furls that do allow them to contribute storage to the grid.



> Date: Sun, 29 Sep 2013 04:19:15 +0000
> From: zookog at gmail.com
> To: tahoe-dev at tahoe-lafs.org
> Subject: Re: [tahoe-dev] Read only (client/gateway only) Introducer furls?
> 
> Dear Garonda Rodian:
> 
> It sounds like you're confusing the authority to access certain
> files-and-directories (which ultimately boils down to some
> cryptographic keys and/or cryptographic identifiers) with the
> authority to upload data. The former is currently controlled by those
> caps that you named, the latter is currently controlled in a very
> limited, brittle way, which is that if you give someone the FURL to
> your introducer then they gain the authority to upload as much as they
> want to any storage server that connects to that introducer.
> 
> Fixing the problem from the server's perspective — that servers can't
> control which clients can take up how much storage space — is the
> topic of ticket #666. Fixing the problem from the client's
> perspective, that you also mentioned in your email — that clients
> can't control which servers they are relying on for the longevity of
> their ciphertext — is the topic of #467.
> 
> Although actually I think the plan that Brian made (with the help of
> some other people) for #666 will partially address the latter problem,
> too.
> 
> https://tahoe-lafs.org/trac/tahoe-lafs/ticket/467# allow the user to
> specify which servers a given gateway will use for uploads
> https://tahoe-lafs.org/trac/tahoe-lafs/ticket/666# Accounting: limit
> storage space used by different parties
> 
> Regards,
> 
> Zooko
> _______________________________________________
> tahoe-dev mailing list
> tahoe-dev at tahoe-lafs.org
> https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20130929/38a5eeae/attachment.html>