> This is yet another platform solution. The problem with platform solutions is that they still present one and only one choice of software.
Friendica supports a ton of protocols, see the "Interoperability" section on the front page.
Regarding ActivityPub, it is good to keep in mind the reality: https://github.com/friendica/friendica/issues/4688
Quoting MrPetovan:
> ActivityPub is a "loose standard", meaning that it doesn't define precisely each interaction. "Supporting ActivityPub" doesn't make any sense, because, per the standard, implementers are forced to make local decisions about how to convey specific features via ActivityPub because of an intended lack of description.
> In this context, you can claim "supporting ActivityPub" and not being able to interact with any other service also claiming "supporting ActivityPub" just because you made different implementation decisions.
> Another angle: Mastodon implemented ActivityPub for internal communication between Mastodon instances. So they designed their usage of ActivityPub according to their specific usage and features since the standard actually encourages you to do so by leaving parts intentionally vague. However, if any other project wants to communicate with Mastodon instances, they will have to know which specific decisions were made for the intentionally vague parts of the standard because you can't just guess.
> It is different from OStatus where interactions were much more precisely defined, so you actually could rely on the standard definition to implement a single connector that would mostly work with most OStatus services because the vague parts were reduced to a minimum.