Loomio
Sat 2 Nov 2019 1:26PM

fedwiki

M mike_hales Public Seen by 140

I wonder whether some of the solutions adopted in fedwiki are more generally useful in OAE. Specifically, I found the UX in fedwiki exciting, fluid and responsive, and I wondered whether Mikorizal's open-value network apps might have that same sense of UX. Interestingly, it seems to me that the UX emerges directly from the architecture, and isn't just floated on top. I blogged a thought on this - here in fedwiki - and would be interested to learn what folks feel about fedwiki's approach potentially contributing in OAE architectures and apps? Are there fedwiki hackers here?

Here's a note on fedwiki - in a fedwiki on 'commoning'.

M

mike_hales Sat 14 Dec 2019 9:10PM

@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?

BH

Bob Haugen Sun 15 Dec 2019 3:43PM

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.

JR

Jon Richter Wed 18 Dec 2019 1:40AM

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.

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:

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.

M

mike_hales Wed 18 Dec 2019 10:02AM

@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?

M

mike_hales Wed 18 Dec 2019 10:15AM

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?

BH

Bob Haugen Wed 18 Dec 2019 4:41PM

@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.

M

mike_hales Wed 18 Dec 2019 4:59PM

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?

BH

Bob Haugen Wed 18 Dec 2019 6:24PM

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?

JR

Jon Richter Fri 3 Jan 2020 11:14PM

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

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.

In agile manner, the code is the documentation.

Where should we take this?

M

mike_hales Sat 4 Jan 2020 11:03AM

@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.

M

mike_hales Sat 4 Jan 2020 11:11AM

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.

M

mike_hales Sat 4 Jan 2020 11:18AM

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?

JR

Jon Richter Sat 4 Jan 2020 4:20PM

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:

And more loosely related:

DS

Danyl Strype Fri 10 Apr 2020 12:09PM

@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?

BH

Bob Haugen Tue 5 Nov 2019 4:29PM

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.

JR

Jon Richter Sat 14 Dec 2019 1:36AM

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:

Or better like

?

JR

Jon Richter Sat 4 Jan 2020 3:39PM

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

M

mike_hales Thu 7 Nov 2019 1:40AM

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

DS

Danyl Strype Fri 15 Nov 2019 6:41PM

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).

JR

Jon Richter Sat 14 Dec 2019 1:16AM

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?

DS

Danyl Strype Fri 10 Apr 2020 12:19PM

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.

SG

Simon Grant Fri 22 Nov 2019 2:59PM

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.

M

mike_hales Fri 22 Nov 2019 3:31PM

@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?

SG

Simon Grant Sat 23 Nov 2019 10:10AM

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.

M

mike_hales Sat 23 Nov 2019 11:01AM

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.

BH

Bob Haugen Sat 23 Nov 2019 12:48PM

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.)

M

mike_hales Sat 23 Nov 2019 1:13PM

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 ;-)

G

Graham Sat 23 Nov 2019 1:44PM

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

BH

Bob Haugen Sat 23 Nov 2019 3:05PM

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.

CP

Christophe Parot Sun 24 Nov 2019 9:48AM

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.

JR

Jon Richter Sat 14 Dec 2019 1:10AM

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?

BH

Bob Haugen Sat 14 Dec 2019 3:13PM

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

M

mike_hales Sat 14 Dec 2019 7:43PM

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.

M

mike_hales Sat 14 Dec 2019 7:52PM

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.

BH

Bob Haugen Sun 15 Dec 2019 2:59PM

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

M

mike_hales Mon 16 Dec 2019 1:14AM

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?

JR

Jon Richter Fri 3 Jan 2020 10:57PM

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?

M

mike_hales Sat 4 Jan 2020 12:28PM

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.

DS

Danyl Strype Thu 9 Apr 2020 12:29PM

@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.

M

mike_hales Thu 9 Apr 2020 12:51PM

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!

JR

Jon Richter Sat 14 Dec 2019 1:01AM

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

PS

Patrick Steyaert Sun 15 Dec 2019 1:50PM

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?

M

mike_hales Sun 15 Dec 2019 3:03PM

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?

PS

Patrick Steyaert Sun 15 Dec 2019 3:15PM

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.

M

mike_hales Sun 15 Dec 2019 4:21PM

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?

PS

Patrick Steyaert Mon 16 Dec 2019 7:38AM

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...

M

mike_hales Mon 16 Dec 2019 10:31AM

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.

LF

Lynn Foster Mon 16 Dec 2019 12:48PM

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.

M

mike_hales Mon 16 Dec 2019 1:07PM

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.

LF

Lynn Foster Mon 16 Dec 2019 2:07PM

>>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.

JR

Jon Richter Wed 18 Dec 2019 1:50AM

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.

PS

Patrick Steyaert Wed 18 Dec 2019 8:09AM

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.

DS

Danyl Strype Fri 10 Apr 2020 12:39PM

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?

BH

Bob Haugen Sun 15 Dec 2019 3:08PM

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...

M

mike_hales Sun 15 Dec 2019 4:09PM

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.

JR

Jon Richter Wed 18 Dec 2019 2:24AM

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/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://docs.wagtail.io/en/v2.0/editor_manual/new_pages/creating_body_content.html#streamfield

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

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

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?

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/

BH

Bob Haugen Wed 18 Dec 2019 1:25PM

@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.

JR

Jon Richter Fri 3 Jan 2020 10:47PM

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?

BH

Bob Haugen Fri 3 Jan 2020 10:56PM

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.