What's actually in the special collections, causal activity or target object?

ActivityPub
1

From reading the spec and the guide here, I believe it should be as follows:

  • Inbox: activities
  • Outbox: activities
  • Followers: actors
  • Following: actors
  • Liked: objects
  • Likes: activities (type Like)
  • Shares: activities (type Announce)

But I’m doubting this because Liked seems to be described both ways in the spec:

5.5 Liked Collection
Every actor MAY have a liked collection. This is a list of every object from all of the actor’s Like activities, added as a side effect.

5.7 Likes Collection
…
Note
Care should be taken to not confuse the the likes collection with the similarly named but different liked collection. In sum:

So maybe they should all be activities for consistency (i.e. followers/ing are Follow activities)?
Should I expect to handle varying forms from other severs?

2

IMO putting Like activities in that collection is useless because what you actually want in both your database and your UI is the list of actors that liked an object. If these are to be activities, you’d have to resolve every one of these to get the actors — which is a huge overhead.

To prove my point further, I’d like to point out that most implementations, including mine, store both likes and followings as relations, not activities. Here’s the schema for my likes table. And here’s the Like activity Mastodon sends, notice the “ephemeral” ID with fragment:

{
"@context":"https://www.w3.org/ns/activitystreams",
"id":"https://mastodon.social/users/grishka#likes/28393208",
"type":"Like",
"actor":"https://mastodon.social/users/grishka",
"object":"https://friends.grishka.me/posts/12082"
}
3

that’s currently under discussion, there’s no real reason for us to have a fragment ID there except that it saves us from building another route and controller action. while you’re correct that on the database level, it’s a relation, there’s nothing preventing that relation from storing an activity if it’s useful.

4

Thanks, but I’m not concerned with how it is stored (I’m using a denormalized model so it won’t make any difference). I’m trying to figure out what is in the collections when they are federated so I know what to send and what to expect from other apps

5

Thanks for commenting. I see that Mastodon sends actor ids as the content of the following/followers collection. If another app were to send Mastodon a collection of Follow activities instead, would it parse out the actor/object of those activities, or just not understand the collection?

6

(ah, sorry, I was replying to the comment directly above mine, my comment should be read in direct reply to “And here’s the Like activity Mastodon sends, notice the “ephemeral” ID with fragment”. i’ve edited my post to add the relevant quote :D)

Unfortunately, I think the inconsistency you pointed out is just the result of a late editing change in the spec. Since the text from 5.7 is a non-normative note, there is no technical contradiction—the normative text is consistent about describing an object’s likes as Activities and an actor’s liked collection as a list of Objects. it’s regrettable that a note added to help people understand things better actually caused more confusion!

Technically, Mastodon wouldn’t care, since the only thing we actually process is the count of the collection, but i would recommend against it, since it definitely violates both the spirit and the intent of the followers collection. If a collection is made up of Activities, the idea of targeting it as a to or cc property doesn’t make any sense, and there would be no way to specify followers-only or followers-addressed posts. Almost all posts on the network currently are to some followers collection or another.

1 Like
7

I’ve filed a bug on the activitypub repo to handle this errata:

Thanks for pointing this out!