===== Interoperability glitches =====

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