activitypub Store local and remote ActivityPub data

We need to store metadata on local and remote ActivityPub objects. Examples:

Local Actor of type Person (user) is following other local user.
Remote Actor of type Person is following a local user.
Remote Note was posted by an actor that a local user is following.

Mix local and remote in same storage? Use a custom entity type? Can we model all of this using a single format?

Dec 21 '19 02:12 nedjo

I would definitely go for a custom entity type.

Some data can be roughly compared to a webmention. When something comes in (e.g. a follow, reply, note from a user you follow), store the data in a custom entity type and then depending on the type, additional actions could happen:

A reply could potentially become a comment (in IndieWeb, the comment just has a reference to the webmention object, this could be the same here).
A follow could just be stored, but a dedicated block/views page could list all your followers.
A note from someone you follow which comes in is tricky: should it potentially create a node so that it automatically comes into some sort of local stream? Or is the stream a list of AP entities which have their own theming depending on the type?
And, even trickier, should the user your follow which just created a post, also become a local Drupal user so we can view the profile? My mind kind of exploded almost on that thought - I don't have an answer for this one yet, I justed wanted to write it down :)

In IndieWeb I have two entity types: incoming and outgoing. My naive assumption at the moment is that this relates to the inbox and outbox:

The outbox entity type is what the local user would 'do' (post, follow, block, ignore) - kind of related with #9 - it simply stores the AP object of say a note which gets the data configured in #7 - maybe the actual full data (e.g. content ) doesn't have to be stored, it can always be dynamically be constructed when needed .
The inbox entity type stores the AP objects which come into the inbox.

Note: since the AP objects would be pretty much the same - I would serialize a large part of the object, with a couple of base fields which store type, uid and other common things, one entity type could still be fine here. A property could be used to determine this was inbox or outbox.

I hope this makes sense a bit - I'm also just dumping things which I haven't fully thought through anyway, but the inspiration comes from the experience I've had with pixelfed and bridgy fed (did a lot of debugging on both to just get them working locally).

Dec 21 '19 15:12 swentel

All this sounds good.

And, even trickier, should the user your follow which just created a post, also become a local Drupal user so we can view the profile? My mind kind of exploded almost on that thought - I don't have an answer for this one yet, I justed wanted to write it down :)

Possibly related: Decoupled User Auth module which "allows you to store users that do not have a name and password."

Dec 21 '19 16:12 nedjo

Ooooh, very interesting indeed!

Dec 21 '19 16:12 swentel

Just capturing some musing...

Possible model would be to use the Message stack for activity objects. Could consider dispatching activities as a custom transport mechanism via Message Notify.

Jan 03 '20 05:01 nedjo

What to do with incoming activity is certainly one of the issues.

For the outbox, and inbox, I'd so far just been working on an Activity entity. What is displayed in an actors outbox as the collection / collectionpage is just the result of a query of all Activity entities that have that Actor entity as the referenced actor (and have https://www.w3.org/ns/activitystreams#Public as one of the values for the https://www.w3.org/TR/activitystreams-vocabulary/#dfn-to).

For the inbox it's the other way in that it's a query on the Activity entities with the actor as the Target. This is complicated by the fact that this is commonly to or cc but could also be bto bcc or even target. So it will probably mean adding all of these to a standardize internal field.

What then happens to the inbox content?

The only one I'd thought of so far was Follow requests. Which can be automatically, or manually accepted (generating an Accept and an internal relationship entity to document it). The relationship entity then used to populate the /activitypub/type/actor_name/followers and used for pushing Activity when the target to or cc is is that followers iri.

From here I'm just thinking aloud, so sorry if it confuses:-

The next most obvious but more complicated might be Note in response to another Note or Article. Which would often be mapped to a comment on a node. I would guess? This is where Mastodon adds the ostatus namespace and properties ("ostatus": "http://ostatus.org#", "atomUri": "ostatus:atomUri", "inReplyToAtomUri": "ostatus:inReplyToAtomUri", "conversation": "ostatus:conversation") not contained in the ActivityPub vocabulary. So you'd have to have some plugin / module that understood that, and was able to make thready comments out of them. Could queue them perhaps for moderation.

Another one that I want to be able to implement is in federating Events being able to set up a group that is following the content somewhere else for the purpose of syndicating it. So the incoming content signed by the followed actor would be Create, Update, Delete Activity of Event object and would be automatically mapped to Node with bundle event and created or update or removed. The owner user in this case can be the person setting this up, and it's assigned referenced to an actor with a iri linking off site).

Incoming Accept to Invitate for example might just want to automatically be processed and increase a field/flag on the target event.

But yes there could also be configurations where you want to not only create a remote activitypub actor/relationship, but have this as a user who could own content. That's where Decoupled User Auth looks very cool.

Churning through all of these I get the feeling that an Activity post to an inbox path for an actor entity what's to create a activity entity, and it's creation triggers an event that other modules can subscribe to and decide what to do with it. Does it need more mediation on behalf of the Activity entity, or module? Trying to build some common use cases I guess will answer?

Jan 11 '20 17:01 ekes