[tahoe-lafs-trac-stream] [Tahoe-LAFS] #3457: The separate introducer servers represent unnecessary complexity in an overall Tahoe-LAFS deployment

[Tahoe-LAFS]

#3457: The separate introducer servers represent unnecessary complexity in an
overall Tahoe-LAFS deployment
------------------------------+-----------------------
     Reporter:  exarkun       |      Owner:
         Type:  defect        |     Status:  new
     Priority:  normal        |  Milestone:  undecided
    Component:  code-network  |    Version:  n/a
   Resolution:                |   Keywords:
Launchpad Bug:                |
------------------------------+-----------------------

Comment (by exarkun):

 Here's another idea.  An entity creates and maintains a mutable list of
 announcements *on a grid*.  It sets the encoding parameters for this
 object so that a full copy exists on every storage server which appears in
 the list of announcements.  Storage clients are given bootstrap
 configuration which consists of a recent-enough copy of this list.  If any
 storage server in the list is still reachable then the current copy of the
 list can be retrieved and the client can update its persisted
 configuration with that copy.  Over time the storage client can continue
 to retrieve updates to this list.  As long as the client retrieves an
 update before *all* storage servers it knew about become unreachable it
 can always find the latest configuration.

 This mostly solves the problem of the static introducer list.  There is
 still a bootstrap configuration but there is a mechanism to update it over
 time.

 It has ... some ... impact on overall load on the system.  Every storage
 server in a grid now has to maintain a copy of the list of announcements.
 However, the list doesn't have to be updated as frequently anymore.  It
 only needs to be changed when the actual list of storage servers changes
 (compared to currently where an announcement is sent every time a storage
 server process *starts*).  This probably means the storage requirements
 are higher (but still essentially negligible) and the runtime requirements
 are lower.  Since there is no notification mechanism it will require
 clients to poll the storage object to find updates - however this can be
 quite low frequency and there are a number of reasons we want to *add* a
 notification mechanism to Tahoe-LAFS anyway, at which point it could be
 leveraged to remove the polling here.

 It defends against unreliable storage being announced since now only "an
 entity" can control the list of announcements.  It does this by completely
 denying open participation, of course.  However, *any* entity could choose
 to maintain one of these lists containing *any* announcements that entity
 likes.  Clients can pick the list (or lists!) they want to follow.

 It should remove all privacy concerns since there is now no longer any
 difference between consuming storage for normal purposes and obtaining the
 storage announcement list (as it is the same as any other data on the
 grid).

 It also addresses behavior in the face of misbehaving introducer clients.
 The entity managing the list might misbehave.  In some ways that entity
 becomes the single point of failure in the system.  For example, they
 might lose their keys and become unable to distribute further storage
 server updates.  This would require a reconfiguration of all clients to
 follow a mutable object.

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/3457#comment:3>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage