Joseph, I am very excited and encouraged by your overall approach. JSON's the way to go, clearly. Given the power and purity of what you are trying to accomplish in a core form, I agree that p2p may be too much of a stretch at this point. The ability to separate content servers and identity servers may be sufficient for now to allow enough flexibility to provide the secure and distributed editability to make this an attractive medium. Thinking of the Nkommo model, I suppose as a stopgap/starting point the question might be whether there can be mechanisms for export/import into a content server that can allow simple and non-synchronised sharing of content into different network domains - in other words, keep the "sneakernet" option open. Not a high priority given your initial focus, but worth considering. I suppose that this could be related to the Snowden scenario from this standpoint: ultimately, network security is moot if someone with credentials can replicate server data. That's not to say that your approach to network security is bad - it's right and necessary - but the ability to administer a server needs to be thought through as both a problem and an opportunity.
I like that you're including the ability for "bot" apps to do OTs - this will be very important for sensor-driven data collection and interactions that build up around it. I'd like to think that we would have an Android-like flag that can suppress "side-loaded" apps at our discretion, both at a system/user-wide level and with document-specific exceptions. As I've asserted often, being able to have some sort of system of storefronts/repositories for trusted apps will make all the difference, especially on public documents. Seems like there should probably be a tiered approach to this - only document owner can enable additional apps, collaborators can enable trusted apps, all trusted apps are allowed, non-trusted apps allowed on a whitelist basis, non-trusted apps excluded on a blacklist basis, all non-trusted apps allowed. Concept for schemas is similar to what we discussed earlier - I agree that it's a very important part of enabling far more flexibility than what the typical Wave derivative platform offers today. You're smart enough to have waited until both the technologies and your point of view have matured to the point that you're ready to "make a statement" with this project. The world of Wave has not run away in the meantime, so I hope that there is great potential for this to still take off. I agree with your scope of vision - the Web as a whole is stuck, Wave threatened to unstick it, and now it's time to move the Web forward. All the best, John Blossom email: jblos...@gmail.com phone: 203.293.8511 google+: google.com/+JohnBlossom On Wed, Sep 9, 2015 at 3:05 AM, 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 >
