fedwiki

Hi Bob, you can run npm i -g wikiand run it on your computer. That site will not be available to the federation, if you don't take an effort.

The npm module can installed anywhere node is running. Your server, a container, a cloud. If Docker is a thing for you, you can also try the images and compose setups in https://github.com/federated-wiki?q=docker

You can also use it with Beaker Browser on dat. Simply create a local, writable copy of dat://federated-wiki-client.hashbase.io/

Plus the described way to use an existing farm, and spawn a new wiki in it.

The Electron implementations above appear to be very early for now.

I like some of the concepts of fedwiki - but the above and the UX and the general geekiness of it all makes it too exclusive imho - no-one other than a well informed and determined geek is going to be able to follow that process, or even to browse pages effectively... and imho, that kinda undermines the open ideals and objectives... something a lot simpler would probably get better uptake and use and hence deliver greater value

I’m raising fedwiki here as a possible source of protocol/architecture/code/UX insights. I do have a hunch that something fedwiki-ish (with its plugin architecture) could be a way of handling other P2P app ecosystems. There is something good about the parallel-pages UI? There is something good about the way it’s so easy to write and publish pages and sites in fedwiki? And curate many-to-one-to-many neighborhoods?

As @Oli SB notes, the world of the fedwiki browser window is intrinsically complex. My increasing sense is, it’s not code-geeky as such (though there’s plenty of that in the app environment and the culture). Rather, it’s a very complex sense of hyperspace. That’s exactly why I like it, and feel it’s a valuable environment to have so easily available on the web (after many years of pining for the loss of Hypercard) - but I have a pretty good head for complex spaces. That’s also exactly why it’s hard to work within, and many folks may easily get lost in it? So as a general way of handling communication and tool-presentation, yes fedwiki has limits to its potential user base, and yes it does call for determination and skill. The complexity-geek in me is up for that.

Nevertheless . . is the protocol/architecture and maybe code of interest here as OAE principles or resources?

And actually - what do we think about the complexity issue? A complex reality, channelled thro simple-seeming apps, is a world misunderstood? The complexity has to be available to the user, at some level?

Alongside what I wrote about necessary complexity, I do accept what @Oli SB says

something a lot simpler would probably get better uptake and use and hence deliver greater value

It’s both/and? Is that part of the complexity we take on board here, by talking about an app ecosystem?

I enjoy grappling with complex spaces too, but quite frankly FedWiki confuses the heck out of me. I'm slowly learning to appreciate the whole "multiple diverging and converging perspectives" style of coherence/synthesis/sensemaking, and I think that if it's complex you (probably) shouldn't hide the complexity. but I found myself quite frustrated with the way that FedWiki surfaces that information. Complex doesn't need to be obtuse or complicated; you can find ways to present the same information that are more intuitive and travel on higher bandwidth cognitive paths. The FedWiki concept has a number of axes, as I recall:

• Time (revision history)
• People (parallel copies in other people's stores)
• Time × people (revision history tracks forks)
• Vertical space (chunks of a document)
• Horizontal space (cards to the right can take data from their left as input)

This information is rich and useful, but staggeringly combinatorial too. I think the idea is great but more UX exploration is required to make it generally usable.

Yes, all those axes! I’m at an early stage learning the interface. One thing that impresses me is the provision for what is called ‘navigation’ in ordinary webspace, but in fedwiki it becomes something more like ‘active management of context’ - for reading, but especially, for writing and forking. I also have a number of skills still to develop, I think, in handling content editing in the side-by-side (ie multi-context, multi-level) page display. In a tabbed browser.

However, once I’ve put in the hours to acquire skills, I think that the real complexity thing will remain, which is a properly hypertextual, object-oriented space. My hunch is, a lot depends on how carefully writers write and signpost their pages. And furnish specialised context using ‘rosters’. I do have high expectations eventually, of graphic mapping of systems of linkages - visual representation of networks is something some fedwiki folks seem to major on.

Please note that the federated wiki client is not conceived as a 'browser', a mere passive, consuming entity to ramble through the webs. It implements the idea of a read-write web, in which the content along my paths turns into a remixable whole. Why some also think of Xanadu when thinking of wiki.

It performs best for me, when I put several browser windows, at least two, next to or on top of each other and the many tabs allow switching between multiple lineups (= a series of pages displayed in a row), quickly forking content from one page to the other (by dragging the flag of a page onto another client window, that will retrieve it via CORS).

The pure existence of wiki does not mean it needs to fulfill every user need. The outside world still exists, and can very much help to guide one into the federation. Chats are still useful, and forums alike, for the purpose they serve. Which purpose do you see for a federation of wikis?

Replying to @mike_hales @Jon Richter and a few other people, thinking of fedwiki as a potential OAE substrate: I suspect different people here have very different ideas about OAE, but @Lynn Foster and I are thinking about components for federated economic networks.

Those networks will need a combination of social-network interactions, economic-network interactions, and more static documentation of ideas as in wikis.

Could fedwiki extend to include all of that spectrum? Some of it, but as a networked component with those other types of interactions? Or does it need to be its own network (altho probly connectable by hyperlinks to and from the other stuff)?

It is interesting for me that you bring up this trivium of components neccessary for a network to work. It mirrors the strategy used in a concept for 'transpersonal commoning' that is currently being written at a german commons blog. What they currently want, is in fact a library of vocabularies, based on Wikidata (similar to what we did at base.transformap.co), a network for transfer of means between individuals (Commons API), and a storage for patterns of good collaboration.

https://git.fairkom.net/transcomm/transcomm-concept/wikis/interfaces

In the past year I have taken some time to writtingly introduce them to the Value Flows vocabulary and the general idea of Linked Data, which mirrors many of their approaches. Even their visualisations resemble the graphs that are derivates of the economic networks that can be drawed. This page links all places in which they published them:

https://git.fairkom.net/transcomm/transcomm-concept/issues/34

If you are interested in giving Google Translate a try, the articles and a wealth of blog comments can be found at

• https://keimform.de/2019/ein-softwarekonzept-fuer-transpersonales-commoning-grundlagen/

• https://keimform.de/2019/ein-softwarekonzept-fuer-transpersonales-commoning-commoning-prozesse-prozessanalyse-taetigkeitsmuster/

In these conversations, I came to reason about the similarities and differences of federated and peer to peer networks, with special focus on how Federated Wiki seems to reflect some of the ideas present in the Unhosted.org or IndieWebCamp movement, i.e. one server per person and a generic JSON-over-HTTP API, and how in return that is similar to how Solid presents storage and identity abstractions to the user.

With the linear data flow of plugins from left to right, we are able to draw combinations of multiple datasets. You might wish to make yourself comfortable with the documentation of plugins, to see what they can do for you.

http://plugins.fed.wiki.org/managing-lists-of-plugins.html

Lately the tooling to inspect the flow of data has been improved for debugging, which might be of interest later:

• https://www.npmjs.com/package/wiki-plugin-diag

• https://github.com/joshuabenuck/wiki-plugin-compare

• https://github.com/joshuabenuck/wiki-plugin-specs

Simple examples from past experiments in the federation are:

• Lineup diagram and multiple maps in one map.

• Combination of elementary graphs into an overview.

Pages in federated wiki can be generated and kept in numerous ways. You can import a site backup, you can fork a page, create it anew, or fork one to your server from local storage. There is a dat variant that can live and mediate between both networks, some have written a Holochain implementation, and in the early days a version with transport over NDN existed.

From outside we intake data through so-called Transporters, effectively lambdas/serverless deployed functions, that take a command and will reply with a federated wiki page. There are different transporters for different use cases:

• A transporter to generate HTML image markup from dropped links to images.

• A transporter to convert Wikipedia pages into wiki pages. (LiveCode, unpublished)

http://port.fed.wiki.org/finding-and-writing-transporters.html

Inside we like to keep data close to the plugins, either as inline markup, through the JSON plugin or as an asset.

• http://plugins.fed.wiki.org/about-json-plugin.html

• http://plugins.fed.wiki.org/about-assets-plugin.html

• http://plugins.fed.wiki.org/about-force-plugin.html

Please see [Abstraction of Method / Plugin Lifecycle / Common Markup Practice](http://plugins.fed.wiki.org/view/welcome-visitors/view/about-plugins/view/abstraction-of-method/view/plugin-lifecycle/view/common-markup-practice) to learn about the things that are similar for plugins. It might also be good to know, that plugins can have both, server and client components, and may extend the wiki in both places.

@Bob Haugen On the basis of just a couple of months using fedwiki, my hunches on these three criteria are:

Social-network interactions

• Fedwiki is an active author’s environment, rather than a passive reader’s. Many people are confused at first by how fedwiki works for reading - but for regular readers that’s no longer a problem? So, let's say that writing and reading are easy, after the first learning curve.

• Fedwiki has no back channel - comments, dialogues, notifications etc. Other media channels will be needed for this. I think maybe this kind of interaction is excluded from fedwiki's rationale. Edit I was partially mistaken about this - but the means are not obvious. See later comment on pods

• Fedwiki is fabulous for expressing complex sets of thoughts, in smallish bites, connected in complex ways (hyperspace) and linked potentially into many different networks of thought (re-used). It’s fundamentally object oriented. Great for writing in, and building an oevre.

• Great for publishing creative thought, and reading and ‘stealing’ the creative thought of known others, who regularly read each other's wikis in a tight, mutually engaged community. But they must chat, agree, respond, etc using other media: discussion-oriented, threaded, poll-equipped, etc. I believe these are outside the scope of fedwiki, by design. Edit: same correction as above, on pods.

• Each wiki belongs to an individual. There is no ‘social’ space as such. Wikis can't be co-authored. Edit: no, but a pod leader can be nominated. And wiki masters and wiki gnomes can shepherd good content, which attentive writers can find and reuse.

So, not great for social-network interactions of a commonplace, casual, twitterish or facebookish kind, or a Loomio kind. Good for mutual publishing between fellow enthusiasts on some topic, and spinning complex webs of thought. Edit: also, for very serious, mutually attentive collaboration.

Economic-network interactions

• Any page can have any number of plugins, and a coder can write custom plugins, ad infinitum. Good for calculating. And other kinds of processing.

• A plug-in on a page can access data on adjacent pages, and put its results into a ‘pipe’ of any number of downstream pages’ plugins. Can do quite complex stagewise calculations. But maybe the page-by-page nature of a pipe would make the lineup unwieldy for calculations of many stages?

• In the first application of fedwiki (Nike), Ward used it to carry out simulations, where repeated sets of parameters are input to a pipe of calculation plugins, generating and displaying numerous calculated outputs. Handy in economic contexts?

• I have a hunch the object oriented basis of fedwiki makes it better suited to ad hoc custom assembling of processing sequences (problem solving?) rather than as a 'factory' of standard calculations, where a stand-alone app might be better suited. But I could be wrong here. 'Factories' and 'transporters' in fedwiki are designed for repetitive handling of transformation processes. @Jon Richter what would you say?

• I don't know whether fedwiki can take a constant data feed from external sources? I'm aware that some of the uses of fedwiki involve 'scraping' data batchwise from external sources. @Jon Richter can fedwiki dynamically update data on pages on an automatic basis from external sources, or does it expect to be 'told' by a user to collect data from 'x', where x is a page in the lineup?

Static documentation

• Fedwiki is fine for this, if you're happy with individual authorship. It's very good at holding many differing frames in rather small wikis, which are then interwoven and cross-bred thro cross-linking and forking/stealing.

• As for collective authorship, I don't know yet how this works for fedwiki veterans. Ward has an expectation of 'a chorus of voices' which, over evolutionary time, may lead to a common wisdom via the mutual curiosity and tacit mutual engagement of many authors. But there's no machinery for collective authoring. I think an authoritative page could only be created by the community of author-peers agreeing, in some other medium, and authorising a single author to write that page.

Overall . . I guess a lot lies in the balance of importance between the economic processing/modelling and the social interacting. The former maybe could outweight shortcomings in the latter. The balance of the decision whether to use fedwiki would then lie with whether folks are comfortable using multiple interfaces/apps for mutliple functions (eg chatting, agreeing). And whether the paralleled display of multiple pages is an attractive and appropriate interface, for interacting with a complex underlying system?