scratchpad

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Fediverse Notepad ======

This is a collection of odds and ends I learnt to know while hanging out on the Fediverse, dealing with various ways of social networks outside the walled gardens and enjoying its community while trying to sneak around its various pitfalls. This is not and never will be a finished document but I'll revisit it then and now to add and fix things. Content warning probably should be: Consume with a grain of salt. Some aspects are personal opinions and should be taken as such. This is obviously written keeping my personal context in mind and I have left some notes on that below. In a way I feel like a nest-fouler for that but some things out there at times leave me lost, and in some cases when looking at the time I spend on particular aspects vs the effect it makes, it feels difficult at least.

This is a page continuously updated and reflecting my current state and mood on that topic. Feel free to drop me a note if you think things are completely wrong, missing, ..., thanks.


===== The Good =====

  * Communication between users on different servers arguably works better and is more open than it ever did or was on blogs or in the social media walled gardens.
  * Moving between systems without losing touch with contacts is at least basically possible.
  * Some implementations of Fediverse servers and clients in itself are already fairly feature-complete and usable.
  * Being able to run independent, separated instances without depending on some infrastructure under control of one particular entity definitely has a sweet spot.
  * As the Fediverse is aiming at providing alternatives to walled gardens, there are projects out there right now trying to address most of the current use cases seen in bigger platforms, like image sharing, microblogging, longform blogging, hosting videos and audio files and some more specific use cases.
  * Most of these systems are done (implemented, set up, operated, ...) by volunteers without any pressure, commercial requirements or interests. That by design eliminates a certain set of problems to be seen with other solutions here.
  * Most of these volunteers are enthusiasts. This is a very cool thing and helpful if you manage to get into that flow with some of these people, there's still a lot of this early-web mood of people wanting to do something they firmly are convinced of.
  * In some niches and topics, even excluding the tech/privacy bubble for a moment, it seems the Fediverse now is fairly well established and has a stable crowd of active users communicating and contributing.



===== The Not-So-Good =====

  * ActivityPub as a protocol foundation has quite a bunch of things that are surprising and at times annoying, please see [[fediverse-notes-ap]].
  * Specifically for new and less technical users, a few hurdles make onboarding and regular use challenging to impossible, see [[fediverse-notes-users]].
  * In some cases, a very heterogenous community understanding, brand identity and conflicts between all of this adds to this set of issues, see [[fediverse-notes-identity]].
  * Everything else, and in my opinion the vast majority of not-so-good aspects of the Fediverse, partially caused by some of the topics mentioned above but not only, is about a sheer endless amount of interoperability glitches and complexity side-effects that are tough to avoid, see [[fediverse-notes-interoperability]].
  * Privacy in the AP Fediverse is an interesting topic too, see [[fediverse-notes-privacy]]. 
  * Client choice, just like everything else, comes with its own share of aspects to consider, see [[fediverse-notes-clients]].




===== System specific aspects =====

This is to collect a few insights specifically on certain Fediverse implementations I have used or am using.

Moved here: [[fediverse-notes-servers]]




===== Improvement ideas =====

Random, unsorted, hard to handle yet here we are:

  * Start out with some more generic "Fediverse Support" channel that's available on all federated platforms and to most federated users and make it known, make it a place where a reasonable amount of developers and instance admins hang out and are following up fast enough, even with questions raised by totally new and "untrained" users.
  * Make the FEP process - https://codeberg.org/fediverse/fep - more inclusive and aware not just of technical but of user requirements, especially talking everything related to compatibility between instances. Also, get it to a point where it is more binding and relevant for implementers to honour and follow.
  * For the love of ..., establish a process of maintaining and updating the AP spec itself! Having something like that "in a final version" dating back to 2018 is just odd. A spec that old in this field of technology doesn't "rock". It's just outdated and static.
  * Maybe consider a foundation (similar to GNOME, Wikimedia, ...) to fund focused development on federated projects, specifically end user acceptance and consistency.
  * Make onboarding easy. Currently, picking an instance is both challenging to people - and something that, once done, basically can't be changed due to lack of real data portability. 




===== Related readings =====

  * https://www.timothychambers.net/2025/06/18/113327.html -- there are a lot of aspects in this document and its follow-ups to consider when talking about making a more "user-friendly" Fediverse. Some of them seem worth discussing, some seem quite obvious. 
  * https://deadsuperhero.com/mitigating-the-7-deadly-fediverse-ux-sins/ -- is a response to the previous post, addressing some of the issues, adding other thoughts and ideas here and there.
  * https://overengineer.dev/blog/2019/01/13/activitypub-final-thoughts-one-year-later/ -- thoughts on the ActivityPub procotol by one of the Diaspora* developers. A bit dated but it sheds an interesting light on priorities and focus in the ActivityPub specification process.
  * https://chrastecky.dev/technology/activity-pub-the-good-the-bad-and-the-ugly -- a much more technical article but especially that "Ugly" section is both short and should be noticed.
  * https://arxiv.org/html/2408.15383v1#S3 -- an interesting lengthy study conducted by a researcher in Brazil on the potentials of the Fediverse talking decentralization of communication and power, that comes with some interesting conclusions addressing more of a political and social than a technical and standards-related aspect of things (didn't know the term "techno-romanticism" before).
  * https://privacy.thenexus.today/unsafe-by-design-and-unsafe-by-default/ -- a longer article on Fediverse and technical and social aspects of trying to make the Fediverse a safe place, hindered by, well, technical and social realities.
  

 

===== Personal background =====

Some words on myself for context here, pushed to the bottom because even though it might help to follow my perspective, it shouldn't be priority here at all. Per 2025 I'm in my late 40s. Professionally, I've been into IT ever since the late 1990s, have spent 20+ years building distributed in-house applications and most of the time had a focus on reliability and availability of these solutions, in 24x7 operations. I've been involved into second level support for end users, internally, externally. On a technical level I've touched CORBA, SOAP, Java RMI and REST, built monoliths and microservices and used Java, PHP, Perl and Python for that stuff. I've learnt to suffer from the drawbacks and issues of both centralized and decentralized systems in that context, and I've even more learnt to suffer from user communication in situations in which technically crafted user interfaces failed to meet experts users demands. The last decade I spent as both a scrum master dedicated to getting a very skilled and motivated team to do a good job (which worked quite well) and recently as a project lead in customer environments implementing a specialized software solution focused on information management and retrieval and integration of both old and new, standard and custom systems. 
Personally, I've been on the GNU/Linux/Software Libre train ever since installing Linux for the first time in 1996, reading through the usual documents like the GNU Manifesto, the GPL, the Cathedral/Bazaar document and Stephensons Command Line article and still am enthusiastic about the idea of community-driven technology to be able to leave behind corporate solutions - if there just is "a community" with a reasonably well-agreed-upon set of goals and priorities to pursue, given it's ... just incredibly hard to complete with global companies both determined and funded to do exactly what they currently do. Too, I've seen XMPP, I've seen and been on platforms like identi.ca, Diaspora, GNUSocial or early Friendica, I've seen their aspirations and where they repeatedly, again and again, ended up. And there's a bunch of frustration especially arising from the latter and the community part. It's been growing. When it comes to the Fediverse, I'm somewhere in between having a lot of thoughts and noticing a lot of things that feel slightly odd but at the current stage of my life lack the time to really do anything about it.


===== Comments? =====

Want to leave comments, thoughts, considerations, ...? These pages are write-protected as they mainly serve as my own writepad. Feel free to however leave comments here: [[fediverse-notes-comments]]