# Challenge: Adopt a shared (technology) vision for the Fediverse **URL:** \ **Category:** Commons based social stack\ **Tags:** fediverse, challenge\ **Created:** [March 25, 2022, 10:07pm UTC](https://discuss.coding.social/t/challenge-adopt-a-shared-technology-vision-for-the-fediverse/45 "2022-03-25T22:07:20Z")\ **Posts on this page:** 1\ **Showing post:** 6
**Author:** ![aschrijver](https://discuss.coding.social/user_avatar/discuss.coding.social/aschrijver/32/3_2.png) [@aschrijver](https://discuss.coding.social/u/aschrijver)\ **Post date:** [August 12, 2022, 12:22pm UTC](https://discuss.coding.social/t/challenge-adopt-a-shared-technology-vision-for-the-fediverse/45/6 "2022-08-12T12:22:00Z")
> [@WisTex](#): > > As a relative outsider who has recently become active in the community, I don’t see the lack of a common vision as a problem. The problem is interoperability. It is partially technology vision, and partially a product vision of “what the Fediverse could be”, on both of which there looks to be a lack of imagination in general (though, of course, some projects are wildly imaginative and don’t fit this general label). Wrt technology vision most people look at what is implement… Microblogging apps.. and then move ahead with a “How can I cram my non-microblogging app into this?” approach. As a result no one has looked well at how to really build vocabulary extensions and benefit from the Linked Data aspects of ActivityPub before. Many people - exposed to the complexity that’s increased by protocol decay - fall back on doing things the way Mastodon does them, i.e. post-facto interoperability. Wrt product vision I see people endlessly stuck in talking about Instances, federation, accounts, timelines, and a whole host of features that are 1-to-1 copies of what corporate social media offer. But there is so much more, and there are higher / different levels of abstractions, numerous business domains that can be modeled on the Fediverse. If you consider all the online services on the internet where people interact… they are all forms of social networking. This is a wild potential! > [@WisTex](#): > > It doesn’t matter if you have an open source email client, a proprietary one, a customer relationship management (CRM) system, a ticket system, or marketing system, an autoresponder, etc. The apps are very very diverse and have very different use cases… yet the email still gets sent and delivered to all of these diverse systems. This demonstrates a point made above. The talk about instances and federation we do on the fedi.. those are implementation details. Like mentioning SMTP all the time. In email indeed you have many different uses. [Delta Chat](https://delta.chat/en/) is a good example of how far beyond what most people understand with “email” you can go. Those out-of-the-box uses should be encouraged. This has been and will remain a big part of my fediverse advocacy. > [@WisTex](#): > > ActivityPub and other protocols are vital for making these competing visions work together. If we can get the protocols to the point where it does not matter which app you are using, then we will start getting somewhere. I’ve said this myself for a long time, but recently found that I should revise that so as not to raise unreasonable expectations. ActivityPub does not and will not facilitate this. Broad interoperability like that requires massive and prolonged collaboration across all the different domains that are involved. But that doesn’t mean we can’t come a long way 🙂 The blog posts by Dennis Schubert of Diaspora\* mentioned in [Challenge: Healthy substrate formation for the Fediverse](https://discuss.coding.social/t/challenge-healthy-substrate-formation-for-the-fediverse/63) made me see that it is better to talk about AS/AP et al as providing a Framework with which to become part of the Fediverse. But your interoperability depends how you collaborate with the ecosystem partners in your own and other domains. A great example of a new ecoystem forming and in need of ‘substrate’ is [forge federation](https://forgefriends.org/blog/2022/06/30/2022-06-state-forge-federation/) and I advocate forming an [Ecosystem Alliance](https://discuss.coding.social/t/ecosystem-alliance-strategic-collaboration-to-evolve-faster/89) (of which Social Coding will be a part) to evolve this area. Btw. “federating forges” is a good example of setting your vision appropriately. Federating forges means adding Gitea, Sourcehut, Gitlab etc. to the Fediverse. But what is a “forge”, really? A rather arbitrary collection of online software development tools. A better vision would be to dedicate to “federating software development”, and then you are on the level where Github is also positioning their product portfolio. > [@WisTex](#): > > But my impression is that most fediverse platforms want to promote connecting between instances of their own platform, and being compatible with other fediverse platforms is a secondary priority if a priority at all. And even when they are technically compatible, there usually is little user documentation or interface cues to let people know they can connect to competing platforms. Indeed. It is understandable, as it is the easiest way to start and make progress. Documentation is the eternal tech debt in any software project, always 😄 And the interoperability with other apps, means overcoming the Protocol Decay, more tech debt. And maintaining it continuously as arbitrary ad-hoc interop elsewhere creates breakages. A situation that will become unmaintainable in the future. --- _[View the full topic](https://discuss.coding.social/t/challenge-adopt-a-shared-technology-vision-for-the-fediverse/45)._