[tahoe-dev] weekly Tahoe dev call report: 12-Jun-2012

[Brian Warner]

Participants: Brian, David-Sarah

Topics:

* preparing for Accounting: there are several cleanups/refactorings that
  can pave the way for Accounting code to land without causing
  user-visible changes. The plan is:
  * create a separate "Account" object, which is Referenceable and
    provides RIStorageServer. Create one instance named "anonymous",
    publish its FURL in the introducer announcement.
  * Each Account connects to the Server. Start by porting some of the
    cloud-backend branch (which moves remote_ methods from Server to a
    backend object), so that Accounts get connected to backend objects.
    Try to minimize the disruption here, but also minimize conflicts
    between this change and future landing of the cloud-storage branch.
  * (no user visible changes so far)
  * (release 1.10 before this point)
  * Disable expiration, create the LeaseDB and the Crawler that adds
    starter-leases. Remove lease-handling code from share objects (and
    stop putting leases in shares).
  * (at this point, renewal and expiration is disabled, but all shares
    are getting starter leases)
  * Implement Account methods that create+renew leases.
  * re-enable expiration, rewrite expiration-status/progress web display
  * (at this point, lease/expiration functionality is back to 1.9
    baseline: no per-user accounts yet, but GC should work as before)
  * implement multiple Accounts, per-user Account creation, client-side
    Account negotiation
  * add basic CLI tools ("tahoe admin", for local nodes only) to dump
    accounting table: list number of files, space consumed, per user
  * add web view (readonly) of accounting table
  * (at this point, accounting starts to become usable: admins can
    monitor space usage, but have no tools to control/disable it beyond
    complaining to the user in question)
  * add account modes (enable-read, enable-write, retain-shares), CLI
    tools to set them. tahoe.cfg mode to set default (accept-all or
    require-approval).
  * then future stuff (undecided): petnames, Invitations, secure web
    control panels, reciprocity, payment

* concerns about ACL-ness of Accounting: "node key ABC has can-read but
  not can-write flags" is very ACL-ish. Experience shows that moving
  from ACL-ish to objcap is hard. Can we start with objcap?
  * we've circled around this a *lot* over the last 5 years
  * ACL-ish appears simpler right now
  * offline-delegateable (-revocable -attenuable) storagecaps require
    certchains
  * online-delegateable storagecaps require interaction with all
    servers, kind of a drag
  * delegating a storagecap should cause the new cap's space-usage to be
    counted against the old cap's quota, so servers need to know the
    ancestry of these caps, and DB queries need to sum them. This looked
    somewhat hard, and provoked a lot of discussion+disagreement between
    Brian and Zooko back in the day. Might still be possible, but
    expensive in engineering/design/implementation terms.
  * WUI affordances for managing storagecaps seem beyond us right now
  * general hope: treat client keys as degenerate certchains, add more
    generic structures later

* 1.9.2 bug triage

The phone bridge worked fine, only a little static and latency and
occasional dropouts. But a warning: the on-hold music when you're the
first to join and are waiting for your friends to join is a painful
country-music song about listening to on-hold music when you're the
first to join and are waiting for your friends to join. I was very
relieved when David-Sarah connected :).


cheers,
 -Brian