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 13:04:34 GMT
+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 <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