#ThoughtProvoker  

The current fediverse is an evolutionary dead-end for 2 reasons:

1. It has painted itself in a small niche of decentralizing typical social media use cases, by means of post-facto interop and the introduction of protocol decay.

2. Lacking a proper grassroots standardization process, and with the primary mechanism for fediverse extension being only post-facto interoperability, there is no way out.

Congratulations to the early adopters, who managed to "cross the chasm" with their own app platforms. It took true grit to become deep #ActivityPub experts, and plug holes needed for your app, but you have made it. Post-facto interop works in your favor now. You are unrestrained to productively add more features in your app, and put them on the fedi wire for others to deal with.

To avoid fedi to become less and less attractive to newcomers, we must now consider:

“Why do we want to grow the open social web, and for whom?” -- @ben

http://coding.social/blog/shared-ownership/

Shared responsible social web ownership

We strive for an inclusive social web that is by the people and for the people. But how do we guarantee equity and shared ownership?

Social coding commons
100% agree.

@thisismissem

I sometimes feel that I must be crazy, and totally off the mark, as I - and luckily others with me - are saying these things for 7 years now. But it somehow hits a wall of inertia.

It is this inertia in itself, that has started fascinating me the last 2 years, and it is the reason why https://coding.social exists. We have to figure out how to deal with the grassroots social dynamics such that healthy long-term sustainable standards, ecosystems, and online environments emerge and further evolve.

Long ago I took notes on some major challenges that in my opinion hold back the fediverse from becoming The Future of Social Networking. These are all mostly social in nature, and are as relevant today as they were then. But this is also just imho. 😬

https://discuss.coding.social/t/major-challenges-for-the-fediverse/67

Joyful creation for the Social web

We reimagine the social web and cocreate a peopleverse.

Social coding commons

@[email protected] oh definitely, and like, I think part of that is down to the fact that W3C received the first version of each of the specs and went "that's good enough for 10 years", when there were so many unaddressed and incomplete aspects of these specs. The fact that there wasn't actually authn/authz in the original specs should have kept the WG open until that was resolved. Without it, half the spec was basically pointless.

I really hope the activitypub ecosystem can escape the inertia of the existing network and architecture that is widely deployed today. I've said a few times that Mastodon's threat isn't Bluesky, no, it's the next generation ActivityPub app that does microblogging well but built with C2S. That's what will unseat Mastodon from it's dominant position, not a social app on a different protocol that has different features.

@thisismissem

And this time I am the one responding that I 100% wholeheartedly agree with that. Thank you.

(PS. I wouldn't describe it as "unseating" where it comes to the position of Mastodon. This would bring Mastodon in a better position too.. "uplifting"?)

@[email protected] I say unseating, as in, this sort of significant shift in architecture would like be appealing to people who want to use multiple social apps. The cracks would immediately be visible to everyone with the current social app vertical architecture of the fediverse.

Sure, it'd be more microblogging, which is good for Mastodon, but people on Mastodon wanting to use other apps would feel annoyed and want to migrate to gain access to more applications in the ecosystem — where as right now the choice is to migrate from one vertical platform to another vertical platform, which isn't really beneficial to most people.

I think @[email protected] will likely be the person to build the first "killer" C2S app.

@thisismissem @cheeaun

Yes, I agree.

I think the important thing is that we get in a position where the ecosystem as a whole is able to make rational technology decisions that make the most sense and which fulfill clear objectives. But in order to be able to do that we first have to have a clear picture of where we are today, what we have established, where pain points are, and where we want to be tomorrow. Then work strategically along a shared (technnology) vision on ecosystem level, top-down. While individual developers drive experiment and introduce technology innnovations to be incorporated, bottom up.

Who dares imagine the fediverse of 5 years in the future. Or 10. Or ...

Who dares to #ReimagineSocialNetworking?

@[email protected] I think something that is going to be really interesting to explore is that with ActivityPub C2S, it may make sense for there to be aggregator services, which fulfil a role much like "relays" in AT Protocol — essentially a big fat pipe for applications to aggregate data from all their accounts from many individual data servers.

There may even be a need to have a way to have an application when writing an activity to the data server, to be able to say "also deliver this to the relay as a bcc/bto" (a relay could just be an inbox/outbox setup).

@thisismissem

Yes, a whole range of new architecture patterns come within reach. The whole notion of services (and I don't mean as:Service actors) leads into new territories. A service-oriented fedi, or the fediverse of apps & services to not exclude anyone. Services that compose, orchestrate, and choreograph into solutions that serve people's needs. Consumed as social experiences that are entwined into the social web.

That is what Social experience design (SX) is targeting. The combination of:

1. Sustainable free software development
2. Of the future of the social web
3. Taking into account grassroots environment

And where the commons gradually build the foundation upon which it stands, and each of the 3 points above are continually improved.

The old book "SOA Design Patterns" from the good old XML days, still has a completely up-to-date pattern library to guide us along..

https://dzone.com/refcardz/soa-patterns

SOA Patterns - DZone Refcards

Service-Oriented Architecture (SOA) patterns describe common architectures, implementations, and their areas of application to help in the planning, implementation, deployment, operation, and ongoing management and maintenance of complex systems. The patterns in this DZone Refcard are classified into four major groups, and listed in alphabetical order within each group. Each pattern includes a Pattern name, Icon, Summary, Problem, Solution, Application, Diagram, Results, and Examples. This Refcard also covers SOA Fundamentals, Pattern Language, Basic Service Patterns, Architectural Patterns, Compound Patterns, and more.

dzone.com