incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Wrobel <darkfl...@gmail.com>
Subject Re: Design review: A plan
Date Wed, 09 Sep 2015 18:02:24 GMT
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 <vega113@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 <me@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
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message