One Grid to Rule Them All

[nejucomo]

Introducing a use case and associated ticket keyword: globalcaps

This is an enhancement request to fulfill this use case:

A user knows a $CAP they want to share with the world, so they tweet it, or print it in a book, or otherwise share it across time and space to a potentially boundless audience.

Anyone using the right software setup who sees that $CAP has a reasonable chance to retrieve the contents.

There are many related design issues, as well as existing mailing list posts and tickets:

• My call to action: ​https://tahoe-lafs.org/pipermail/tahoe-dev/2013-June/008447.html
• A request for a "grid id" feature that's complementary: #403
• Many relevant keywords which this issue is tagged with.

This ticket has a scoping problem: when do we close it? I recommend closing it when either of these conditions are met:

• One user emails a $CAP to tahoe-dev and another user successfully retrieves it without us sharing any introducer information with a checkout from the official tahoe-lafs git repository (any branch); or

• There is a new separate code base established whose purpose is to implement this use case and whose URL is in this ticket.

[nejucomo]

Ticket #1838, Add StorageLocation hint to Storage Server, suggests a feature which may be used to implement universal caps.

[nejucomo]

I advocate the following design strategy: ​https://tahoe-lafs.org/pipermail/tahoe-dev/2013-June/008448.html

One implication of the outlined design strategy is a need for a webapi feature to expose share placement. I'm going to add a separate ticket for that, because it is not logically necessary for this use case, but it is one approach which would also address several other tickets, such as #1838 and #1657.

[nejucomo]

Exposing share location in the webapi is also quite relevant to this page: ​https://tahoe-lafs.org/trac/tahoe-lafs/wiki/ServerSelection

[nejucomo]

Client-controlled peer selection is already ticketed in #573.