@benpate @puppygirlhornypost2 @hrefna @jenniferplusplus @lily That's not to say this isn't a useful and valid discussion, I just don't think these points will solve AP's deeper issues.

@benpate @puppygirlhornypost2 @hrefna @jenniferplusplus @lily

Looking at the key issues discussed, I am not sure I'm thinking in the same direction. These suggestions feel like they're more focused on the UX of implementations, and not addressing shortcomings of AP as a protocol. I am generally aligned with what @jenniferplusplus is saying, particularly the lack of stated goals being the main driver of divergence in implementation. Adding more client capabilities just hides the fact there's no accepted answer here.

@benpate @puppygirlhornypost2 @hrefna @jenniferplusplus @lily

(Long reply follows, possibly breaking your client implementation?)

- Lack of reference implementation. A spec without a reference implementation or usable test suite hands control of the spec to the largest implementer.
- Lack of easy extensibility. A successor needs a clearly documented capability for extensions.
- Lack of opinion on implementation. This is a controversial one, but leads to implementations that are spec-conformant but not interoperable. The spec should provide a baseline set of operations that may/must be implemented upon receiving a message, with a set of expected responses.
- Feature discoverability. When your protocol allows for wildly different implementations, feature discovery is essential to allow interoperability. This allows servers to negotiate for the largest implemented subset of features instead of defensively assuming the smallest.
- Trust at the server level. A server verifies actors it owns, no individual certs. The verification mechanism must be baked into the spec and not left to implementers.
- Batching.
- Doesn't utulise HTTP effectively. ActivityPub mandates HTTPS as a transport protocol but does not mandate use of HTTP features such as response codes. This is a must-fix for operational scaling.
- Client API. C2S is almost impossible to implement. A replacement should be an optional, lightweight, minimum-surface REST API.

@lily @puppygirlhornypost2 @jenniferplusplus @hrefna @benpate One way out of this particular chicken-and-egg conundrum is to provide a reference translation layer or proxying client that will provide compatibility with AP whilst allowing implementers time to migrate. Then you can make decisions about what subset of features to expose without having to burden your protocol with compatibility. Experience with AP suggests to me there's significant value in reference implementations.