LAFS Twice-Weekly Hack Hour, 2014-04-03

[Zooko Wilcox-OHearn]

.. -*- coding: utf-8-with-signature-unix; fill-column: 73; -*-
.. -*- indent-tabs-mode: nil -*-

LAFS Twice-Weekly Hack Hour, 2014-04-03
=========================================

in attendance: Zooko (scribe), Aaron, Daira

(Note that Freenode was unreachable, at least to Zooko, so that might have
prevented some people from joining the meeting.)

Pre-meeting chit-chat: Bitcoin is fatally flawed.

1.a. A Dominant Miner is an existential threat to the currency.

1.b. There is a smooth path of making more and more profit, at the end of
  which you are a Dominant Miner.

2. Having a complete transaction history indelibly stamped on every coin will
   lead to non-fungibility. The IRS just tried to give it a big push in that
   direction, but even if they roll that back, says Zooko, Bitcoin will still
   inevitably lose fungibility in practice.

Once the meeting officially started, Aaron demoed his Javascript (Bootstrap)
WUI, which is called Simple Secure File Browser ¹. It is read-only. It looks
very clean. The major functional difference between it and the builtin
Tahoe-LAFS WUI is that when you click on subdirectories in the Simple Secure
File Browser it updates a "breadcrumb trail" showing the path of
subdirectories that you've taken, from the root.

This means that if you share the URL, you're sharing access to the root, not
to the current subdir.

We had a good discussion about sharing, UX, and security. The consensus among
the three of us was that a good user action to initiate sharing would be:

* If you want to share read-only access to the thing you are looking at, you
  just copy the URL from the URL bar and send that.

* If you want to share write-access to a page that you have write access to
  and which you are looking at, you push the button on the page labeled
  "Share Write Access To This". This pops up a text field next to the button
  containing the write-cap, already selected. This is similar to how web apps
  such as Google Maps implement the "share a link to this" feature.

Aaron said that when he suggests LAFS-style crypto-caps, he commonly
gets pushback about tracing delegation, prohibiting delegation, and
revoking access. Zooko sighed heavily and agreed that this is an
extremely common reason for people to decide not to use crypto-caps,
but that it is a *mistaken* reason. The difficulties of tracing
delegation, prohibiting delegation, and revoking access are made
*obvious* by crypto-caps, but they aren't *caused* by crypto-caps,
they are inherent problems that also bedevil conventional access
control solutions. Zooko ranted about how you can't prevent your users
from sharing credentials, you can't prevent them from proxying for one
another, and you can't prevent the people who control your centralized
access control server from abusing *their* access, either.

We discussed how there were possible improvements within the
crypto-cap model to ameliorate these problems. Many such improvements
are already described in tickets on our trac, but one that is not yet
described is to create independent caps pointing to the same resource,
so that you can revoke one of them and not the others.

We talked about if and how to integrate a newer and better WUI into
Tahoe-LAFS. Incremental improvement of the current WUI, or a fresh start? We
would want to support non-JS-capable browsers in any case, so we would end up
with two WUIs — one for JS-incapable and one for JS-capable browsers.

All such work is blocked on releasing Tahoe-LAFS v1.11!

Daira and I agreed to work together on Tahoe-LAFS v1.11 at the next
Twice-Weekly Meeting.

future meeting agenda: David's Clojurescript-based WUI

¹ https://github.com/acordova/lafs-simpleui


-- 
Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.