I will necro-post on this thread. For a long time, in the context of Groups support for the fediverse I have stated that we need more than just group support bolted onto a microblogging use case. That a paradigm shift is needed, where we recognize that Community is everywhere, and has intricate meaningful relationships to other Communities and actors across the fediverse. A paradigm shift I dubbed..
“Community has no Boundary”
We must design meaningful community spaces, where people in the right social context can communicate effectively and engage in collaborative creative events in safe spaces.
In recent days in various discussions I mentioned the implicit but very detrimental “Big Ball of Mud” anti-pattern to the evolution of the fediverse, that is the result of an incomplete grassroots standardization process.
No one is taking care of the design of the fediverse as a whole.
Here I’m talking about the conceptual design, not protocol plumbing and tech details on the wire. What are we building all of us together? What does it mean to become part of the fediverse? We do not ask those questions enough → we do not focus on the design of the social layers of the tech stack!
By just focusing on glueing our apps together with other apps we are able to duplicate existing corporate social media, and add an extra beneficial sauce of decentralization benefits and richer features sets through basic levesl of interoperability.
This is the topic that has my fascination, the major fedi challenges. What we see and facilitate through the FEP Process is natural organic emergence and discovery of best-practices that are funneled into a standardization process. This is what we want.. a fediverse of cocreation and value exchange between communities.
“App-free computing”
But the problem starts by how we subsequently consider fediverse as just some Ethernet LAN where we attach our plug’n play App device to. Or a wall plug to get to the juice..
Going beyond the limiting abstraction of the app. Another theme I’ve long been advocating for. It is now part of my “working in commons” activities around elaboration of Social experience design (SX) methodologies, and focus on these missing social layers of the Open social stack. Most importantly though, to adopt a design approach that is focused on Needs of all participants engaged in social experiences together. SX provides a form of needs-driven development.
That is a totally different perspective than “I attach my Forum to the fediverse, and now I am part of the fediverse”. The app by app integration approach. Where the represented needs are those of the App developer who wants to push as many features as possible onto the fediverse, but may be less interested how other apps deal with, and what the overall impact is on how social experiences satisfy the Needs of a particular use case.
In the SocialHub community fragmentation discussion the pros and cons of the technical wire implementation of the ActivityPub plugin can be discussed and weighed to evaluate whether it turned out net positive or net negative to healthy community formation. But it a whole discussion after the fact, where ad-hoc coding without design of the social layers / conceptual architecture of the fediverse is now the reality to deal with.
Effectively what it boils down to when you consider the whole fedi dev community as a whole, is that highly distributed teams with different cultures, different programming languages are coding microservices they launch into production, without design for their interaction with others. That can never come beyond a fedivers that just marginally works, imho.