Open georgeowell opened 4 years ago
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.
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.
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.
@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
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
@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 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:
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
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
This way
More details
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
mergin is already treated by https://github.com/grrowl/redux-scuttlebutt ?
@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.
@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
It's probably better to implement #268 first before we tackle this.
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.