incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joseph Gentle ...@josephg.com>
Subject Design review: A plan
Date Wed, 09 Sep 2015 07:05:45 GMT
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
View raw message