| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| fediverse-notes [2025/12/04 07:10] – z428 | fediverse-notes [2025/12/04 09:47] (current) – z428 |
|---|
| ===== The Not-So-Good ===== | ===== 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. | * ActivityPub as a protocol foundation has quite a bunch of things that are surprising and at times annoying, please see [[fediverse-notes-ap]]. |
| * 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. | * Specifically for new and less technical users, a few hurdles make onboarding and regular use challenging to impossible, see [[fediverse-notes-users]]. |
| * 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. | * 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]]. |
| * 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. | * 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]]. |
| * Server implementations provide feature sets that are at times drastically different. Examples: | * Privacy in the AP Fediverse is an interesting topic too, see [[fediverse-notes-privacy]]. |
| * 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. | * Client choice, just like everything else, comes with its own share of aspects to consider, see [[fediverse-notes-clients]]. |
| * 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. | |
| * Somewhere near the community aspects of things: One of the usual selling points is stating that things are compatible and it's cool that every system can talk to every other system because they're all using the same protocol - until they are not. As outlined before, there's no shortage of interoperability glitches in the Fediverse, and also there's no shortage of that dreaded "works-on-my-software" attitude and people stating that whichever (valid) problems one might encounter or run into are just problems caused by their (obviously stupid) choice of federated software. It all too often boils down to fingerpointing and blaming "the others" for messing up compatibility and being in charge to fix things on their end. | |
| * 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). | |
| |
| |
| 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. | 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. | 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]] |
