This is an old revision of the document!

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

The Fediverse lacks some sort of “shared”, agreed-upon identity and some “structure” of whichever sort to communicate that identity to the “outside” world. This causes interesting and at times annoying effects, because that's very much unlike what Mastodon gGmbH does - they do marketing, communication, advertisement in this way or the other which might be a reason for Mastodon (as a brand/software name) being quite a bit more known than Fediverse (as a much more vague term for a distributed communication network). There would be an obvious solution to that problem but in most cases this seems to be addressed or resolved by blaming Mastodon for how they handle things. Which is at least disputable.
A myriad of different server implementations, in different stages of maturity so it's difficult to impossible for an arbitrary user to initially pick one balancing its advantages and its drawbacks. There are some comparison pages floating somewhere out there but even those take a considerable amount of time to dig through and understand to its full extent.
Instance choice is difficult due to a bunch of criterias hard to know in advance. Specifically, servers blocking each other (every type of server) and different features in particular instances depending on plugins / addons / extensions (Friendica, Hubzilla) add to the complexity here.
Moving between instances is possible but just rudimentary. In best cases (for Mastodon and/or migrating between instances running the same software), migrating contacts and taking your social graph and some extended information works. In “worst” cases (like moving to Hubzilla), even this step has to be done manually. Post and communication history is lost in most cases except maybe Hubzilla. Same goes for features such as blocklists for domains or individual users.
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”.
There's no really good way of general “Fediverse level” support for end users especially when it comes down to needs and feature requests. If you have immediate technical questions, in most cases your instance admin will be able and happy to help. For more fuzzy technical questions, like communications noticed to be lost between users on different instances, it gets more difficult and requires a bit more knowledge about project structures, people and their means of communication - yet it's still somehow possible. But at the very least if you are, say, on Mastodon and want to be able to see your pixelfed contacts stories, you're basically lost. At this point, so is the Fediverse promise of not needing accounts on more systems anymore because “everyone just can talk to everyone else”.
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 Fediverse is driven by enthusiasts and most of them are very passionate about what they do. That's a good thing if you manage to chime in and let their enthusiasm come for you. It's slightly more difficult in some cases if requests, needs, reports seem to get into way of this enthusiasm. The best thing is not to be heard, seen, taken seriously. There are worse outcomes which I don't want to quote here in detail but cause me, in example, to stay away from Loops or Pixelfed for an indefinite period of time no matter how good they might eventually get.
The ActivityPub protocol itself has a bunch of drawbacks and limitations I really fail to grasp, even looking at it some years after it's been published. (Which was in 2018, and the fact that apparently there seems to be neither a formal process nor a working group to work towards update versions of that spec is an issue to tackle on its own). To me, the most pressing and confusing ones are:
- Virtually everything is tied to fully-qualified HTTPS URIs, all along with the fact that (except for micro.blog) it's impossible to use a custom domain even on a non-self-hosted Fediverse instance. This is still a total WTF moment whenever I touch back on it. It seems weird start to end. In a situation where most users are on systems they aren't likely to run on their own (and subsequently don't own the domain the system uses), it's hard to impossible to really understand that approach. In the end it seems a commitment to certain actors who benefit from having huge servers and want to make sure that, despite all portability and own-your-data communications, users aren't easily able to “just” take their content and go elsewhere. There would have been prior art to do this in a smarter way, in Hubzilla, at the very least.
- Lack of a proper scenario for backup/fallback accounts or nomadic identity. In an environment where everyone is encouraged to run a small, ideally single-user instance maybe on that Raspberry Pi living in ones own cupboard, services are likely to be less reliable than Twitter or Facebook. There is prior art how to solve this - in Hubzilla. In a sane world, this feature would have been essential, and indeed it's second to top of my list of gaps in the current ActivityPub spec I fail to wrap my head around.
- Lack of real data portability, even though this somehow goes along with the previous topics. There's no standardized way of migrating anything related to your account across random Fediverse platforms. The implementations that exist are proprietary to individual implementations and somehow interoperate here and there (like most platforms except Hubzilla seem to support contacts being imported from and exported to a common CSV style format), but everything else, specifically migrating posts, threads, communications, … do not just fail technically but also already conceptually - as importing big archives with myriads of messages all of a sudden might end up in clashing with the moderation policies on the server the account has just been moved to. At this point, certain completely unresolved core issues seem to shine through.
- Lack of real privacy - in example by adding encryption rather than just message signature.
- Lack of standardization of particular content types, see above. There are some approaches to that but it seems they're way too limited to be used (or just ignored by the implementers, arguably).
- Lack of feedback on communication errors to the end user, see above. In some ways, it feels like ActivityPub is an HTTP based redesign of a lot of things initially designed in e-mail protocols, but without learning the lessons that could have been learnt from looking at 30+ years of e-mail in large-scale deployments.
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.
Community-wise, depending on where you pop up and how you get started, Fediverse itself can be overwhelming and also somewhat unwelcoming. This has improved a bit recently per my perception, but, more or less unconsciously touching the right topics one can end up in nasty disputes all along even ones very first posts out there. From that point of view it somehow sometimes resembles strictly maintained late-1990s mailing lists where you could expect a strong lecture on your mistakes much more than people being mellow or forgiving with those who are new to the party.
Especially if coming from Facebook, visibility settings of posts behave not as expected. No matter whether wanting to temporarily hide all posts ever made from any visitor of ones profile regardless of contact relationship or wanting to add or remove access to individual posts for certain users retroactively - the current nature of federation doesn't seem to handle this at all in any platforms out there (tested on Sharkey, Friendica, Mastodon, Hubzilla).

System specific aspects

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

Mastodon

Started using Mastodon in around 2018. Still having two accounts on there, https://social.tchncs.de/@z428 and https://social.lol/@z428, which I randomly use.

(+) By far the most consistent experience in terms of web interface and mobile apps. Maybe also the federated platform with the most well-polished user experience.
(+) Easy to use without too many bells and whistles that might get into ones way.
(+) Rather widespread and able to even reach mainstream channels that seem inaccessible to other federated services.
(+) Built and - “flagship instances” - run by an organizational structure that doesn't solely depend on unpaid volunteers work.

(-) Limited in feature set, compared to other platforms. In some cases, this is okay from a “less-is-more” perspective, in some cases (like that four-pics-per-post limit) it's annoying. Too, it's a rather difficult decision not to display the software used to create a remote post; this would help predicting quite some interoperability quirks in the current Fediverse.
(-) Rather than using ActivityPub Client API, Mastodon introduced and still maintains a proprietary interface for attaching mobile clients and other applications, making Mastodon-specific tools tied to Mastodon rather than available to a wider Fediverse audience.
(-) Sometimes it feels just as if the Mastodon team also is a bit off when it comes to aligning implementation and design choices with those made by other communities in the Fediverse, even knowing that this is quite a tough thing to handle.

Pixelfed

Stopped using this in February 2025 and haven't touched it ever since. So state of information dates back to this. Things might have changed in the meantime.

(+) Very polished user interface specifically for the image sharing use case.
(+) Portfolio screen is a rather nice feature to present your works.
(+) Supports locations and license for posts.
(+) Some good client apps are available for mobile platforms.

(-) Features sometimes tend to disappear without too much ado or annoucement (see the “memories” functionality that just got lost somewhere down the line).
(-) A lot of features are available but half-baked and/or broken. Even basic ones, such as direct messages, federation of comments on comments, … .
(-) Development has been rather fast initially but at some point seems to have slowed down. Some longstanding bugs haven't been addressed in more than five years.
(-) Export of data is somewhere in between broken and disabled. No way to take all your images elsewhere. Not even talking about re-importing these.
(-) The main developer is a … difficult person, mildly put. Won't go into much more details here but safe to say this makes me stay away from everything he did or does for the time being.

Friendica

Currently my main vehicle to explore the Fediverse.

(+) Connects not just to ActivityPub but also to Tumblr, Bluesky, Diaspora - and a couple of others I don't use. This includes even odd use cases such as posting messages retrieved from e-mail systems / IMAP servers and likewise sharing articles to e-mail recipients.
(+) Mostly supports Mastodon client API so there's a chance of re-using mobile apps like tusky, moshidon or fedilab on here.
(+) Channels allow for providing pretty fine-grained sorting and filtering of posts, similar more to custom feeds in Bluesky than to mere “contact lists” in other platforms.
(+) Community support in most cases is fast and helpful, both talking about instance admins and developers.

(-) Friendica web client, albeit quite improved throughout the last couple of releases, has a bunch of shortcomings and glitches that really feel annoying at times, especially talking use on mobile devices. Some things still are tied to mouse-hover interactions and don't work on touch screens at all.
(-) Although Mastodon client apps are supported, obviously features related to Friendica (such as sharing just to certain connectors or circles) aren't supported in there and most likely never will be. There's as of now no mobile app fully supporting these features.
(-) Oddly enough and then again, some “late additions” to the Friendica feature set aren't available from the Friendica web interface at all. Example here: Setting visibilities to responses to other posts. Using any Mastodon-API-Client with Friendica, this is possible and seems to work but the Friendica web interface doesn't have any way to do so.
(-) In some cases, Friendica has glitches that are extremely hard (not to say impossible) to recover if you're not an instance administrator, such as Tumblr or Bluesky connector getting stuck.
(-) Some limitations that are there aren't obvious. Like, Tumblr posts are mirrored but not responses or messages - because the Tumblr API doesn't support that but still it's not obvious. Same way, Bluesky direct messages don't come through, and Bluesky contacts appear to be in some way different to other contacts in example when it comes to adding them to circles.
(-) In general and unfortunately, it seems Friendica development has massively slowed down the last couple of years. The latest stable release is 2024-12, released in Dec 2024. For a while, there was a two-release-per-year strategy. Now, the current RC, as of writing this in Nov 2025, is dubbed 2025-07RC. In the past, more than once there have been situations of odd errors introduced with one of the releases to keep features broken for half a year or more.

Hubzilla

Been on there for a while. No current account as of now.

(+) Immensely flexible and powerful, much more than just a social network platform. Longform blogs, photo gallery, a tremendous amount of tools for a load of purposes.
(+) Very fine-grained security and privacy mechanisms.
(+) Offers a bunch of features that … should just be around in every other platform. Period. Like nomadic identity, magic web authentication or delivery status overview.
(+) Development seems rather fast and developers seem to respond quickly to inquiries and questions.
(+) Diaspora connectivity is still here, ActivityPub can be disabled if one wants to disconnect from that part of the Fediverse.
(+) Importing content from elsewhere using RSS feeds or other kinds of channels works amazingly well.

(-) No import of contacts from any other platform is possible.
(-) No mobile app for any platform, even though the mobile web view is quite sophisticated.
(-) Stability, maturity of the different apps greatly differ.

micro.blog

Been on there for a while too. Cut ties with the platform over a certain controversy in early 2025.

(+) Paid and mostly supported service.
(+) Lightweight tooling on top of Hugo static site CMS. If you're a bit skilled with Hugo, you'll feel home there.
(+) Supports individual / custom domains so it's easy to take your content once you decide to move. My copy still lives at https://notes.z428.eu.
(+) Connects to Bluesky, LinkedIn, Pixelfed, Mastodon, Threads, Nostr. For some of these not just as in crossposting but also as in pulling comments and conversations back to the posts they've been attached to which is really a sweet spot.
(+) Has a bunch of plugins and is generally quite hackable if one wants to.
(+) Supports import and hosting of old Twitter archives for everyone and import of Instagram archive exports at least if using the MacOS micro.blog app.

(-) Has a mixed and somewhat unclear stance towards Fediverse/ActivityPub by supporting both crossposting to existing accounts and exposing a micro.blog account via ActivityPub.
(-) For micro.blogs very own AP implementation, generally people aim for compatibility first, foremost and exclusively with Mastodon so interactions with folks on other servers might be more or less messy and hard to fix.
(-) micro.blog is somewhat opinionated when it comes to interactions. Coming from the Fediverse, every kind of interaction except for comments is ignored or discarded so there's no way seeing who reshared or left favourites on your posts.

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.

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

scratchpad

Table of Contents