First, I’m still work shopping names and boundaries of what to name, and what to just call a composition. So please, don’t be too confused with me not having a clear naming scheme yet.
Second, this is mostly an announcement of: Hey I’m doing this stuff. So be prepared to digest the ideas behind it, or be somewhat confused.
A bit of background: One of my main peeves with ActivityPub is that it has an implicit storage assumption and an implicit assumption of URIs that reference a JsonLD object can miraculously be resolved. This results in ActivityPub being untestable as it has no clearly specified behavior.
A way to get around the above issues is to instead of viewing the Fediverse as HTTP APIs, is to view the Fediverse as processing messages. This means one needs a protocol that speaks the language of message brokers and not HTTP. So the announcement of this post is something like that:
Yes, I’m a little confused. The “implicit assumption of URIs that reference a JsonLD object” is not really an assumption, it’s a requirement if an S2S id/URI is present in the object (Section 3.1 Object identifiers). I’m not understanding the “miraculous” aspect of it. How “clearly” it’s specified is subjective, but it’s reasonably clear to me.
I think “storage assumption” is practically true, but URI dereferencing can result in an object that is generated on-the-fly, so not necessarily stored.
Looking at the cattle drive description, couldn’t that all be done with a test-oriented AP C2S client (with some special test actor authorizations)?
Creating new Fediverse actors
A Create/Actor activity? This is unusual in a non-test context, but it’s valid AP AFAICT.
Performing actions as these Fediverse actors, e.g. posting, following other actors, or looking up (remote) objects
All this can be done with the C2S API (acting as the actor created by the test actor).
Managing the actors, e.g. updating their profile
Update/Actor?
Deleting the Actors
Delete/Actor?
This would require using RabbitMQ? It’s motivating me to think more about how this could be done with standard C2S, but I’ll be interested in following the discussion.
I don’t think talking about C2S is productive. I’ll just comment, one can transform these things into each other. However, it will require transforming from push based systems into pull based ones (and vice versa). Second, one probably needs some reverse proxy acrobatics.