Hi Joseph It's great you are moving forward. My concern is that you go for too much without clear monetization plan. Honestly, i don't think I can fully grasp your plan, but it seems to me that you should go just for p2p content servers without specifically designing identity servers and embedding encryption but instead design you architecture to allow powerful extensions that can do such things and who knows what more. Extensions might also create potential for monetization.
Another great opportunity for p2p content network - is ability to distribute advertisement profits to those who actually create the content. Something like reddit, but p2p where profits go to most influential users. (Ethereum smart contracts?) On Wed, Sep 9, 2015 at 10:06 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 >
