mini-Summit report, day 1

[Callme Whatiwant]

Hello horribly backlogged mailing list!


I wanted to follow up with an item inline below:


On Mon, Jun 30, 2014 at 10:33 PM, Brian Warner <warner at lothar.com> wrote:
>
> Quick summary of the first day: Brian, Daira, Nathan, and Tony Arcieri
> met up in a bar/coffee-shop from 6-10pm. We talked about:
>
> * Accounting: Once we ship 1.11, we can land the "leasedb" branch,
>   followed by the "cloud backend" branch currently in use by Least
>   Authority. We could then cut a 1.12 release immediately, and servers
>   would then get leases stored in the database, with both Starter and
>   Anonymous "accounts" owning these leases. The next steps after that
>   would be: client pubkeys, furlification (to access non-anonymous
>   accounts), account states (enabled/frozen/disabled), account API
>   (space-used, lease reconciliation/mass-expiry, eventually payment),
>   server-side account control panel, client-side server-selection
>   control panel
>
> * Replacing the write-enabler: we tried (and failed) to reconstruct the
>   protocol developed at the previous(*2?) Summit to safely transition
>   from shared-secret-based write-enablers to pubkey-based ones. Reminded
>   ourselves of the potential approaches (signed mutable request
>   messages, unsigned requests but server verifies entire shares),
>   debated whether to move piecemeal towards removing Foolscap or to make
>   one big leap.
>
> * discussed grid identifiers, how/why to participate in multiple grids
>   at the same time, how to tolerate non-overlap between uploader's
>   desired servers and downloader's known servers. Daira had an idea to
>   describe a grid as a mutable file stored in a (single/global)
>   "meta"/"super" grid, containing contact info for all its servers. The
>   gridid is then the readcap for this file. Brian described his
>   "storage-club" idea from a few years ago
>   (https://tahoe-lafs.org/pipermail/tahoe-dev/2011-February/006159.html)

I brought up a desired use case relating to multiple grids and
storage-user / storage-provider agreements:

Suppose I'm in need of online storage and I find a friendly storage
provider and I prefer the service they provide to many alternatives,
so I sign up with them.  Alas, it turns out their terms were actually
specific to grid A, but I use grid B.

-or, suppose I'm a storage provider and a storage user comes along and
wishes to use my service and I want to provide that service.  Alas, I
provide my storage to grid A, but the user is on grid B.


The use case is that a storage user or a storage provider both want to
be able to arrange a storage agreement, but have that agreement be
valid on multiple grids.  I have no idea how feasible this is to
implement, nor what kind of user experience it would entail.  But I
*do* know that if I'm going to pay for LAFS storage, I'd really
*rather* pay for storage that just so happens to work on these three
different grids I use.


Note: This is related to a larger issue which is affecting me and
probably others more and more as time goes on.  That is that I am a
member of multiple grids.  Currently I run multiple gateways and
storage providers, which is simple to reason about, but cumbersome.
Perhaps one of my storage servers is full and the other is half empty.
I have to determine by context which caps belong to which grid (or try
and fail to perform operations).  This is a real problem which won't
go away, because a new grid will come along in which I want to
participate, because I want to provide storage or share files with
members of the new grid, but I'm already quite invested in current
grid memberships (for example, because I rely on them for backups).



>
> * Went over a diagram of related/dependent tasks from the previous
>   Summit: explicit server selection, new encoding formats, web control
>   panels, grid management.

Explicit server selection, grid management, and the multiple-grids use
case I outlined above are overlapping and interacting design facets.


>
> * Brian demoed Petmail, walked through the message-wrapping layers,
>   explained the invitation process and UI.
>
> * We discussed Rust, Noether, and type systems.
>
>
> We're meeting up again tomorrow, 6pm, at the Mission Creek coffee shop,
> 968 Valencia, because it's quieter than the bar. Join us!
>
> cheers,
>  -Brian
> _______________________________________________
> tahoe-dev mailing list
> tahoe-dev at tahoe-lafs.org
> https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev