Smallest-Federated-Wiki
Smallest-Federated-Wiki copied to clipboard
WardCunningham
Discussion: Operational Transformations
I was just reminded of the concept of Operational Transformation http://en.wikipedia.org/wiki/Operational_transformation
I also have been reading Darcs' Theory of Patches as inspiration for the federated part of this project(SWF). The description of OT seems even more applicable to how I imagine SFW could work. That begs the question, is this project rebuilding Google Wave? I'm not saying that bad, it could even be a great thing. Its protocol is documented at http://www.waveprotocol.org/ and is another source of good information to move the federated part of this project forward.
Welcome.
I've read some paper on the darcs' theory but don't remember much. I just read the OT wikipedia article and find I will need some coaching to understand the variations. What's a good way forward?
I've added move hover and click functionality to the journal so that we can understand by example what we're recording now. I've noticed that there are more cases than I'd realized even with our modest collection of actions.
Im not sure what the way forward is but something should emerge with enough studying of OT and an understanding of how the wiki works/should-work. An infographic of the indivisible pieces of the wiki would be a nice start.
The idea with OT is still somewhat current : https://github.com/WardCunningham/Smallest-Federated-Wiki/issues/384.
Introducing a granular versioning as darcs messes with the Journal, which decreases compatibility, if not handled right. Although https://github.com/WardCunningham/Smallest-Federated-Wiki/issues/318 warns about this, still I kept on thinking if it wouldn't be wise to allow a more granular versioning backend.
darcs is interesting, because it handles commit dependencies differently. there's an impressive video at http://projects.haskell.org/camp/unique .
I'm imagining to fork / copy certain patches instead of whole paragraphs. Maybe someone forked my site and made a clever addition. I want this to return to my page. But only this halfplace. If I'd hover the left side of a paragraph, I'd move it in total. But if I hover above the text, portions of it that belong to certain commits are highlighted and can be dragged, too. We imagine this page is already opened via the federation. So dragging works basically.
Now if I took one of those darcs/camp partial commits/patches, I could hover them above any other paragraph and if the diff 'snaps in', I could let it fall. Otherwise a new paragraph is being created.
Maybe some of ideas used over on substance provide some ideas/pointers, see substance internals.
Maybe someone forked my site and made a clever addition.
There remains a discovery problem. How to know that somebody has forked a page from my site? While it will show up if you already have their site in your neighbourhood, if you don't the wiki currently has no mechanism to inform you which pages have been forked, and to where.
Wow, Paul, thank's for the mention of substance. It seems that's one part of the (self-hosted infrastructure) puzzle I've been waiting for.
https://github.com/WardCunningham/Smallest-Federated-Wiki/issues/186 also talks about Data Schemes for the Journal. https://github.com/WardCunningham/Smallest-Federated-Wiki/issues/278 talks about storing JSON changes in JSON.
For anyone still interested in this problem space, I've been doing some thinking on version control in Wiki:
http://rosewiki.org/view/wiki-version-control
TL;DR It looks like we're building a version control system in Federated Wiki: Let's abstract it and put some deep thought into what we need it to do (and what we don't need it to do)
Great and inspirational summary. Happy to discuss that further.
On 5 March 2014 09:05, Ryan Bennett [email protected] wrote:
Thanks Paul!
— Reply to this email directly or view it on GitHubhttps://github.com/WardCunningham/Smallest-Federated-Wiki/issues/194#issuecomment-36718529 .
I just realized, that we maybe don't even need character-per-character Operational Transformation as in @hallahan's Broadcast, but paragraphwise like Gingko with something PubSubHubBub could already be enough. On the other hand, that implies the availability of Transclusion within a distributed patch based real-time version control..
So heavyweight Socket.IO on the one side, RSS dialect PubSubHubBub on the other. Maybe the simple compromise is a de facto standard like Webhooks, in fact a remixed RESTful API, that might need to be rewired to work in distributed environments? People are still waiting for fork notifications.
Another intermediary possibility for bridgin the Operational Transformation and Distributed Versioning world could be Webmentions, if we think of the more important need to provide Fork notifications over real-time concurrency.