Microbloggoverse entanglement
Not long ago SocialHub featured a long thread about fragmentation of SocialHub discussions due to the forum being federated. My own observation was that “becoming part of the fediverse” was a mixed bag (and on itself a fairly meaningless statement). On one hand we finally removed the member sign-up barrier, so that any fedizen can participate from their own fediverse account. On the other hand the “sense of community” deteriorated and AP-related developer discussions become more dispersed in fragmented fleety microblogging channels than they probably were before, without building an archive and knowledgebase of these discussions.
This morning I happened to notice one such interesting discussion where @jdp23 tried to bring the discussion into SocialHub’s context by adding mention of the appropriate AP actor for the #fediversity category. It did not have the desired effect, and rather served to cause a load spike that may have dragged the forum down (a known issue). Jon writes:
(In a discussion on SocialHub, @trwnh asked what kinds of developer-focused discussions were happening elsewhere on fedi and what the barriers were to bringing them to SocialHub. This is certainly a good example! So, as an experiment, I’m going to try tagging @ fediversity @ socialhub.activitypub.rocks to see how that works.*)
[…]
* EDIT: it didn’t work. In fact it may well. have caused a load spike on SocialHub that made SocialHub unavailable for a few minutes, although it’s possible that was just coincidence. In any case I edited this post to remove the tag to keep anybody else from unintentionally also temporarily crashing SocialHub!
Technosphere vs. sociosphere
For a long time it struck me how the fediverse isn’t designed as one usually designs software. It is more that what emerged in the early days - based on working early ‘prototypes’ that explored the ActivityPub protocol, such as Mastodon - was taken for granted. With a working proof-of-concept that communicated in federated fashion taken as-is, the fediverse was seen as ‘universal wall plug’ for connecting apps and fedizens. Any announcement of a project or product “joining the fediverse” a reason to celebrate.
But what does it mean to be federated?
Today an app-centric development approach determines how the fediverse evolves. The protocol and existing installed base is seen as a technical connection point to code support for. And app developers are focused on bringing designated app features into federation. Mostly first to federate between their own app’s instances and then opportunistically with other apps where there may be interoperability. Every app feature - scoped to the particular FOSS project - pushed onto the wire in this ad-hoc tech-focused manner introduces protocol decay and contributes to “Big ball of mud” and “Whack-a-mole driven development” (retain app-by-app interop against moving targets) anti-patterns that makes the next integration more complex than the one before.
The current fediverse represents a technosphere.
Today we have created a fediverse that allows app developers to advertise their federated product features. The app dev is the primary stakeholder, and their Needs drive development. These in turn indirectly represent Needs of people using their app (“users”) via product development or ‘issue-driven design-by-consensus’ often seen in FOSS projects. The secondary stakeholder group are usually called just “Users”, an easy app-centric abstraction that developers love to use. “Users” do not equate to “Fedizens”. At best fedizens are considered tertiary stakeholder group, but mostly app-centric development considers them to be just potential users. On the app-centric fediverse it is all about the app.
A future peopleverse represents a sociosphere.
The current app-centric fediverse has a measure of success. Social networking use cases of existing centralized platforms have been successfully ported to ‘federated space’. A communication medium resulted, having the characteristics of a Microblogging platform, representing an ‘application domain’. It is fair to say that app-centric fediverse evolution has a viable future. Yet I would add that imho an exclusively app-centric fediverse does not represent the future of social networking (and even stronger I think such ‘technospheric approach’ has no future at all, where we get the fediverse we dreamed of). Above all the approach does not do justice to the promise of the ActivityPub protocol to provide us with an interoperable social graph of addressible actors to exchange meaningful social activities with. And then model anything on top of that foundational technology base. More specifically, to use using domain-driven design terminology, to model ‘business domains’.
SX envisions a peopleverse where the needs of people in their daily lives are central and social networking technologies are supporting them online. SX is a solution development method that - based on the SX Pyramid of perspective - starts to investigate personal needs of all people involved in a solution, and then scales to take inter-personal relationships into account, to ultimately consider how societal constructs are modeled that can satisfy these needs. SX thus rises above app development and includes entire ecosystems and grassroots movements to its scope. Only here a true peopleverse may emerge over time.