Getting Two sides of wiki together

Someone wrote in Two sides of wiki about the seemingly opposite purpose of _Wikipedia_ and _Fedwiki_: > Thinking about this leads us to the conclusion that there are two sides to wiki (any wiki), both of which are equally important: > - multi-tenanted consensus based writing > - solipsistic federated writing The original example was mentioning a huge problem with the fediwiki approach:

> When you have multiple copies of a piece of information across many folders or domains (they are effectively the same in federated wiki), it becomes unmanageable when you have to keep multiple copies updated.

The article then explored _transclusion_, which is just a fancy way of saying "inclusion" or "pointer to the original", and that it's not the good solution for the purpose of Fediwiki. However I disagree with the observations and the conclusions.

## The problems In my view, Fedwiki is built around the idea of __forking__, or creating a copy of a page and start working on it independently, then showing it to the peers. I may not completely understand the motives (even Federated Writing can't define what it is), but probably it is the total independence of others in the creative writing process.

### What might have been the main reasons behind using forking technique? - Working on an independent copy? - Same title - different content? - Adding content/updating to original? With the intent of merging back? - Segmentation of content? (To support or create Information Bubbles?) The first reason nicely fits the solution. The second could use a __common page reference__ (central or shared) which would contain infinite amount of forks, but this way they would be all collected in one place (and would offer much better merging possibilities than the scattered unconnected forks version). The third would require a __fast, easy, painless way to merge back__, supported by code not manual labour. It would need multiple things, I'll detail later. The fourth aspect would require controlled forks within specific areas, and may require "same title" pages covering "different topics". This could be solved by organising pages not by _title_ but by _meaning_ (by idea, by theory, by object), and controlling tightly how merges happen, and how links prefer the specific bubble sites first.

### Problem of the current method The original idea was implemented as `wiki` `npm` module. This implementation - while containing extremely good features in large amounts - have a few problems in my opninion: - creates infinite amount of copies of the same material (violating _normalisation_ principles), - creates unorganised copies, - create unsearchable copies (same title on infinite sites need full-text searched to be distinguished), - creates wildly disconnected and diverging copies. Also there are other, implementational problems: - hard (or impossible) to get full history of a page with authors, timestamps and full change history - backward (origin) pointers seem to be more-or-less available, but may be easily broken by sites removing specific Items or their versions - there seem to be no forward pointers, which would be essential to maintain updates of forks - this also cause no forward notification possible, so forks can't be notified of changes (but forks could still ping origins backwards) * working state of links is highly dependent on the neighbourhood state of the moment, and can change from session to session. And the largest problem is - __there is no merging back.__

### Response from the Fedwiki community about these problems The mainstream answer were along the line of: - we wanted it this way (maximal independence of pages), - we already got used to it, - we can do it manually, - we discuss it in person/video chat (out of band), - we care way more about the writer than the readers, - some of those *can* be done in a hidden/non-trivial way, - we like surprises (instead of consistence/reliability). ## Mergeback I believe my two most important missing features of the _current_ Fedwiki are 1. fully connected forks with source, author and timestamp, and 2. easy merging back. For the first, I would imagine:

### Every page with the same title would be somehow connected. Both "same title" and "somehow" is open question. _Same title_ should rather mean __same object__ or __idea__, much similar to Wikidata entities, which are not connected to _words_ but _ideas_, like "Kingdom of Hungary" (1840) is a different object from "Hungarian Republic" (1995), which is also different from "Hungary" (2011); like "Hungarian" (language) is different from "Hungarian" (person) or "Hungarian" (attribute). Maybe that's too much added complexity, but a possible way to unify across languages and imperfect words/language. (Not to mention that Pages optionally could _actually reference Wikidata entities_ to connect to very precisely defined theories, objects, ideas.) _Somehow_ is preferably also federated, like every origin and every fork maintaining its First Origin (as an universal object indicator [think like GUID ]) and immediate parent and descendants (basically a DAG), so the fork tree always could be created and view. Also it can be one central server recording all the forks of a page. So anyone interested in __X__ would pull up the Tree of __X__ and be able to browse the forks, or do whatever they please to do with them. Also it would be obvious how the forks are related, so if anyone looks for the most recent version of any given object it would be easy to find leaves, and find the one with the most recent timestamp. (Forks could be grouped by domains, or tags, or anything if one needs to actually mark the Information Bubbles, though I don't think it'd be necessary.)

### Easy merging back To prevent information explosion there should be an automated, simple, machine-assisted way of merge-back. Merges require some well-known practical functions: - finding the original-fork relation (that's zeroth step, or call it pre-requisite) - seeing exactly the difference, clearly showing what and how changed - offering the possibility to merge whole document automatically if possible - when whole merge isn't possible due to conflicting changes, offering merging changed _Items_ in whole if it's possible - if that's not possible, offering merge strategies assisted with machine help as much as possible (while Wikipedia for example only offers "merge the text manually" at this stage, but it isn't good enough) - also offering the possibility to not to merge but _append_ the Items, or the Document to the original, preserving original state for example. Merging back would "destroy" the fork, or rather unify again it with its origin, lowering fragmentation and divergence. There is two (non mutually exclusive) way to start a merge: 1. Merge happens when original author gets notified (or become aware in any way) that their page was updated. It provides complete independence in the merging process but requires the author to thoroughly examine and manage the merging. 2. Merge gets created when the fork author decides to merge back, knowing their own changes; they prepare a merge and notify the origin; the origin still decides whether to merge but the merging is already prepared, only have to be accepted, rejected or manually modified if the author wished so. (This is basically describing the _pull request model_.) This would preserve independence of the original authors: they decide whether they merge or not, and what and how to merge. It may pose a risk of malevolent forking notices or malevolent merging offers, but software could handle this gently, using unobtrusive hints, for example, as that someone have requested a merge on a page the author wishes to modify. And on a separate page provide a _waiting merges/PRs_ list which can be seen as the author feels fit (or ignored at will), without disturbing creative processes. Same goes, naturally, for the fork authors' protection. They would be notified if they want to work on a fork which was modified since in the original. (And all these "realtime" unotrusive notifications could be clicked away and ignored forever for that specific fork (or all forks for that page).) Origin authors would have the option to set a page, or a whole site to "independent", meaning they do not want to know about the forks and usually do not intend to merge anything back. They would not get fork-changed page notifications and they wouldn't look at the _changed forks_ status page anyway. Fork authors also have the possibility to mark the page as "Not For Merging", signaling that they do not intend to merge back, they intend to create a "hard fork" or an independent page, so all the warnings - both ways - would be silenced. These pages could be merged as any else, but there would be no origin-changed (and possibly fork-changed) notifications.

## Why not "transclude" or "fork-protect"? Transclusion means I have a document where parts are not mine. Its is working well with a frame already (and indeed there could be a transclusion Factory much like than a proxy now), but I believe it is against the original Fedwiki theory of owning the whole copy. Fork protect would mean that parts of the text are not forkable but can only be edited locally. Since local editing is almost always forbidden (and creating a globally managed local edit frameworks seems like a lot of work for little gain) I do not think it would be better than having a fork actually phone home and tell that a merge (_pull request?_) is waiting.

chat.openai

There are a few ways to bring together different Perspectives on a topic that may be represented on Wikipedia. One way is to use the "Talk" pages [⇒ Talk Page] associated with each article. These pages are intended for discussing improvements to the article, and can be a good place to bring up any concerns or issues with the article's content or bias. Additionally, you can also use the Wikipedia's 'References' section that contains the source materials used by the Wikipedia editor to write the article, which can give you a better idea of where the information in the article is coming from and can help you form your own opinion on the topic.

Another approach is to read articles from different sources, including reputable news outlets and academic journals, to get a well-rounded understanding of the topic. Additionally, you can also seek out experts in the field and ask them to share their perspectives on the topic.

~

And what does that mean in the context of Federated Wiki instead of Wikipedia?

chat.openai

Federated Wiki is a decentralized platform for creating and sharing wikis. It differs from traditional wikis like Wikipedia in that it allows for multiple independent instances or "federations" of the wiki to exist and be linked together, rather than having a central authority controlling the content. In the context of Federated Wiki, getting different sides of a topic together would involve searching for and reading different instances of the wiki that cover the topic, and possibly linking them together. This allows for a more diverse range of perspectives on a topic to be represented and easily accessed by readers. Additionally, Federated Wiki allows for easy editing and commenting on pages, so readers can also contribute their own perspectives on a topic and engage in discussions with others.

~

How is this "linking them together" related to transclusion?

chat.openai

In Federated Wiki, "linking them together" can be done through a feature called transclusion. Transclusion is a way to include the content of one wiki page within another, without actually duplicating the content. Instead, a link is created to the original page, and the content is displayed within the context of the page where it is transcluded. This linking together of different pages allows readers to easily access and compare different perspectives on a topic, while also allowing them to contribute their own perspectives and engage in discussions. Transclusion also allows for pages to be easily updated, as changes made to the original page will be reflected on all pages where it is transcluded. In summary, transclusion in Federated Wiki allows linking different pages together, which allows readers to see different perspectives on a topic and easily access the original content in one place, allowing for easy updates and interactions with the community.