1.12 with Magic Folders
Brian announced the plans for 1.12.
"After the discussion at today's devchat, I've changed the next milestone
(1.12) to focus on Magic-Folders. This branch is ready to land, and
after some time baking on trunk, I think we should get it into a
release. So I've moved most of the other 1.12 tickets up into 1.13 (and
moved everything that was in 1.13 into a new 1.14). If there are
specific items that look like they can make it, we can pull those back
into 1.12 (e.g. the Tor stuff, introducer-cache, non-automatic-IP
guessing, removing v1 introducer support).
It'd be great if #1382 (servers-of-happiness) could make it, but I don't
want to hold up magic-folders for that.
Incidentally, at some point we might want to stop making guesses/claims
about which tickets will make it into which future releases, and
collapse everything that's not a current development priority into a
generic "soon" bucket. We have one of those already (along with
"eventually" and "undecided", since we didn't start out making these
sorts of predictions), so maybe it's time to add "sooner" and "soonest"
buckets too :-)."
Nuts and Bolts
Tuesday 06/28/16
Attendees: warner, ramki, cypher, zooko
- used google hangout this time, all went well except for zooko's
browser crashing a lot
- zooko and LAE folks are using Slack a lot, but there's an IRC-to-slack
bridge so they can still see #tahoe-lafs
- ramki is interested in porting Magic-Wormhole to Android
- discussed leasedb, parts of which are in the cloud-backend branch
- also #1834 which is about using the leasedb exclusively and removing
the share-crawler tools
- magic-folder branch is ready to land, warner ran the tests and found
they only add about 10% to the test runtime. currently waiting on
daira to agree to landing magic-folder before cloud-backend instead of
vice versa
- warner wants to release a 1.13 with magic-folders and whatever else
has already landed. To do that, we'll rename the current Trac 1.13
milestone up to 1.14, move most existing 1.12 tickets into a new 1.13,
then whittle 1.12 down to magic-folders plus anything else that's
already done, then release 1.13.
- warner suggested removing the numbered not-immediately-upcoming Trac
milestones (i.e. 1.13 and 2.0), maybe moving those tickets into a
"sooner" milestone to indicate that we care about them more than
"soon" and "eventually" and "undecided". Given our erratic release and
development schedule, I'm not sure that assigning tickets to
milestones more than a few months out is really useful.
- to make process on accounting, warner will publish a description of a
new WAPI protocol to the mailing list: websocket, CBOR, access tokens,
safe origin (unsullied by attacker-controlled grid-stored documents)
- we plan to add a Trac wiki page for next week's devchat, with an
agenda and notes
Tuesday, July 5, 2016
Attendees: zooko, warner, dawuud, meejah, ramki, cypher
- warner, dawuud, meejah will spend time wednesday pairing on
tor/multi-introducer stuff
- discussed warner's new WAPI plan
- one idea: do CBOR over unix-domain sockets, pass file handles to
gateway process for uploading
- similar: given proof that the WAPI client has local filesystem
access, gateway could use open() on local filesystem
- either would make uploads faster, removing a extra copy operation
folks were generally negative on the gateway doing filesystem access
- dawuud is thinking of Subgraph environments where client and gateway
have separate (sandboxed) filesystems, even though they nominally
run on the same computer
- one-pass vs multi-pass uploads
- warner is working on blog post to compare potential new encoding
schemes
- in some, we can get one-pass uploads by giving up on convergent
encryption, probably convergent share placement
- convergent share placement matters more on large grids (nodes > N)
- zooko wants to figure out if this is possible, or impossible, and
then stop thinking about it forever
- fun idea that probably won't work: place shares wherever, then build
a short bloom filter to remember where the shares went, then append
the bloom filter to the readcap
- repair / server churn will cause the filter to become inaccurate
- doesn't converge between multiple uploads
- noted that the backupdb (especially if enhanced by file hashes)
reduces the need for tahoe-level convergence
- how to achieve a universal grid ("one true grid" use case)
- resource (bandwidth) allocation, storage incentives
- downloaders need both filecap and either a way to pay a server for
download access or someone else who is willing to pay the server,
and a scaleable way to find the servers
- uploaders need a way to pay servers to accept and hold shares, and
to record the servers that were used (rather, the servers that will
be useful for the downloader)
- current Accounting design is very person-centric
- might be useful to add more file-centric options: per-file pre-paid
storage costs, pre-paid download-bandwidth budget
- someone who loves the data (as opposed to the person who uploaded
it) could deposit credit to pay for future downloads (by anybody),
the API would look like add-lease or renew-lease but would not be
tied to an Account
- maybe make a new database for this, "accessdb" or something
Tuesday, July 19, 2016
Attendees: warner, zooko, daira, liz
- daira is still working on cloud-backend
- daira agreed to have magic-folders land as-is
- talked about how to achieve the "OneTrueGrid": scaling problems, etc
- we're planning to add a wiki page with meeting agendas, etc
- hopefully the first half of the weekly meeting will be nuts+bolts:
ticket triage, specific decisions about current branches, then the second half
can be weird science stuff
The Tahoe-LAFS Weekly News is published once a week by The Tahoe-LAFS Software
Foundation, President and Treasurer: Peter Secor . Scribes: Patrick
"marlowe" McDonald , Zooko Wilcox-O'Hearn , Editor Emeritus:
.
Send your news stories to marlowe@antagonism.org - submission deadline:
Monday night.