+1 JSON I like Json. It all sounds pretty good, with a new codebase maybe I'd stand more chance of meaningfully helping at some point next year.
~~~ Thomas & Bertines online review show: http://randomreviewshow.com/index.html Try it! You might even feel ambivalent about it :) On 9 September 2015 at 09:05, Joseph Gentle <m...@josephg.com> wrote: > Hi everyone! > > I want to get some feedback on a rough plan I have going forward. Next > year I'm moving to Europe (not sure where yet - gonna spend a month or > two travelling first before settling. Berlin?) I want to start my own > business, and I'm considering making that business a simple(r) > successor to wave, starting from a fresh codebase. I want the whole > thing to be opensource, monetizing through paid hosting or something > like that. I might do a kickstarter once I have a working prototype - > I'm not sure. I'll see how my financial situation holds out. > > --- > > So here's my plan: > > Waves (documents) are JSON objects. Each document is hosted at a > single site and has a URL. I'd love to use a fully p2p approach (like > ipfs), but I don't think the tech is ready[1]. Each document will have > a schema field or something to tell applications / the server how to > render the data. > > Documents are living things. They can be modified by submitting > operations using the new JSON OT type[2]. They can also be subscribed > to. > > I want to split servers into two parts: > - Identity servers > - Content servers > > ## Content server > > Content servers store actual documents. They're the equivalent of > webpages, although they have a few more tricks: > - You can subscribe to documents > - You can edit them using OT > - Documents can be encrypted > > The content server is responsible for access control. So you could have: > - Private documents only viewable & editable by one user > - Documents with a set of collaborators > - A publicly readable document which only one person can edit (like a blog > post) > - A process editing the document (for content like the hackernews / > reddit frontpage) > > > ## Identity server > > The identity server is a place to remember who you are, keep track of > which documents you're subscribed to (think gmail + google reader) and > maybe present the user an inbox view of some kind or something. The > identity server is also responsible for triggering phone > notifications. Once a user has logged into their account, they should > be able to interact with content either: > - Via a webpage on the identity server > - By connecting to the target content server directly > > I'm happy to stick with user@identitydomain identities for now (are > there any good alternatives?). > > When a user starts a new conversation, the conversation will be > created on a content server. I expect most hosting providers will run > both an identity server and a content server then just default to > using their own content server to host their users' data. > > > # Encryption > > Not having end-to-end crypto after the snowden leaks is a bit of a > non-starter. Unfortunately to do server-side OT the content server > will need to be able to decrypt the operations. Thankfully there are > some performance/encryption tradeoffs we can use to make make this > work. Ideally I'd like to copy some of Moxie Marlinspike's crypto > primitives from TextSecure (aka Signal). This will need more thought. > > But it should be doable by considering the content server to simply > store a stack of encrypted blobs (the operations) and a recent > snapshot blob. The snapshots would have to be uploaded periodically by > users. If the server was told the version of new operations, it could > punt back operations which aren't up to date back to the submitting > client. The client would then update the operation and resubmit. > > I'll have to explore this more at some point. > > > [1] There's three big unsolved problems with making a fully distributed > system: > - I don't think anyone's solved the Zooko's triangle identity problem. > - OT in a p2p setting isn't mature enough. > - I don't know any way of implementing spam / abuse prevention in a > p2p setting. Even with full end-to-end encryption we can get pretty > decent host-blacklisting spam prevention in this model. > > [2] The new JSON OT type is based on the discussion we had on this > list awhile ago. I've been working on it for the past few months. The > draft spec is here: > https://github.com/josephg/json1/blob/master/spec.md. > > > --- > > So thats the basic idea. As I said, I'd love some feedback / comments > / concerns. Its not the most ambitious project - which honestly is > good. I think setting something like this up is very doable. Once the > new JSON OT type is done then all the really hard pieces of > infrastructure will be ready (except crypto). > > I have no idea about how connected / involved everyone wants to be in > this project. At least early on I'll use the benevolent dictator model > of governance. Hopefully once we have a few sites connected and > working we can organise a steering committee or something, but thats a > ways off at this point. > > -J >
