[tahoe-lafs-weekly-news] TWN70

Fri Jul 22 04:18:25 UTC 2016

=====================================================
Tahoe-LAFS Weekly News, issue number 70, July 21 2016
=====================================================

Welcome to the Tahoe-LAFS Weekly News (TWN).  Tahoe-LAFS_ is a secure,
distributed storage system. `View TWN on the web`_ *or* `subscribe to
TWN`_.
If you would like to view the "new and improved" TWN, complete with pictures;
please take a `look`_.

.. _Tahoe-LAFS: https://tahoe-lafs.org
.. _View TWN on the web:
  https://tahoe-lafs.org/trac/tahoe-lafs/wiki/TahoeLAFSWeeklyNews
.. _subscribe to TWN:
  https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-lafs-weekly-news
.. _look: https://tahoe-lafs.org/~marlowe/TWN70.html

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 :-)."

.. _`plans for 1.12`:
  https://tahoe-lafs.org/pipermail/tahoe-dev/2016-June/009754.html

.. _`#1382`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1382

Mailing List
============

A New WAPI and WUI proposal
---------------------------

`Discussion began regarding a new WAPI and WUI`_.

.. _`Discussion began regarding a new WAPI and WUI`:
  https://tahoe-lafs.org/pipermail/tahoe-dev/2016-June/009755.html

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

.. _`Magic-Wormhole`: https://github.com/warner/magic-wormhole
.. _`#1834`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1834

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

* topics:

 * 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

Send your news stories to `marlowe at antagonism.org`_ - submission deadline:
Monday night.

.. _`marlowe at antagonism.org`: mailto:marlowe at antagonism.org
.. |peter| image:: psecor.jpg
   :height: 35
   :alt: peter
   :target: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/AboutUs
.. |marlowe| image:: marlowe-x75-bw.jpg
   :height: 35
   :alt: marlowe
   :target: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/AboutUs
.. |zooko| image:: zooko.png
   :height: 35
   :alt: zooko
   :target: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/AboutUs