@oranadoz

The challenge is that the baseline features of activitypub are essentially impossible to build an effective client off of.

It's not just they are defining their own interfaces, it is that they _have_ to define their own interfaces if they want to be even reasonably effective at their chosen tasks at scale because of the limitations on how collections can be dereferenced

There are ways around this with FEPs and such, but it's not in the protocol

@mariusor @helge @risottobias @osma

@hrefna
Moreover, if a protocol as all-encompassing as ActivityPub/ActivityStreams would need to first standardize a feature to the protocol foundations before anyone could implement that feature for their service, absolutely nothing could ever be done. It's hard enough today with so much of what has been defined in the protocol being so vague.

Standards-track RFCs require several implementations for a reason.
@oranadoz @mariusor @helge @risottobias

@osma

One thing that I think that ATProto is doing interesting things with in this space is separating these concerns. Basically by allowing the definition of applications (some would term them profiles) with dedicated semantics for how to declare them and interface with them. So you can define your own (RPCish) methods for actions on top of the protocol.

We could do something similar with AP, but it's a really hard thing to do retroactively.

@oranadoz @mariusor @helge @risottobias