Tesla Coils and Corpses report, 2014-07-25

[Zooko Wilcox-OHearn]

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

LAFS Tesla Coils & Corpses, 2014-07-25
======================================

in attendance: Zooko (scribe), Daira, Andrew, Nathan, Brian (last minute)


topic: add-only sets!

Nathan points out that the Tahoe-LAFS concept of add-only sets has much in
common with open topics in crypto-consensus algorithms (e.g. Bitcoin).

We looked at our current best design for add-only sets
(https://tahoe-lafs.org/trac/tahoe-lafs/ticket/795#comment:13 ), which is
known as "The Elephant Circus Design".

Daira wanted to know: what does the reader do? The design described in
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/795#comment:13 is silent on
that critical question. We had some discussion of the weird way in which a
simple union-read might somehow allow servers, authorized-adders, or a
collusion of those two, to exercise what Zooko calls "editorial control".

What should the Diminish-Relations be between caps? The description at the
top of https://tahoe-lafs.org/trac/tahoe-lafs/ticket/795 has write-cap
diminishable to append-only cap, but Zooko doesn't think there should *exist*
a write-cap, since a write-cap is a thing that can violate the add-only
property.

Brian has an idea about a write-cap being used for a sort of
"compacting/garbage-collection" process that could occasionally rewrite the
state for efficiency, but Zooko (at least half the time) thinks that we can
get away with not having that, and instead having a stronger security
property. The stronger security property is that *nobody* *ever* has the
authority to violate the add-only property.

Note that if we do the can't-be-rewritten version, so that add-only sets
inevitably get more and more heavyweight as they get bigger, then
applications written on top might choose to emulate the rewritable version by
having all readers switch to a new add-only set once the old add-only set
gets too heavy.

We decided that this is actually a multiset, not just a set.

Nathan suggested that for some uses cases an "add-only multiset" API is the
right API, but for other uses the underlying partial order might be
important.

We talked about the use case of building "append-only files of records" on
top of the add-only multiset. That is definitely a use where having access to
the underlying partial order can be valuable, because without it you have to
sort the entire set of records, but with it you can sort only those subsets
which are still ambiguous after applying the underlying partial order.

We talked about the use case of building "append-only log files" on top of
"append-only files of records". Zooko is enthusiastic about append-only log
files.

Daira asked if the elephants should be size-limited. Brian argued that
accounting and consistency would be easier if the net were wrapped around the
entire elephant, instead of the net being wrapped just around the elephant's
trunk and you can go find the right elephant if you need it.

Does the append-only-file-of-records protocol need to *prevent* an authorized
appender from appending a record without proving knowledge of the previous
record? Without proving knowledge of the previous record *from* them? No, the
protocol does not need to prevent those things. Appenders are not constrained
in these ways. The goal of append-only is just that all readers will see the
same total order as one another.

Daira says they should be called add-only DAGs instead of add-only multisets.

Nathan started writing the Python API for "append-only files of records" in
the branch named 795-add-only-sets_0. Brian pointed out that the current
Python API to mutable files has much in common with the new API for
append-only files.

Use case: secure logging

Use case: chatroom, elephants are messages from different people

Use case: the OS 10 "Dropbox/Publc Box" thing which people can use to give me
files but they can't see what files have been given to me.

Use case: announcements on a shared grid

Use case: secure backups, defense against ransomware


-- 
Regards,

Zooko Wilcox-O'Hearn

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