When federated wiki started in 2011 it used jquery-ajar to POST to ruby-sinatra on the server. JSON format was already popular in 2011 so we went with the flow.
Within a year the ruby-sinatra was cloned as node-express which worked very much like ruby-sinatra and was easier to install because node was young then without so many variations. I still run some ol ruby-express sites just to prove they are interoperable.
We only ever write to the “origin” server though the client will read from many “remote” sites one page at a time. We POST a page to the server when it has been forked from somewhere else.
A page consists of a title, an array of items called the story and an array of edit actions called the journal. The client side editor will POST actions to change one item at a time which will update an item in the story and add an action to the journal. When this server turn-around completes the clients copy of the journal is extended similarly.
Items and actions have a type field. For items the type indicates what kind of markup it is expected to hold. Type paragraph is the simplest being plain text and hyperlinks alone. Type markdown is popular and offers italic, bold, bullets and headings. We extend markdown with our specific conventions for links.
Most items use a standard text editor if they support editing at all. Type fivestar has its own click handling for selecting one to five star ratings. A click on a star POSTS and edit action to the server to record the selection. We have 40 or so different types tho not all are installed on every server.
Action types are limited and unchanging because they must be understood everywhere to recover the version history of a page. Actions are create, add, remove and move.
Move is exceptional because our record understands that items can move around. Source code control systems that don’t include an editor just guess what happened when things are moved, and they usually guess wrong.
.
JSON Schema in more detail with examples.
Where Pages Live and how they get there.
History of the Lineup as creative space.
Federating Foreign Servers as read-only participants.
Computational Plasticity provides a vision for the future.