@everton137 To broadly summarize some of the pain points, a lot of it comes down to how the standard is put together, as well as how it is used.
Most ActivityPub implementations initially looked to Mastodon for examples on how to implement the protocol themselves. However, Mastodon took a number of liberties as First Implementor to declare how things should work, such as: using Webfinger for pulling in remote content, using a field for content warnings that other systems were using for summaries, and not implementing the Client-to-Server portion of the spec.
Part of the problem is that some parts of the AP spec are under-defined, to the point that it’s not totally clear how things are supposed to work by default, as presented in the spec. Most ActivityPub implementations are a revision of what Mastodon first did, and most of these implementations were built against Mastodon for compatibility, rather than a standards-compliant target where everybody could be compatible with everybody else.
This has actually caused a lot of long-term growing pains, as developers have to play whack-a-mole in trying to be compatible with one another. I’ve heard that some aspects of the protocol cannot be easily abstracted into a library in a matter that’s both comprehensive and standards-comformant, and there are a lot of open questions on what a “proper” standard implementation should be for any given ActivityStreams Verb. Most of that stuff is loosely defined, at best.