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?

@Jon Richter I do need to check out these links, thank you. Broadly, what you're signposting seem to be things that are way more tech than I can afford my own involvement in fedwiki to be. I would need others to hack whatever tools/plugins are needed. Even with the existing standard repertoire of plugins, my experience is that how to use them isn't always 100% transparent to a non-code or non-git geek.

Via Silke Helfrich I'm aware of the German commoning community and would love to know more and discuss. But sadly, I wouldn't want to use any tools (such as <translate>) that are branded 'Google', so the language difference remains a real obstacle.

At first sight, I'm unsure whether

a library of vocabularies based on Wikidata

a network for transfer of means between individuals (Commons API), and

a storage for patterns

is equivalent to the three criteria @Bob Haugen is naming. At first glance, the Commons API is very much simpler than the very diverse kinds of economic (value chain, supply chain, transformation network) interaction Bob is concerned with. It seems to amount to something like a tool-sharing and -booking arrangement for a number of finite, permanent objects. Am I mistaken? Is something much more complex intended in the longer term?

Regarding a library of vocabularies, I think Bob probably has something in mind that is much more like live conversation, rich enough to furnish both context for real-world trade and production commitments, and the infamous quality of 'trust' which we're not supposed to need anymore, since hashchains came into being 😉

With regard to a storage for patterns, I would expect a repertoire of patterns (Alexander-style - is this what you mean?) to be much more complex in general than a simple 'storage' would deal with, requiring specialised writing and reading tools, and display formats. I hope for a specialised pattern-writers' toolbench to emerge in the short-to-medium term. @dilgreen is at work on this. I doubt that 'static documentation', such as Bob perhaps wants to handle, would cover a dynamic, evolving, interweaving collection of Alexander-patterns?

what do we think about the complexity issue? 

@Jon Richter thanks for http://venners.ward.bay.wiki.org/view/complexity-that-empowers

Complexity that empowers vs difficulties that disempowers.

Local/regional economies that we want to generate and manage together will be complex.

Hey @mike_hales , thank you for these detailed reactions to the latest posts. I would love to see the thematic fields you bring up in separate conversations. Should we possibly move those over to the empty gardens of https://socio.federated.wiki and inspect them to their fullest? I feel we're overburdening this thread with details already.

The library of vocabularies is also an interesting question (problem space), where an intermediary like Wikidata/-base can be an interesting answer (solution space).

About the aims of Commons API, I will have to feedback with the developers some time. That might take a while. Currently it focusses on Cargo bikes, while an extension to other time-bookable items is not excluded. Inventaire.io are also working in this domain, yet based on Wikidata. https://wiki.inventaire.io/

And back to federated wiki. It's still a place to conceive what a federated wiki could look like. So we are not bound by the state of the current interfaces, as those are only the current means of investigating how such a federation would work. It is the often accidental, serendipituous moments which produce new ideas and understandings.

This is why the current client is also not the only possible form to visualise the content in the federation.

• https://github.com/rektide/hapgood-reader.htm (outdated)

  • https://hapgood.us/2015/07/05/calling-all-hackers/

• https://github.com/WardCunningham/small-client-wiki

  • http://read.wiki.org/#federated.wiki/welcome-visitors

Which asks us new questions about the generalisations used for plugins, so they can work accross clients. A Web Components approach might be of use here.

The wiki client can consume any data that is accesible via CORS, whyfore it depends on the plugins how they eventually cope with it.

Then what seems hard to convey, is, that federated wiki already is a pattern repository and writing environment with large-scale pattern language processes in mind. As was the first wiki.c2.com. David Bollier and Silke Helfrich used it to collect the material for the freefairandalive.org book in federated wikis, for example, which helped formulating the first patterns of a Commoning pattern language:

• http://makecommoningwork.fed.wiki/view/welcome-visitors/view/make-commoning-work

• http://mustersprachedescommoning.federated.wiki/view/welcome-visitors/view/felder-des-commoning/view/soziales-miteinander/view/sorgendes--selbstbestimmtes-wirtschaften/view/selbstorganisation-durch-gleichrangige/view/selected-plugin-pages/view/lineup-diagram

Please note the new hamburger symbol ☰ at the bottom of your *.federated.wiki wikis, which appeared after the last update, which can make the new lineup diagram visible to you at any time, too.

The graphviz plugin, too, has many ways to visualise your lineups.

• http://federated.wiki/view/about-graphviz-plugin/view/more-about-algorithmic-markup

@Jon Richter Should we possibly move those [themes] over to the empty gardens of https://socio.federated.wiki ? . . I feel we're overburdening this thread with details already.

Seems like things are headed that way. This single thread here won’t hold all the branches of thought in a readable way - and we’re mostly considering things outside my original rationale for posting here, regarding wiki as a possible architectural form for achieving OAE aims. I had been thinking that discussions in this thread should migrate over into fedwiki, with a pod being formed. So in coming weeks I may harvest comments from here, and paste them into a wiki for starters. But I have other things to do short term. I’ll notify progress here.

Regarding social.federated.wiki - I’m not excited by Discourse as a space to dialogue in (rather bulletin-boardish?), and broadly prefer Loomio. However, the fact that the space already exists is obviously good reason to use it. It doesn’t seem to be in very intensive use, am I mistaken on this? Broader than this, is the question of where wiki activists talk about visions and needs. I find the Riot chat space really unhelpful - just a single unrolling thread with no subthreads or searching (in my reader anyway). I am unsure where the best place may be, to have the kind of social and new-economy discussion that’s been bubbling up here, rather than the tech discussions that seem most prominent - the kind of things touched on in your 2013 post on experimenticity.

I accept that the wiki community has deeply social visions (including commons vision and pattern vision) but would be glad to see a forum where the the balance has shifted somewhat towards geeks of another (non coder) kind. Myself, I’m a culture hacker, not a code hacker. My best hunch is, a fedwiki pod (or two) plus Zoom plus either Discourse or a new Loomio group ( but linked somehow within Loomio space, to both OAE and Commons Transition). What views on this?

generalisations used for plugins, so they can work across clients. A Web Components approach might be of use . . . The wiki client can consume any data that is accesible via CORS, whyfore it depends on the plugins how they eventually cope with it.

This is the kind of question that I feel is closest to the purposes of the OAE group? More discussion of this kind maybe? App builders (eg @Bob Haugen ) - what could be achieved with apps built as as fedwiki plugins? What benefits could there be in the characteristic fedwiki UI? How does the (tacit?) protocol of fedwiki compare with or integrate with or complement other P2P protocols like Scuttlebutt, Dat, ActivityPub, Holo? @Jon Richter Has fedwiki been set down anywhere, as a protocol?

@mike_hales

My best hunch is, a fedwiki pod (or two) plus Zoom plus either Discourse or a new Loomio group ( but linked somehow within Loomio space, to both OAE and Commons Transition). What views on this?

A lot of ideas have surfaced in this very interesting discussion. What I have seen happen at this stage of many similar conversations is that people try to move to a different space or spaces and the conversation dissipates and dies, or at least loses a lot of the active participants. The least disruptive (I think) would be new threads or maybe even new subgroups in https://www.loomio.org/g/exAKrBUp/open-app-ecosystem where this thread lives now. Every idea and topic discussed here fits comfortably within OAE.

I would be happy to stay here, if it fits. I like Loomio. But alongside, I would want to have a pod of wiki writers (a) to evolve the exploration through ‘a chorus’, (b) to extract numerous ideas into a net of small pages and (c) to make these more easily accessible outside of Loomio. @Jon Richter does that seem appropriate, given that the Riot chat seems a quite limited format, and discussion is already occurring here rather than Discourse?

I'd be happy to see a fedwiki exploration go back and forth with continued discussion in Loomio. Might be better to start another Loomio thread for it?

That sounds right. Dissipation is something we will like to avoid.

@mike_hales Kudos to discovering the Geosemantik Blog with the Experimentcity article. This was an output heavily influenced by reading through

• [Organized Networks / Organised Networks: Weak Ties to Strong Links](https://nedrossiter.org/?p=371)

• [Organized Networks / Organized Networks: A Guide for the Distracted Multitudes](https://nedrossiter.org/?p=448)

• [Organized_Networks.pdf](https://www.nedrossiter.org/wp-content/uploads/2009/08/Organized_Networks.pdf)

shortly after working on https://publicspaceinvaders.org/ / https://alpha.publicspaceinvaders.org/

Rich text editors are fun!

I'm happy to participate in a process of an "OAE fedwiki happening" around one or two pods (see https://www.loomio.org/d/r7T9o6b2/fedwiki/67 above) where we align on

• OAE related considerations

  • app design patterns: like what was sparked within the Kendraio thread around vf-ui and vf-graphql

  • module generalisations: What is a plugin? What inputs and outputs does it accept? How can we generalise the notion of nomadic models moving between systems and protocols?

• Using Federated Wiki for Value Flows

  • using simple page generation rules (non-code!) to represent an economic network within the web of wiki pages

  • find out how the extensible RDF/GraphQL schema can be fit within the wiki design

• Internationalisation of the discussion

  • indirectly also hooking up with the Germans and trying to find out how they seek to combine economic networks with pattern languages

  • Build an international network of enthusiasts who can see the benefit of combining Federated Wiki, Economic Networks and Pattern Languages for good! Yikes!

The wiki protocol itself is nowhere defined but in the implementations, and generates resonance where it works. Every forked page shows it is there, and sufficiently defined. The closest to a specification are the following, but from an outdated version of the server software.

• https://github.com/WardCunningham/Smallest-Federated-Wiki/wiki/Concepts

• https://github.com/WardCunningham/Smallest-Federated-Wiki/wiki/Federation-Details

• https://github.com/WardCunningham/Smallest-Federated-Wiki/wiki/Story-JSON

• https://github.com/WardCunningham/Smallest-Federated-Wiki/wiki/WireDetails

In agile manner, the code is the documentation.

Where should we take this?

@Jon Richter the Rossiter-Lovink links are very interesting thanks, and join up well with what will occupy me for the next month or so. It’s off topic here, so I’ll be brief. They‘re exploring the practical relationship between network/digital tools & architectures, and the activist making of peer-to-peer society. Classic anarcho concerns but very critical of the equally classic - and today pandemic - anarcho-expressive tendency to the Spectacle of the Event, and the way social media allow bursts of passion to be indulged in without producing enduring new historical practical forms. There’s something here that might form a wiki pod topic. But for the next month or more I have to focus my attention elsewhere, so no proposals from me right now.

Where should we take this?

Somewhere, definitely. Your pod/happening proposals are here on record. They are quite diverse - probably too diverse to pick up all of them - and my own hunches (and those of others) would add to the diversity. So there’s some focusing to do, before a useful happening could be initiated. But it will be a month or more before I can pull a frame on this myself, sorry. Busy elsewhere. 2020 is going to be a heavy one, the world seems to be somewhat complicated this year.

The wiki protocol itself is nowhere defined but in the implementations . . The closest to a specification are the following . . In agile manner, the code is the documentation

I love this principle but it calls for so much hard labour, to learn one’s way into the frame - and excludes those who don’t hack code. Thanks for the quasi-specification wiki pages. I note they’re in tedious-old github hacker space. would be good to have these in a federated rather than an old-style wiki. Surely Ward has compiled such a wiki somewhere?

Yes, let's see first what people are interested here to write about. I guess it will be us for a start, but one never know.

About the protocol side of things, I am not aware of a single place in the federation that explains the concepts sufficiently well. Try these:

• http://ward.asia.wiki.org/json-schema.html

• http://stack.fed.wiki/federating-foreign-servers.html

• http://dev.asia.wiki.org/hacking-federated-wiki.html

• http://earth.wiki.dbbs.co/wiki-openapi-spec.html

  • https://earth.wiki.dbbs.co/assets/earth/swagger.html

And more loosely related:

• http://ward.bay.wiki.org/federated-wiki-design-principles.html

• http://kate.au.fedwikihappening.net/dissertation-over-discourse.html

• http://code.fed.wiki/wiki-design-choices.html

@mike_hales

> This single thread here won’t hold all the branches of thought in a readable way

This sums up the problem with Loomio threads nicely. The Loomio UX was designed with organizations in mind, not networks. It assumes a focus on coming to an actionable decision (convergent social processes) not exploring a problem space from diverse perspectives (divergent social processes). FedWiki is in many ways a better tool for the latter. However, as I think Mike is suggesting, perhaps Loomio threads could be useful as meta-discussion space for a group of FedWiki authors aiming to create consensus documents (ie converge their work)?

a new Loomio group ( but linked somehow within Loomio space, to both OAE and Commons Transition)

If I remember rightly, there was a plan to allow subgroups in Loomio to be under the umbrella of more than one parent group. Did that ever happen? If so, perhaps we could propose a co-parented FedWiki subgroup to the CT folks?

Re complexity: this is a quote from the VSM gang, and I know that @mikeh8 is skeptical of them, but they did not make up the law:
https://wiki.p2pfoundation.net/Law_of_Requisite_Variety

So if the problem space (for me, economic systems) is complex, so must also be the solution. That's necessary complexity.

So it will be good to have simple starting points for new people and also graduated paths to mastering complex reality. Those paths have consequences: can lead to elitism, but if those farther along on the paths help those who want to learn, it can also lead to lots of very competent collaborators.

I don't know how that applies to fedwiki. I'm not there yet, and not yet attracted, but I'm glad Mike is exploring and can maybe demo what he's learned some time.

Hi Bob,

I also don't know how complexity works in the federation. The onboarding experience might be an intentional high barrier, to prepare for the vast lands ahead. Once you're in, you gain some sort of serenity from it. Somehow the pages are self-organising, as paragraphs float freely between them. Refactoring is a breeze in wiki land!

We can also ask the federation for its opinions on complexity:

• search.fed.wiki.org:3030/#/find=words&within=pages&match=and&query=complexity

  • fedwiki.frankmcpherson.net/organised-complexity.html

  • venners.ward.bay.wiki.org/complexity-that-empowers.html

  • ward.bay.wiki.org/spontaneous-complexity.html

Or better like

• search.fed.wiki.org:3030/graph/bundle.html

• search.fed.wiki.org:3030/counts.html

• federated.wiki/alternative-interfaces-to-the-federation.html

?

In the #fedwiki chat Ward keeps on repeating that wiki is supposed to be simple but not easy, which might reflect very well on the hurdles we find here. He proposes a hierarchy of uses¹ which might explain better in which levels users can interact with the system, and which kind of wow/aha-effects it produces along the way.

In the same channel is Eric Dobbs, who compiled a list of factors involved in maintaining complex, distributed systems (for work)². The points try to converge around how the complexity of the system and the social relations around it mutually infuence each other.

¹ http://found.ward.bay.wiki.org/hierarchy-of-uses.html

² http://wiki.dbbs.co/culture-trust-and-reliability.html

Here's a note on fedwiki, in a fedwiki on 'commoning'. Among some other thoughts on digital commons. Just introductory stuff, for lowImpact.org.

I think the idea of FedWiki is great. The ease of editing of Wikimedia, crossed with the power of Git to fork/ branch, sustain multiple versions that test out different ideas or reflect competing interpretations, and then merge if and when consensus is found again.

I too find the existing UX of FedWiki a bit overwhelming. There are a lot of things that could be done to make it easier for new users to keep track of where we are, where we can go, how to go back, what visualization options are available, and how to use the power it gives us to fork and edit.

I think the tech of FedWiki is at the quick-and-dirty prototype stage. They've used a bunch of Node.js and related stuff to demonstrate the idea and let early adopters play with how it could be used. I assume that if the idea has legs, we will see a mature 1.0 FedWiki - or different implementations by other groups - using more robust web tech. I'd love to have a native app version on my desktop, where I can create my own wikipages, and find and fork pages from both FedWiki farms (servers) and other users running the desktop app (or mobile app for that matter).

I like the perspective that you take in easing the users progress through the interface. Providing little visual hints, and a more haptic interface. Not to change it dramatically, but only to add other design patterns that were merely not implemented yet, as other priorities seemed more promising. If we all only came up with a list of design questions that are not yet present in goals.pods.wiki.org/goals-for-federated-wiki.html, I'm happy to steward a process that injects our ideas upstream.

But, then, who's here for the implementation work?

There are two Electron-based apps I have seen in the wild, would you like to test or extend from that?

• github.com/rynomad/wiki-desktop

• github.com/joshuabenuck/wiki-electrified

FWIW The use of Electron again suggests quick-and-dirty prototyping. My old laptop can only copy with so many [copies of Chromium running on it](https://drewdevault.com/2016/11/24/Electron-considered-harmful.html) at a time ;) But if they're available as AppImages, I'd be willing to give them a test.

I don't just want to echo the comments about geekiness, I'd like to propose some real dialogue around what a user-centred approach to a federated wiki would best look like. No doubt someone has looked at this from a (less-techie) user point of view, and I'd like to read about any such reflections. But top for me would be to get a user-centred co-creative design hosting group together, not to decide a design, but to host conversations, as well as an emerging "commoned" design itself.

@Simon Grant (Cetis LLP) I’d like to understand better what you have in mind with a “co-creative design hosting group”? For example, might that grouping/hosting be done inside a family of fedwikis? Coupled with a chatroom, with Mastodon?

As regards “a user-centred approach to a federated wiki”, does this below engage any of what you mean . . ?

The problem I had with creating a (conventional) wiki - which I wanted to do 18 months back, and ended up creating www.foprop.org instead - was finding a wiki farm that would simply provide me with an empty wiki shell, ready to roll (preferably for free). They all seemed to expect me to be a Unix server admin and manage my own software installation, which Im totally unwilling to take on - life’s too short. I’m unsure how to deal with the same issue in fedwiki, where it certainly is possible to easily create a wiki by hacking a url on somebod’s wiki farm ("some geek somewhere", thank you!) - but what are the operational consequences (eg backup, sustainability)? Non-geekily managing a commons of wiki farms may be part of the question?

I’m beginning to understand what fedwiki is good at - new emerging thoughts, enthusiasms, exchanges with other enthusiasts, evolving a complex of ideas, developing something complex in bite-size chunks. Or simply, developing complex systems of connected ideas and info (for example, pattern languages), which demand hypertext and not just simple hierarchies. I find fedwiki a terrific writing/thinking medium. Which is instantly shareable. But quite different from a Google doc, thank goodness (or Etherpad). Chorus of voices, not consensus.

I‘m beginning to recognise the problems people have when unfamiliar with passively reading a fedwiki. Because I’m starting to publish quite regularly now in fedwiki, I’m evolving a help page.

Useful for understanding how fedwiki ticks is Names of things (all the features of fedwiki). Including Project names (= potted history of fedwiki) - though these seem to be stubs right now.

PS: Have we gone off topic? Writing plugins (as distinct from 'writing') is probably where the OAE interest is centred? And the comment by @Strypey about the current quick-and-dirty prototype status of fedwiki?

Hi @mike_hales -- I think you help point to two issues relating to usability:

1. ease of set up and admin for someone like you or me wanting to set up wiki pages

2. ease of use for a contributor to said wiki

You also helpfully start a list of tasks (or whatever they might be better called) with "reading", "recording new emerging thoughts", "developing something complex..." etc. Using my experience from other wikis, I could add "correcting an error", "fixing a link", "adding material to an existing page", "contacting a contributor" etc. etc.

Thinking that some established experience from IT systems analysis and design is still valuable, we could perhaps look at systems design issues for any generic information commons project. Could start with scenarios and use cases, maybe types of user (or personas), maybe several other common established practices -- some helpful wikipedia pages include e.g. Software development process and User-centered design

I mean, there is a lot of methodology for designing systems, some of it helpful, some less so. But there is no need to approach the task of designing information commons (if that may be one helpful way of naming your intention) simply blindfold.

Am a bit over my head in other things just now, so won’t quickly respond I’m afraid. But I ask again - are we now off topic here in OAE, and should this discussion be forked? What do folks think? Is this Commons Transition not OAE? I would t want to lose the tech insights from here.

This thread has been interesting to me because we also want to create something like a wiki to structure and allow people to maintain a bunch of info for local resilience groups in our region.

We have been thinking FedWiki is too wild for our group, and are looking for a good free mediawiki farm. (Or something more familiar like that.)

When you find the good free mediawiki farm, it would be great to know about it Bob. I got stuck at that hurdle.

And yes, pooling data is a different use case than commoning thought?

Meanwhile, there’s work to be done, taming fedwiki ;-) Ward Cunningham is wildly creative I think, but not dangerous-wild ;-)

I've just been made aware of Crabgrass https://we.riseup.net/crabgrass/table-of-contents - any good to you?

Could be, thanks for the tip. First impression: too many features (eg complications). I think we need a very plain wiki allowing group creation, editing, and interlinking of pages.

You are welcome to use http://ventureo.frama.wiki it is a dokuwiki hosted by Framasoft, I created it to develope project for organization. Your organization can get 100,000 Ventureo to do it but it is not mandatory. If you don't want any money, it is fine.

I would be very interested in participating in a real dialogue around a user-centred approach to a federated wiki would best look like. Unfortunately I must reraise your doubt, as these questions are thought within the system, but might not apply to the same kind of user that is imagined.

This interface produces serendipity and unexpected occasions, in which new thought can only come about. What is it that you are missing from federated wiki, should we collect it in socio.federated.wiki (Discourse)?

Else, are you maybe looking for pods.wiki.org/all-about-pods.html?

@mike_hales belated reply: we ended up in Miraheze. Just getting started here:
https://resilience.miraheze.org/wiki/Main_Page

Hi @Jon Richter It's great to have you coming into this thread, bringing lots of fedwiki background. Much of this is distinctly more tech than I can handle (which corresponds to the nature of fedwiki generally, I feel) and I have other things to attend to just now, so it will take me some time to digest and respond to your numerous contributions below. But it's good to know you're tuned in, thanks.

I'm glad you've settled on a wiki farm @Bob Haugen , and started your site. Good luck, La Farge Wisconsin 👍 I have a sense that Miraheze is where I would settle too if I needed a wiki. But I'm unsure. I want to exploit fedwiki in every way I can, because it's such a great fluid writing medium. The things that I thought would need a wiki a year ago (www.foprop.org) are things that I'm happy to put into fedwiki: they're an individual take on things within 'a chorus of voices' fedwiki-style, rather than things on which I would expct a consensus, wiki-style. The main thing that I might want to do collectively would be pattern language. But I doubt that Mediawiki is the best medium for that. I wait in hope that a specialised pattern language platform will emerge, with specialised tools and display formats (including graphs) specifically adapted to patterns and collections of patterns - @dilgreen is working on one.

@Jon Richter thanks for the tip to pods. Clearly a bunch of interesting experiments evolving from fedwiki. Meta-question below...

Likewise @Jon Richter thanks for the pointer to http://pods.wiki.org/all-about-pods.html. I knew about pods and happenings but hadn’t understood before how they work, the roles involved (notably pod leader) and the ways in which rosters can support them or the finer details of assembling a roster. This is great stuff. I begin to see now how communicating and curating can happen within wiki, that there are tools in wiki to support this and that neighborhoods isn’t just a metaphor but can be an actual description of people in a working alliance. The lovely thing about pods is that they are commons - they curate/contribute, they steward/steer/govern (via delegated pod leadership - and maybe some chat outside of wiki) and they enjoy/mobilise what is commoned. I now see that, over the lifetime of a pod, there can be evolution towards an authoritative (or at least agreed) and perhaps beautiful curated page or site. OK, it’s time to get podding! Maybe it’s time to spawn a pod or two out of this Loomio thread?

Hi Mike, sorry for returning late to the party, the end of the year is always lacking a lot of spare time. Which would be the directions you would like to explore through pods?

Are you more into recording your ideas for a Commoning pattern language, as with http://lowimpactcommoning.federated.wiki/commoning-for-lowimpactorg.html

Or explicitly design a pod that aligns around the subjects of the Open App Ecosystem and/or Value Flows, extracts experiments into independent pages and sees how we can mobilise plugins and the linear data flow to represent an economic network? Passing a page between collaborators during different stages of a process comes to mind, where the next in line will add a suitable dose of content and markup+logic to return it to the originating community.

This came as an epiphany to me, when I realised that the data model of wiki pages consists of individual events for every action recorded on it. With events being first-class citizens in Value Flows, this could be a direct match between the data models.

Where could we turn our collective attention to?

a Commoning pattern language

I do have a pattern language ticking away in the background - conformable with the excellent work of Silke Helfrich and David Bollier, but attempting, ambitiously, to include rather more (essentially, the kind of stuff they include in their book - aesthetics, pragmatics - but leave outside of their pattern language framework). It’s slow going but I’m assembling wiki elements in support of this. More anon.

With events being first-class citizens in Value Flows, this could be a direct match between the data models.

That’s a very good starting place, I would say. Adds weight to the option of doing a pod around OAE/ValueFlows issues and wiki protocol/architecture? Not my personal number One option, but a good one for this group? One I’d be happy to participate in, though I might not be the best candidate for convenor.

Going off topic . . . As I noted in another comment, sadly it will be some weeks before I can focus on pod/wiki-happening possibilities, I have a chapter to write for a collaborative project, on activist formations, new economy concepts and the work of ‘transition’. I had thought I could steer it towards issues of digital infrastructure (including ValueFlows). That would be an important connection to make for that readership of ‘social economy’ folks, who are largely unaware of radical production in the fediverse and the force of tools, architectures and protocols. But it now seems like that’s not going to fly. Another time! Rather, I will need to address the difference between ’solidarity’ traditions of ’direct democracy’ (talking about stuff in popular assemblies at various levels) and direct making (hacking) of society-and-economy on different kinds of practical scale (regions, value chains, ’invisible colleges’, aesthetic communities, etc); and the contribution that a distinctive, explicit architecture of commons - and commoning practice - needs to make to this, as distinct from the usual community-organisers’ reliance on ‘social’ values, ‘shared values’ and a rhetoric of federation - which I think is completely flaky. So THAT’s an easy task 🤔 Actually, joins up I think, with the Rossiter/Lovink stuff.

@mike_hales

I‘m beginning to recognise the problems people have when unfamiliar with passively reading a fedwiki. Because I’m starting to publish quite regularly now in fedwiki, I’m evolving a help page

This is a tremendously helpful thing to do! One way to iterate on it
over time would be to find a person you know IRL who has never used
FedWiki before, sit them down in front of it, and watch them trying to
figure out how to use it. If you take notes on what they do and say, and
the explanations you give, they will be invaluable in reminding you of
what it's like to approach the tool afresh, and improving your help
text.

I'm thrilled to see you pick up FedWiki and run with it and I'm pleased
you're finding it useful. Your questions about sustainable hosting are
important and I'd like to see more discussion of organizational models
for hosting servers (with case studies etc) in the OAE, as it guides (or
ought to) how software needs to be developed.

Right now I’m cooking some thoughts on wiki as collaboration infrastructure. Maybe posting here in a week or so. I still have the strong hunch that made me open this thgread, that federated wiki can be a container for ‘open apps’. The more I explore, the more I see wiki’s inbuilt orientation towards mutuality, tacit awareness of collaborators’ activity, and ’toolkit’ ethos focuse don the device-user/wiki-writer. Seems v important to me, in developing cpability for distributed mutualised organising (= commons).

One day, when we’re allowed to be copresent again, I’ll pick up your helpful suggestion about watching a newbie get to grips with the UI!

Thank you @Bob Haugen for pointing me at this conversation. It is only with great delay that I am chiming in, when collective attention has already moved elsewhere.

After reading through the conversation, there are many subjects that resonate with me here. I am "some geek somewhere" (Hi @mike_hales, namely from en.hackenow.de, hosting your federated.wiki farm at ecobytes.net! 👋) and am using federated wiki since about 2013, let's say. The subjects that you bring up have come and went throughout the years. Yet many of the design principles and patterns have stayed, those which were generic and plain enough to sustain thyselves.

From the beginnings I recall some sentences that were spoken in the weekly Hangout (wed. 6pm UTC), and only learned slowly to understand how much this wiki is built on actual human people using it for actual work, together. Oftentimes Ward would sit in the call and report from a pairing session with some person, which led to this insight, or that development. These documentations would often also come with their individual wiki page.

From there it is only pure curiosity which drives the people forward implementing changes to the system. After moving it from a Ruby server implementation (with server-side federation that didn't bypass NAT) to "a bunch of Node.js" and an independent client implementation which only reads the federation and stores to your own server, it already mutated in many shapes.

There are graph visualisations of the search index, static site frontends imitating classical wikis or blogs, React experiments, or the wealth of plugins that has come to live during the years. Yet, all remains built on very simple primitives: HTTP, JSON, CORS and the creative inbetween, protocol and schema.

Federated wiki is finding out what a federated wiki could look like.

The implementation is not finished, neither is the specification. The code and the tool are the documentation, and it does not hide complexity from the users. It surfaces

simple, but not obvious

ideas, which provoke one to retrace paths of writing and reading of others. In which way, one has to experience oneself. Since it doesn't meet the expectations and conventions of the users, it opens up new spaces. We cannot compare it to the high frequencies of social media, where a toot passes by as it arrives, but as a landscape in which contemplative action produces a residue of interconnected texts.

This conversation can now continue in multiple directions:

• What are the technical design primitives in use and how are they employed to provide forkable content on the web?

• Which requirements and stories can the OAE formulate to test an implementation of a federated, decentralised system against?

• Why is the interface of the federated wiki not meeting the expectations, and why that might not be a problem ([1] seek Discoveries)?

• What is it that you are trying to achieve, either with text curation, federation, sharing (of what, data?), and in which situations does this need arise?

From the collaborations of Ward I have witnessed, that they usually sit together for a very limited time-span, and talk in front of a computer, while they write a federated wiki together. Often they capture the gist of a recent event into a series of pages, or curate the notes and pods they created before. The emphasis here is on doing wiki as an act of using it, and not an act of talking about work, as it often happens in conversational interfaces. ([2])

Explain how powerful markup makes federated wiki a place to do work, not just a place to talk about doing work.

Will the threaded interface below help me to select an appropriate comment to respond to, will the context persist? What do I do if my ideas are less conversational, and more structural, how can I represent their interconnectedness?

I'm eager to see what else we can do with the card-driven multi-column layout. Similar small plugins that wrap a visualisation around a simple kind of markup are known from Markdown plugins which display graphs, flowcharts, render mathjax, syntax highlighting, and other interactive gimmicks simply through a filter for the multi-line, fenced code block tick marks.

The visual editors of Ghost, WordPress and Wagtail have all adopted a similar design technique for constructing a page out of independent content blocks. And also, here again, we find place to inject plugins, wrap visualisation around data, and have all this controlled through a simple markup.

All in all, what are the technical innovations that come with wiki, that are not immediately obvious, but sufficiently simple to conceive? Or better: How does its design influence the people that are working with it? That will unfortunately, again, only be knowable to those who participate in the federation. With the federated technologies it shares the notion of decentralisation, which brings us quickly to mesh and dark nets.

Conceptionally wiki is closer to the unhosted movement and Solid, as it is to the mesh networks like dat and SSB. Despite that, the wiki implementation for dat runs fine in Beaker Browser, and happily federates with the web. Tackling the wiki federation can feel similar to wrapping one's head around the implications the semantic web came with:

Fundamentally, however, I think the problem comes down to the fact that the Semantic Web technology stackfederated wiki gets a lot of criticism for not hiding the fact that Reality is Hard. The kind of Big Enterprise software sales that get attention promise to hide the details, protect you from complexity, to sweep everything under the rug.

strangelove.netlabs.org/2014/01/fly-me-to-the-moon/

The complexities that we aim to catch with an OAE do not exist yet, and are yet to be produced. Where a federated wiki does not provide instant satisfaction through visual and interaction incentives, it supports and guides longitudinal research through interdisciplinary discourses, and provides a writing space that is equippable with data visualisations on top of a simple JSON store.

I can see that it is hard to grasp from the outside, which need the existence of a federated wiki fulfills. In short, it is to avoid the fallacy of choosing a neutral-point-of-view, which ultimately led to the admin wars, and greatly directs what Wikipedia can become, and what not. The longer version would have to pass by pattern languages and their influence on Agile, and how the first wikis came about, and what they were missing. This is why in 1997 the idea to a federation of thought ([3] [4]) came about, an idea about folk memory.

In so the information spreads freely between people, and is not orchestrated by a central interest. Here we have an experiment at hands, that proves to be stable and extensible throughout the years. While web development trends come and go, chains split and reunite and plenty of protocols try to reinvent the basics of the internet, the federation of wikis merely grew by writing, by creating contexts, making people meet and exchange ideas in new ways.

This will not conceil the hardship it produces at first. But the technical challenges to serve multiple platforms and devices are simple, in comparison to the fundamental changes in principle that are written within.

Only recently a single developer pushes a lot of effort into refreshing the user interface, so you might want to give it a try again. Just prepend your name to *.federated.wiki (replacing the *) and start writing. Everything else we can take from there.

forage.ward.fed.wiki.org/thought-soup.html

Resources:

1. fed.wiki.org/view/welcome-visitors/view/about-federated-wiki the original introduction

2. forage.ward.fed.wiki.org/view/advanced-work/view/chorus-of-voices advanced work in the chorus of voices

3. c2.com/doc/FolkMemory.pdf

4. ward.bay.wiki.org/folk-memory.html

Matrix:#fedwiki:matrix.org

• hack.allmende.io/s/federated-wiki-introduction with Videos

• hack.allmende.io/s/federated-wiki long reading list

• federated.wiki/federated-wiki-introduction.html my federated wiki farm and findings about it

Not sure whether this is the right forum, but can a fedwiki be used for a knowledge commons that is driven by a reciprocity principle? I.e. people that contribute have free access others have to pay. I like the concept of a chorus of voices, but is it by necessity linked to free access by everybody? Does this question make sense? Is this the right place? If not, where?

It would be rare (unknown?) for a fedwiki to be behind a paywall. I guess a sys admin could assert that over their own wiki farm. But I think it’s antithetical.

Intrinsically fedwiki is a contributor form. I believe it’s possible to run fedwiki on a private server (Jon Richter said so in a recent comment I think), thus ensuring limited access. But why on earth try to put a financial sanction on participation in a commons of labour power? Rather, expel people (close their accounts) or impose sanctions on participants who systematically breach the principles? In the case of a wiki, the former, I guess. This is what commons do, thro commons courts, in their stewarding capacity?

If secrecy is at stake, that’s another matter?

I am thinking of a reciprocity based system: http://commonstransition.org/commons-based-reciprocity-licenses/

Our work is situated exactly in the situation that Michel Bauwens talks about. In the past we have been very open to share but it is mainly large commercial organisations that free-ride on our work. We don't have the critical mass that we can live from donations (and we actually do not want to live from donations). At the same time we want to self-reproduce so we need resources to do so.

It’s hard to police reciprocity in a cultural commons (ideas, discussions). Unless you have lawyers prepared to work for nothing to sue free-rider idea-users who don’t share? It’s hard enough in a material commons where you can see the rustlers stealing the community’s cows or tapping the community’s green electricity. Copyright/intellectual property absurdly asserts property rights of this kind, I haven’t been able to understand how copyleft licensing etc is expected to work in a legal environment of expensive lawyers and dominant capitalist property. Whatever the practicalities may be, though, my sense is that this is way out of keeping with the ethos of fedwiki?

Interesting. We need to choose between the pest and the cholera. Either we give it away for free to large capitalist organisations or we pay for expensive lawyers. Is that the only possible choice? What am I missing? I clearly this can not be it? I hope as a community we come up with better answers then...

There is a third choice - produce the stuff that is needed, strongly cultivate the commons of radical, maker-users, and mobilise it as rapidly and elegantly as possible, in alternative formations of cultural and economic practice, bootstrapping the alternative society. Stay ahead of Bad Actors by being more literate, more agile, more in touch with one another, better informed, more capable in collaboration, more mutually attentive, more kind, more skilful, more capable of going the extra mile, more open-heartedly pluriversal. We may not be able to prevent their access to our media (without enormous costs in defensive labour) but we can deny them participation in our skills and our collaborations. We can do better work with the common means. And we can have better purposes.

I agree with Mike. And I think it's important that we don't hobble ourselves by closing ourselves off or spending time in legal defense mode, as time is of the essence. Although - I guess it depends on if you see yourself as competing with capitalists for a piece of their pie, or if you see yourself working towards a post-capitalist world. If the latter, then I think full steam ahead, organize ourselves and our communities, and don't worry about it. It's more in the organizing than the software, although the software is also necessary.

more in the organizing than the software

I think so. Within OAE, is that a majority view?

the software is also necessary

Infrastructuring is essential for alternatives, and software/protocols/networks/platforms of the right kinds might be pivotal in alternative infrastructure? I'll sign up for that.

>>more in the organizing than the software

>I think so. Within OAE, is that a majority view?

I don't know, there are a lot of people here, and I don't think that has really been discussed.

>it depends on if you see yourself as competing with capitalists for a piece of their pie, or if you see yourself working towards a post-capitalist world.

I should say that I totally understand people also need to make a living, and sometimes that could involve competing in the capitalist marketplace as an entrepreneur or even as a co-op. Or just getting a job, which was my method, since I'm no good at being an entrepreneur. And I know jobs are harder to get these days too. Anyhow, this of course isn't an either-or for everyone, so I apologize for being impatient. I am coming from being reminded recently about the climate threat with some more compelling numbers than I had seen, and I am feeling the urgency a bit more than usual.

No, the federated wiki is built on the Commons, why every page is automatically licenced by its author as CC BY-SA 4.0. Every change of this fact would break the federation. The data model keeps track of the transitions of content between users (neccessary for attribution). Else I could not fork your content.

One could imagine a secret federated wiki farm in an enclosed namespace, only accessible via VPN. An eventual payment model for accessing that private environment would not mean the content cannot exist outside. Any wiki client attached to the VPN/namespace could fork content into the wild. The license in combination with the client-side federation are contagious here.

Higher degrees of privacy can also be reached when using the dat:// wiki via Beaker Browser, and only secretly sharing the links (via encrypted communication channels) to trustful parties that will not share them.

Good commoning work actually tries to work around the reciprocity principle and invent new forms of relations between people.

Thanks Jon for your answer.

I am thinking about some kind of meta-reciprocity. Share with those that share, transact with those that transact. We are in the particular situation where the content that we share has value for commercial organisations; i.e. commercial organisations extract value out of it without necessarily contributing. They are willing to pay for it. At the same time we have a group of individuals that is willing to contribute but not necessarily willing to pay. For us both have value. I do not want to idealise one model over the other; to the contrary, I am looking for ways to integrate models (relational models inspired upon Alan Fiske's relational model theory).

Today it seems that the difficult choice I have is between something like fedwiki which I find very appealing but is, as you say, based on complete openness, and a wiki that can be put in a closed environment. I find that a very difficult choice.

IANAL but I have been a CreativeCommons advocate since it was founded. If your work is on FedWiki and licensed CC Attribution-ShareAlike (BY-SA), then anyone can copy it verbatim, but the license legally obliges them to give the creator(s) credit (attribution), and places their version under the same license. Which means anything they change or improve can be reincorporated upstream, back into your work. These are both forms of reciprocity.

Is this sufficient to avoid:

commercial organisations extract value out of it without necessarily contributing.

If not, can you expand on what you mean by this in the context of your work?

This a meta-question, possible for @Jon Richter and @mike_hales and/or anybody else.

I'm looking for a word or phrase for the general differences between the various interaction/human-experience models of Fedwiki, Mediawiki, Loomio, ActivityPub (eg Mastodon), SSB, etc. Model is too general. Paradigm is even worse.

And also between any and all of those and typical apps which have "users" vs "apps". Actually, I guess Mediawiki and Loomio have "users" and "app", but Fedwiki may not. And while ActivityPub and SSB do talk about "users" and "apps", on another level, AP with personal pubs and SSB do not really have "users", they have agents, as I think does Fedwiki.

I hope this question makes more sense to somebody else than it does to me. I am groping for something that I have not quite grasped yet...

Hmmn, complicated I think, Bob. And a number of concepts involved, not a single descriptor or dimension.

One of the dimensions is moderation and consensus. Mediawiki has moderators, who apply rules for consensus in media content. Fedwiki agent/contributors are free agents, and if there is convergence, it is produced in some other (media) space. In a Loomio group moderation is only informal and in my experience a little rare. In Mastodon (eg social.coop) moderation is variably formal/informal, and variably stringent; social.coop is now learning to moderate its media content formally in ways that were not deployed at its original formation. Leaning also to manage and fund the instance/platform operations.

Another dimension is federation/ownership. The different federal formations (SSB protocol community, SSB pub communities, social.coop tooter community, Mastodon code community etc etc) overlap in complex ways and ‘own’ different kinds of stuff in different ways?

A third dimension is what material kind of stuff the practice is actually managing/producing/clustering around. A repository of code? A released version of an app? A platform (an instance of an app on a server on the web)? Media content on a platform? Collaboration of persons and conduct of social or tech or economic projects via media traffic on a platform? Etc? All of the above? Confusingly, often the latter?

My own hunch (you would guess this I think) is to see things in terms of commons. Rather than ‘agents’ (= a federationist/libertarian notion?) commons are concrete associations of persons whose members simultaneously contribute/curate common-resource content, steward/police/sanction commoner actions and enjoy/mobilise/use (but don’t use-up) the social-materia-cultural substance of the commons, in literate and self-aware ways. Their practice is the ‘dance’ between all three of these continuing constitutive processes. A commons of material stuff (eg food or housing) will do these in different ways than a commons of protocol or code (ActivityPub, Mastodon, GitLab) or a platform commons that co-owns an instance running on a server, and these will differ from a commons of labour power (typically but unhelpfully called ‘knowledge’), which is what I think Wiki and Fedwiki are, as platforms not as codebases. (social.coop too, I would say). ’Associationist’ social and economic movements and groups are commons of labour power too, I would say, if they’re any good.

I doubt that AP or Mastodon, for example, are commons. It would be nice if they were? Mastodon is a typical FLOSS Benevolent Dictatorship, of code? AP may be the same, of protocol. GitHub might have looked like a commons, but Microsoft thought different and bought the platform (not the code) off the previously benevolent owners (if Facebook can make profit from this ‘fake-commons’ business model, why not Microsoft?). Git itself (the protocol), www, etc are more benevolent dictatorships with oligarchic tendencies, espousing values of federation? (Just a guess, this.) This is all complex and hard to evaluate, especially for someone like me, who’s not a coder-participant in any of these. But I suspect commoning will get us further, as a sensitively applied verb-descriptor of practices, than agent will, as a noun (or as a value, which is what it often is?) - especially, a noun that is carelessly used of both humans and code entities.

btw . . in all of the above, I’m not addressing bundles of ‘stuff’ (code etc) and their ‘models’ or even their ‘interfaces’ with users. I’m addressing practices of production and use. So I guess I’m saying, whatever the answer to your question is, it’s a question about practices, not a question about code or apps or designs.

Maybe you are looking for something like platform or protocol?

Stackoverflow brought a new kind of conversation to the table: Choral explanations, which mix wiki and conversation modes. https://hapgood.us/2016/07/12/choral-explanations-and-oer-a-summary-of-thinking-to-date/

Also many ideas in this space here were coined by the IndieWeb. https://indieweb.org/

Or are you looking for something between conversational user interface (chat), wiki and bulletin board/newsgroup? From a technical perspective, what we see here are probably "social" messaging patterns.

• https://en.wikipedia.org/wiki/Messaging_pattern

• https://cycle.js.org/dialogue.html
  

  https://cycle.js.org/img/simple-human-computer.svg

• https://en.wikipedia.org/wiki/Message_passing

https://en.wikipedia.org/wiki/Human%E2%80%93computer_interaction

Or are you more interested in user interface patterns, like card-based composition UIs, as we find them in Ghost, WordPress and Wagtail (and which federated wiki pioneered half a decade earlier ;) )

• https://ghost.org/faq/using-the-editor/

https://docs.wagtail.io/en/v2.0/editor_manual/new_pages/creating_body_content.html#streamfield

• https://wordpress.org/support/article/wordpress-editor/

Or what we get when building on data models for event sourcing (keywords: ActivityPub, CQRS, Task-focused interfaces)?

• https://blog.oasisdigital.com/2014/task-based-user-interfaces/

• https://blog.oasisdigital.com/2015/introduction-to-event-sourcing-and-cqrs/

These are terms that were partly derived from the domain-driven design (DDD) world. And 🎉 we have a wiki for that!

• http://ddd.fed.wiki.org/

But I think you were more asking for some socio-technical description of the way how these interfaces, protocols and platforms reproduce performatifity for the user.

Maybe you are looking for a more artistic interpretation of your question's context?

• https://conditionaldesign.org/manifesto/

• https://roelwouters.com/conditional-design

might have you covered. Or would this be closer to what you have in mind?

http://web.archive.org/web/20170711063332/http://www.wikinomics.com/blog/index.php/2008/03/26/wiki-collaboration-leads-to-happiness/

@Jon Richter thanks a lot for an apt set of links. I'll wade thru and see if I can explain what I am thinking about better after that experience.

Bob, what is it that you came up with, what your original intention was about?

Instead of models or paradigms, were you maybe thinking of (interaction) patterns?

Jon, thanks for the reminder to get back to this question. I got distracted by another project and never got back to conceptualizing this question. But interaction patterns are definitely part of the puzzle, thanks again.