The “single source of truth” for our system is the database. We store all significant data there. I guess I’m too pragmatic to see the vision behind what you described.
Your database is only authoritative for local posts, though. Remote objects are just caches. In the case of these collections, they should be represented at their origin and everyone else should cache those collections instead of trying to recreate them locally.
Pragmatically speaking, you get a lot of benefits:
- You can sync the collection if you missed some replies/likes/shares/etc
- You can support “approval mode” for these collections so that authors get to decide what gets included and what doesn’t
- You get a clear signal that the operation is supported instead of assuming or having to guess whether the remote server will do anything with your interaction
I think there are also some problems with this “pure caching” approach though. If you need to have separate representations in your database for local and remote content, it makes it very difficult to process all known content (local and remote) at once.
For instance, sorting all known content according to their recent upvotes (Likes), to show “hot” posts at the top. I think computing such a sorting would be infeasible (or at least much more complicated) if you don’t merge local and remote content in the same representation in your database, i.e. “recreating the remote content locally”. Of course that shouldn’t stop you from updating the remote content once you are made aware of changes, but ActivityPub is made to support that via Update activity, if I recall correctly.
There’s also a matter of potential future protocols. It’s possible that other social protocols will emerge alongside ActivityPub. In that case, it makes much more sense to have an internal representation of all content, local and remote, and then only using the protocols for external communication. Otherwise you’d need special representations for each protocol you use remotely and that would make it even more complicated. In my mind it makes more sense to have an internal representation and then only use ActivityPub for communication.
But uh… maybe this is straying a bit off-topic hehe.
I’m not sure using these collections to indicate support is a good idea - maybe an implementation allows a user to choose whether to publicly publish a likes or even follows collection and such. In that case, Likes and Follows could still be supported even if the collections are not available. An explicit signal would probably be better.
It’s really easy to publish a “stub” collection and we do it all the time, for example when hiding your followers/following, you represent that as a collection still, but you just don’t include the items as a property. Some software like Pleroma even lets you lie and replace the totalItems number with 0. But removing the followers property entirely is a bad idea, because now you can’t tell when something can be followed. Sure, you can have a canFollow property, but there’s a reason ActivityPub didn’t do this – it’s a bad idea. You don’tneed to explicitly declare that you canFollow, unless you want to do something like declaring who canFollow, i.e. the actor canBeFollowedBy certain other actors. It is “enough” to imply support for Follow activities as long there is a followers collection present (even if it is private or empty).
This logic can and should be extended to the likes/shares/etc collections. If you don’t support receiving likes, don’t declare a likes collection. If you do, still declare it even if it’s private or empty. You can send a Like still anyways, but its side effects won’t get processed.
For EmojiReact support we have an opportunity to simplify things and just say “check for the presence of an emojiReactions collection” or whatever. Not “check for a canEmojiReact property that is set to true” or whatever.
2 Likes
Friendica is a multi protocol system. ActivityPub is just one of the six protocols that we speak natively. This means that we have got a protocol layer for inbound and outbound that stores their data in the database. The frontend then uses the database to display or create posts and activities.
Concerning collections: We store the replies collection URL and we use it to fetch missing posts. The missing of a collection is no indicator a not supporting some activity, since a lot systems don’t create a replies collection. For that reason we support the Pixelfed capabilities extension: pixelfed/app/Transformer/ActivityPub/Verb/CreateNote.php at 0941843fad2b355eeb6966523dc48c6fd233f7c5 · pixelfed/pixelfed · GitHub
P.S.: We support a lot of protocols, but AP is surely the most used one:
1 Like
Submission accepted: fep/fep/c0e0/fep-c0e0.md at main - fediverse/fep - Codeberg.org 
It would be good to write a similar FEP about Emoji objects. In particular, the following questions still don’t have a clear answer:
- Should
Emojiobjects have an ID? - Should
Emojiobjects have anattributedToproperty (I think they should, and in most cases that would be a server actor). - How to de-duplicate custom emojis between servers (content addressing?)
- How to provide an alt text?
I think litepub:EmojiReact is good enough (and I will also keep FEP-888d context file just in case).
I can’t find a live example of fedibird:emojiReactions (is it supposed to be found on Fedibird actors, or on notes?), but this feature is certainly within the scope of this FEP. We can define it later.
Do you have a reference to any of the AP Working Group transcripts (or other WG discussions) where they explicitly advocated using followers as a capability indicator, even if it’s not exposed as a Collection? I don’t remember seeing this mentioned anywhere in the AP Recommendation itself.
1 Like
It seems as if this FEP is based on the existing implementations. This means that we couldn’t simply include this check, since this would break compatibility with the existing implementations.
I wouldn’t like to have such a check for some but not all activities. But for existing ones (like or reply) we can’t easily implement it. So we possibly would need one indicator that would tell that we can rely upon the absence and presence of the collections.
The FEP can suggest feature detection based on the presence of emojiReactions as optional implementation step.
I was working on implementing Like in some software today and thought about this. Out of curiosity, I fetched a Mastodon Note (AP JSON-LD). There’s no collection URI for either likes or shares. Using the logic you’ve proposed, that would be interpreted as Mastodon not supporting liking or sharing that Note. Neither is true in this case given the underlying Status has both likes and reblogs. I assume those were received via AP S2S since this is a single-actor instance.
The absence of a property doesn’t necessarily mean a lack of support. It just means you don’t know — a null value does not mean false.
The real consequence of not declaring a special collection is that it can’t be targeted by an Add or otherwise be fetched for verification purposes.
I think it would be helpful to state that embedded Emoji object can originate from a different server than the actor’s server: #391 - FEP-c0e0: Embedded Emoji can originate from a different server - fediverse/fep - Codeberg.org
In other words, you can repeat reactions made by people from other servers.