Regarding p2p based approaches not being mature enough for OT, are we talking about https://ipfs.io/ like solutions here? I know little about the underlying durability or availability of such technologies, merely it seems best not to reinvent any wheels if others have already done the work.
~~~ Thomas & Bertines online review show: http://randomreviewshow.com/index.html Try it! You might even feel ambivalent about it :) On 9 September 2015 at 15:21, Yuri Z <vega...@gmail.com> wrote: > 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 > > >
