Implement walkaway wikis

[georgeowell]

Me and @christianbundy got a bit giddy discussing how wikis could be implemented. I think it would be really good for Oasis to set a precedent and be the first client to implement basic wikis UX. It's currently something that is missing from the Scuttleverse.

The absolute minimum possible implementation would be public and private wikis that are only editable by yourself.

Then the next goal would be that you could have a public wiki, similar to how events are where anyone can edit. The only question with that is what to do about edit collisions.

[zicmama]

Collision is always an issue when you want to join chains in blockchain... I don't know how do you detect the conflict, but it is mainly a timestamping merge problem... Is it?

I know some people working on the https://berty.tech/ "chat over ipfs". https://www.youtube.com/watch?v=jtAtIsyUn0A (french video on protocol details) They have to deal with the same problem, and uses a kind of lucky algorithm there.

[georgeowell]

Collision is always an issue when you want to join chains in blockchain... I don't know how do you detect the conflict, but it is mainly a timestamping merge problem... Is it?

Yeh It's more just how to present this to the user. It'd be cool if there was a git style flow where you have to fork someone else's wiki in order to make a change. We're just looking for something really simple though.

[christianbundy]

Yeah, if we use the same approach from gatherings (last edit wins) then we end up with overwrites. I think it would be wise to start with personal edits, like #64, and then add multi-user writes when we're super comfortable with all of the edge-cases. It might also be wise to support gatherings before trying to build wikis, since they're well-understood and well-specified by others in the community.

[zicmama]

@georgeowell @christianbundy I am not sure the problem is about forking conflicts... I am thinking that a "wiki" need is relative to a cooperative blog/forum writing, making an "information zone" where hilightened part from each other writings is merge into a more dense and usefull information. Actual solution for information flow is chat, forum, blog, wiki

We need an Information rafinery

Naturally, collective intelligence will rise up from pertinent elected data from all, arange by likes. So the everyone have its own wiki version, based on his selection into others selections.

Interface needs to be like a citation select tool then published and classified in hastags.

That

From %... @... I want to digest into #subject for @me

I am seeing a visual interface like "hashtags relative size cloud" showing inside messages where you can extract citations with highlighter like overliner pen and collect then into your tags

The result would be that collective thinking chat/forum/wiki/blog where insentive could be made with G1/Zen donations (from https://duninter.org blockchain).

Changing relative observing point is what is happening. With blockhains we need to rethink interface and services... And discover better tools maybe

[christianbundy]

@georgeowell Would you mind explaining the exact problem you'd like to solve with wikis? I notice that you removed the issue template, but I think that framing issues as a problem to be solved makes it much easier to whittle down exactly what needs to be worked on.

[georgeowell]

@georgeowell Would you mind explaining the exact problem you'd like to solve with wikis? I notice that you removed the issue template, but I think that framing issues as a problem to be solved makes it much easier to whittle down exactly what needs to be worked on.

I would like to be able to build up and store a collection of information on SSB that isn't in a conversational format and can be referenced back to easily.

I would probably use wikis for:

• Bookmarks
• How-tos
• Lists
• Collaborative documents
• Technical documentation
• Technical support
• Organising events
• Documenting things that happen on SSB

[RangerMauve]

Commenting to get them sweet sweet email notifications as this progresses.

What about adopting a CRDT? There seems to have been a lot of buzz around them lately. Something like Y.js or Automerge

[cinnamon-bun]

Wikiiiiiii :D yes

Agree with @christianbundy that this is a second priority feature while we try to get basic stuff in place. But while we're brainstorming...

I feel CRDTs such as Automerge aren't a good fit here because

• Complexity - we want something simple enough for several clients to implement independently
• Size of data filling up peoples' feeds
• Subjectivity - needs to work well when you only can see some of the edits
• Slow pace of edits - people might make edits and come back online 2 weeks later so there will be large merges to deal with that might need human help

Subjectivity also gives us weird usability problems like: two people won't generally see a wiki page the same way, so how can they even talk about it or comment on it? If you want to publish info for your friends, how can you make sure they can see the same thing you're seeing? How will pages glitch out when some of the edits are missing?

I've been trying to understand Federated Wiki. I think each page has an owner, and you fork pages into your own account to edit them. I don't think they ever merge again, so popular pages end up duplicated into many forks, each slightly different, which feels like getting lost in mirror universes.

What's the simplest thing that would possibly work?

How about

• Each page is owned and edited by a single person.
• Other people can make "pull requests" to submit changes to the page. The page owner can approve/deny them, and is responsible for cleaning up the merged text if it goes wrong (with a git-style patch interface hopefully). The page owner writes the new data into their own feed.
• Changes are published as patches to the previous version (or as complete pages all over again?)
• Wiki pages also can have regular comment threads, as an escape hatch if the page owner is being slow or unfair with the pull requests

This way

• Each page's content is completely contained in a single feed. If you can see it at all, you're seeing the same version as everyone else.
• Since it's in a single feed, it's simple to implement correctly
• Humans do the merging, no need for complicated algorithms
• Some people will emerge as local librarians responsible for curating a pile of pages. You can say to someone "Hey, go follow @ foo if you want info about gardening" and have confidence they'll see everything. I think this tends to happen anyway and making someone responsible for a document will result in better organization and easier vandalism prevention

More details

• Instead of hashes, link to wiki pages by their titles. Easier writing, easier to make bidirectional references, and so you can reference pages before they exist
• Simple wiki-links [[like this]] would point at another page by the same author
• Namespace them [[@aa80789a7:like this]] to go to another author's wiki
• UI should show backlinks also. ("Pages that link here: ...")
• Nice to be able to link to a specific version of a page, or latest. Each document has a plain old one-integer version number. Unsure how to put that into the markup. Hm, this isn't Markdown, ... :/

[cinnamon-bun]

This is 10% of the way towards reimplementing git. I know we have git-ssb already, I just worry that git is too complicated for clients to independently implement.

I don't really understand git-ssb though

[zicmama]

mergin is already treated by https://github.com/grrowl/redux-scuttlebutt ?

[RangerMauve]

@cinnamon-bun Would it be too hard to implement a nicer UI over a git-ssb backend? Like, calling merges and PRs something different and hiding some of the underlying complexity.

Personally, I really like the idea of storing entire pages after you merge changes to avoid having to process a bunch of patches before you can get the latest view (Git stores entire files rather than patches and that helped a lot over SVN which resulted in slow fetching / checkouts).

We could probably embed isomorphic-git into the ssb-server in order to avoid needing a git binary to do all the actual commands.

[georgeowell]

@cinnamon-bun Would it be too hard to implement a nicer UI over a git-ssb backend? Like, calling merges and PRs something different and hiding some of the underlying complexity.

Personally, I really like the idea of storing entire pages after you merge changes to avoid having to process a bunch of patches before you can get the latest view (Git stores entire files rather than patches and that helped a lot over SVN which resulted in slow fetching / checkouts).

We could probably embed isomorphic-git into the ssb-server in order to avoid needing a git binary to do all the actual commands.

Slightly left-field approach but could we use TiddlyWiki? It exports to hmtl or json.

TiddlyWiki is a complete interactive wiki in JavaScript. It can be used as a single HTML file in the browser or as a powerful Node.js application. It is highly customisable: the entire user interface is itself implemented in hackable WikiText.

It could somehow be bundled with Oasis? There could be a plug-in for integration. It could post every revision of your wiki to SSB.

See this thread for my larking about: %tUZBeoFp5fjxUGP6y+ropTHZxOKDW3EjHmTKlAW4RKM=.sha256

[georgeowell]

It's probably better to implement #268 first before we tackle this.