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.

• 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.

• 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.

• Server implementations provide feature sets that are at times drastically different. Examples:
  • Friendica and Hubzilla (and its clones/siblings) are able to connect to Diaspora* as well, all along with ActivityPub nodes. Friendica is able to connect to Bluesky and a bunch of other systems too. Mastodon and most other newer Fediverse implementations, though, aren't.
  • Hubzilla and its descendents/siblings are the only of these systems so far to feature a kind of nomadic identity that eases the problem of your posts being tightly tied to a particular server.
  • Pixelfed supports, similar to Facebook, Vk, Instagram, a “stories” approach of displaying image posts that disappear after 24 hours. This isn't working for anyone else in the Fediverse so far, and I am not sure post of the Pixelfed users are actually aware of that.
  • On that same page, Mastodon still uses to only display at maximum four pictures attached to a post whereas other platforms support considerably more. There's currently no good way for a Mastodon user to figure that out, neither is there a way for people composing / sending such posts to know that quite a bunch of their contacts might not be able to see the majority of its content.
  • Hubzilla provides web authentication between nodes, meaning if you're signed in to “your” Hubzilla server, any other Hubzilla server will be able to recognize you as a logged-in user and allow you to interact with posts and do communication locally. Friendica does implement this to some point I believe, in Mastodon and most other platforms being logged in to your instance still will leave you unauthorized on every other instance.
  • Effectively, only Mastodon and Pixelfed have a wider choice of stable, reliable mobile clients on Android and iOS. Most Mastodon clients somehow work with Friendica as Friendica is implementing Mastodons client API at this point but some things still don't and some things specific to Friendica probably never will. There also is an ActivityPub Client API standard which apparently hasn't seen much adoption, for whichever technical and political reasons.
• For some services (specifically Hubzilla or Misskey) there's a plethora of forks or descendants out there, on different levels of quality and with rather varying levels of maintenance and community. In some situations, asking more specific questions about the version you are on might end you up in being told that your software choice is already by far outdated and pointed to one of these arcane forks which is set to do all of that right, finally - to find out there's not even a single public instance available and “it basically works even though some features are still rudimentary but feel free to spin your own instance on a VPS”.
• ActivityPub messages are, as far as I managed to figure out, “just” signed, not encrypted. Meaning: Even apparently “private” messages exchanged between individuals aren't really “private” but exchanged between services merely with the assumption of them being “private”. This isn't a secret but something at least from my perspective not stressed enough, specifically when talking about using the software and environment as an at-risk or vulnerable group.
• All along the same line, I have had a lot of different accounts on a lot of different federated platforms. More than once, I cleaned up and deleted posts and accounts. For quite a bunch of these acounts, still, though, I see both my profile and a random set of posts on some instances. This, too, is an obvious thing in a decentralized environment but it also might be interesting to keep in mind: Deleting your data is something that just “hints” other systems to please actually remove this data rather than ensuring it is really gone. (There might be interesting legal side-effects to that but that's a topic of its own I guess.)
• There's no defined way of making communication failures visible to end users. Unlike in protocols such as e-mail (which would leave you at least with some sort of status if a message ultimately failed to be delivered), in ActivityPub there is no standardized way of making a user know that recipients didn't receive a message because of technical issues. In my case, messages from Friendica to micro.blog have been lost for “a while” for a technical incompatibility between the both systems without either the recipient or the sender (me) even knowing things are missing. Hubzilla does rather well making these information more transparent, all other implementations basically fail to expose that. At the moment, there's a reliability issue here, and it's hard to even figure out whether anything is wrong, let alone learning how to address and fix this.
• Lack of a more dedicated understanding of content causes interesting and sometimes unwanted experiences in timelines. Like, with pixelfed talking to Mastodon or Friendica, there's no way to distinguish between an image post that has a comment on it, or a text post with an image attached, or a long-form text post with images embedded so that not just the image itself but also its position in an article flow matters. Pixelfed will blindly display all of these as images with text below. Mastodon will display all of these as text with images attached. Subsequently, a pixelfed timeline or a Friendica “pictures” channel will both contain photographies and artwork (which is desired) and screenshots of operating systems or rage-posts quoting certain news articles and having snippets of the articles attached as pictures and there's no real way to make a good distinction content-wise.
• The inability to see old posts of new contacts, especially if they're on an instance that hasn't been known to ones own instance before, is a re-occurring weirdness. There is a straightforward technical explanation for that, but from a client point of view, this is weird and most likely to work pretty much against every kind of expected behaviour. This seems different for other protocols on the Fediverse.
• Particularly weird situations arise if following people with posts set to be seen by followers only. In this case, too, nature of federation totally seems to clash with the expectation people coming from virtually every other social network will have: No matter whether Tumblr, Instagram, Facebook - “private” profile means you'll see posts once you established some sort of contact relationship with the account owner. This doesn't seem to work at all here.
• Amount of different server implementations with different glitches and different update frequencies can and will increase maintenance burden for everyone else, like, making sure ones own implementation works with the recent version of whichever other server just popped up in federation and caused issues for some users. It's a complexity nightmare, and even worse assuming that a lot of federated projects are driven either by individuals or extremely small teams with very little (time) resources. Some people and teams seem to resort to giving up on full AP / Fediverse compatibility and instead just strive for being compatible with Mastodon which seems to be the most widespread AP server in terms of user and instance count. Not a cool thing if one's on anything else but still something one can relate to, given limited developer time at hand.

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

Moved here: fediverse-notes-servers

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.

• 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.

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 24×7 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.