Hacker News Reader

Comment by zkhalique | Hacker News Reader

We've been thinking about this problem for quite some time. My friends and I are passionate about re-decentralizing the web. The biggest challenge we've come across is this:

Many users want to do things with other users

That means there has to be a way to persist state and history (of a group activity, an evolving resource, etc.) across machines. Mental poker is still very hard to do for groups. Since most clients will not have amazing uptime, that means you still need a network of servers. Servers that manage security behind a firewall.

So, the conclusion is -- for group writable data, the best you can do is have servers be completely interchangeable, but you will still need servers and networks of servers.

The good news is, many of the challenges are orthogonal to each other. Someone's building a Mesh network, for instance. Someone else is building the protocol layer with IPFS. We're building the social layer for this coming web.

View on HN

Couldn't you do group editing through using lisp inspired link lists? See a comment thread? CONS your comment onto the end of the comment thread and push into the ether, and notify about the new list head.

Take other patterns from clojure immutable data structures for various other kinds of group edited time travelling sites

It might be possible to do some sort of self contained data structure that authenticates everybody and only allows authorized access to it, which solves the Byzantine Generals problem like BitCoin does, and which resists forking and instead uses vector clocks and Operational Transformations to consolidate actions done to the tree. But even so, how would it resolve conflicts? It could be a long time until a conflict is discovered, and then do edits get dropped, or what?

Why would you want to resist forking, and incur all that other complexity when you can just have an "authoritative" source for the entry point? Similarly, if someone wants to fork the conversation off and become a new "authoritative source" why would you need to stop them?

as for conflict resolution, merging, etc, it kind of looks like a (mostly) solved problem. I don't see how conflicts could occur in a comments stream. It's append-only.

It's append only until B and C get a copy and each append their own comments, then D and E get two separate forks and append their own comments. That can work for trees to which you only append, such as comments. That does NOT work for any operations that do non-append operations on trees, such as operations which rearrange the tree into a line.

So yes, for append-only tree structures, this may work. In terms, of say, a Google Doc that means you can never delete or insert any text, but only append text to the end of paragraphs etc. Certainly very limiting.

Unless there's something you haven't described, in which case I encourage you to provide a more in-depth comment describing a solution for actually inserting or modifying the tree.

actually, google docs ARE append only. They use the vaunted google wave tech of Operational Transforms. every single timestamped keystroke is saved separately in the database. when two users are involved, and editing simultaneously, the OT algorithms resolve the merge conflict on the spot. it kind of looks like a tree structure, or an append only array. the actual document you are looking it is actually something like a flattened keyframe in a movie that's reached the end.

Reply on news.ycombinator.com