[tahoe-lafs-trac-stream] [tahoe-lafs] #403: grid identifier

[tahoe-lafs]

#403: grid identifier
------------------------------------+-----------------------------
     Reporter:  zooko               |      Owner:
         Type:  enhancement         |     Status:  new
     Priority:  major               |  Milestone:  2.0.0
    Component:  code-peerselection  |    Version:  1.0.0
   Resolution:                      |   Keywords:  newcaps newurls
Launchpad Bug:                      |
------------------------------------+-----------------------------

Old description:

> If you give someone a Tahoe URL containing a Tahoe capability, and they
> are using a different grid (i.e., they are using a different introducer
> to meet storage servers), then they will get a graceless failure
> suggesting that the file they asked for doesn't exist.
>
> It might be good to include a "grid ID" in the URL.

New description:

 If you give someone a Tahoe URL containing a Tahoe capability, and they
 are using a different grid (i.e., they are using a different introducer to
 meet storage servers), then they will get a graceless failure suggesting
 that the file they asked for doesn't exist.

 It might be good to include a "grid ID" in the URL.

--

Comment (by davidsarah):

 Here are the design criteria I'd like to see satisfied:
 * A ''grid specification'' (grid-spec) is a file specifying a set of
 servers, and optional parameters such as a recommended share placement
 policy or recommended encoding parameters.
 * A ''grid-cap'' is a global, securely unique reference to a grid-spec. It
 can be a mutable or immutable reference (e.g. a hash of the grid-spec or a
 public key of an authority that can publish updates).
 * There is an IANA-registered URI scheme (say, {{{lafs:}}}) that has a
 grid-cap in the authority field, and a file-cap in the path field. Like
 most authority-based URI schemes, the authority can be omitted and implied
 by the context.
 * Local aliases can map to URIs that include a grid-cap.
 * It is possible to use different grids in different arguments to a CLI
 command, say to copy ciphertext shares (preferably without decryption)
 between grids.

 Note that it may seem as though we have a bootstrapping issue in that the
 problem of looking up grid-specs is essentially the same as the problem of
 looking up files -- and so if we can solve the former, why can't we solve
 the latter without the former?

 The answer is that there are far fewer grids than there are files, and
 even fewer grids that are used by a given client. So,
 * It is practical to persistently cache information on every grid that a
 client normally uses, whereas it wouldn't practical to persistently cache
 information on every file.
 * The mechanism to look up grid information only needs to be available to
 a given client when it actually adds a new grid.
 * Adding a grid is infrequent enough that the lookup could be manual, i.e.
 downloading a file describing the grid and adding that to the local cache.

 However, it would also be convenient to allow looking up a grid-spec
 automatically, so that the resulting caps are truly global names. Here is
 a proposed implementation of that, which takes advantage of the similarity
 between grid-caps and file-caps by having them be the same thing:

 * Each client is configured with the grid-spec of a ''bootstrap grid'',
 that can be used to look up the grid-specs of other grids.
 * There is a ''public bootstrap grid'' which is the initial bootstrap grid
 for newly created clients.
 * Accounting mechanisms are used to mitigate denial of service on the
 public bootstrap grid.
 * Each client has a local cache mapping grid-caps to grid-specs.
 * There is a command (and possibly a WUI admin page, if we can figure out
 how to do that securely) to add a grid-spec to the cache and mark it as
 persistent.
 * A grid-cap is exactly a file-cap that is interpreted as being on the
 client's bootstrap grid. It may be to a mutable or immutable file
 containing the grid-spec.
 * If a client sees an URI with an authority that is not a cached grid-cap,
 it looks up that grid-cap on its bootstrap grid. It does ''not'' cache
 this persistently (but ''should'' cache it temporarily).

 Note that we wouldn't implement this in one go; stage 1 could be to leave
 out the automatic lookup of grid-caps on the bootstrap grid, and instead
 just have the persistent cache to which grid-specs have to be added
 manually.

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