As we head in 2020 toward standards for encrypted data vaults (see overview github.com/WebOfTrustInfo…) I can't help but think of efforts in 1991 to add cryptography to the Xanadu Club system. I found some old Xanadu docs on this & scanned them for posterity: dropbox.com/s/qeyywxr9vk45…
In modern day cryptographic terms, each Xanadu document is like an encrypted git commit (a point in time of a collaborative document). The Read Club has the decryption key to read the data. The Write Club can collaborate to sign future revisions of document.
As I think about how the Club System might be implemented today, the Read Club would be architected something like Minilock, 45678.github.io/miniLock-file-… with its list of public key "permits" that can be unlocked using a Diffie-Hellman secret between keys to reveal the decryption key.
The Write Club would be something like a Threshold Schnorr Musig, where in a MPC ceremony the participants of the old document could sign new commit to show that the revision was properly derived from a threshold of its original authors.
The rules for what is an acceptable signature for future revisions of a Club System document would be written in the previous revision using a #SmartSignature style construction, possibly like Bitcoin Script, or something simpler with basic AND/OR and threshold constructions.
Using Schnorr (or PBC) aggregation and adapter signatures and means that we can offer interesting atomic "scriptless script" capabilities — a payment accepted in Lightning could immediately allow for read access, or be used to get the right to be added to the Write Club.
Like the original Xanadu Club System, all Clubs themselves are Clubs. So you can have scriptless scripts that allow you to pay to read a Club, that then give you adapter signatures to write, where you request a threshold signature from members of another Club to give you access.
Careful use of aggregated signatures can be used to ensure privacy. For instance you can know that you were voted into access to a Club, but not by who.
A particular thing I'd like to see in a Club System is to move away from cloud-based personal encrypted data stores, toward a more "fog"-like approach using content-addressible-hash based system like IPFS. The funds received by Clubs for access can be used to pay for persistence.
As proof that these ideas are possible, here is a demo by @gugol using a Lightning native macaroon-based bearer API credential, offering a server assisted atomic swap capability, sybil resistance, application level DoS, and fine grained authentication:
@gugol If you don't know what macaroons are, they are a bearer cryptographic authorization credential. Here are some useful links: github.com/lightningnetwo… theory.stanford.edu/~ataly/Papers/… These Macaroons use HMACs, but I propose that they could be constructed using aggregatable crypto as well.
@gugol I think there are also some ideas to draw from research at Signal for use for the next iteration Signal Private Groups: signal.org/blog/signal-pr…
