ActivityDrive: A way to manage a Fediverse application

ActivityPub
1

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:

https://helge.codeberg.page/cattle_grid/cattle_drive/

So that’s CattleDrive now ActivityDrive would just be using CattleDrive to do the relevant parts ActivityPub.

There are now a few things:

  • One can use CattleDrive to build stuff, e.g. roboherd. That version is not completely up to date with the linked specification.
  • One can use this protocol to test stuff. If one looks at the steps underlying cattle_grid’s BDD tests, one can see that most just use this protocol.

So question: Does this motivate anybody to add CattleDrive support to their implementation?

2

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.

3

I agree with this statement, and I think the next version of ActivityPub should be transport agnostic. But I don’t understand the rest of your post.

4

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.

It’s nothing I’m personally interested in.