| |
| fediverse-notes-interoperability [2025/12/04 07:35] – created z428 | fediverse-notes-interoperability [2025/12/04 09:00] (current) – z428 |
|---|
| * 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. | * 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". | * 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. | * 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. |
| * 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. | * 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. | * 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. | |
