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
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.
A while back Cory Slep proposed something where servers could federate out profiles with each other to say what features are supported. I'm not 100% clear on the details (and I'd have to dig through the wayback machine to find the original post), but there's definitely been some thinking in this space already for AP as well
Not my area and I don't know who might be working on it today or what the thinking may be, but it is definitely good work.
My view on this is... sure why not? The devil is in the details, but the actual code in @robin 's post is a valid as2 actor as far as I can tell. The 'over ATProto' part seems superfluous. From the perspective of an ActivityPub client, it's 'just' an ActivityPub Server + feature detection. It's not clear why the 'over' is necessary, or why it would be 'ActivityPub over ATProto' and not 'ATProto over ActivityPub'. But maybe just better to avoid the preposition altogether.
Add comment