| name | kb-fediverse-liking |
| description | Background knowledge about how the Like activity works on the Fediverse and in ActivityPub, including the Like/Undo{Like} flow, the `likes` and `liked` collections, delivery model, the Dislike type (exists in ActivityStreams but is unused in ActivityPub), emoji reactions (EmojiReact / FEP-c0e0 vs the Misskey _misskey_reaction approach), stale like counts on remote posts, and implementation differences across Mastodon, Misskey/Calckey/Firefish, Pleroma/Akkoma, and PeerTube. Load when the user asks about implementing likes, favourites, or reactions; why like counts are wrong on remote posts; how to send or receive a Like activity; how to undo a like; how emoji reactions differ from likes; or what EmojiReact is.
|
| user-invocable | false |
Fediverse Liking โ Complete Reference
Overview
"Liking" a post is modelled by the ActivityPub Like activity, defined in
the ActivityStreams 2.0 vocabulary and given server-side effects in the
ActivityPub specification. It is a binary state โ either an actor has liked
an object or they haven't. There is no built-in rating scale.
Platforms surface likes under different names: Mastodon calls them
favourites (shown with a star โ
), other platforms use hearts โฅ or thumbs
up ๐. The underlying ActivityPub type is always Like regardless of the
UI label.
1. The Like Activity
Minimal structure
{
"@context": "https://www.w3.org/ns/activitystreams",
"id": "https://alice.example/likes/abc123",
"type": "Like",
"actor": "https://alice.example/users/alice",
"object": "https://bob.example/users/bob/statuses/456",
"to": ["https://www.w3.org/ns/activitystreams#Public"],
"cc": ["https://bob.example/users/bob"]
}
Key fields:
id โ required; a stable, dereferenceable URL on the actor's server.
Needed so the activity can later be referenced inside an Undo.actor โ the actor who is liking.object โ the object being liked (a URL is sufficient; the full object
need not be embedded).to/cc โ addressing. Conventions vary; common practice is to address
the Public collection and cc the author of the object.
The Like activity SHOULD have an id because it will need to be
referenced as the object of a future Undo{Like}. Omitting it makes
undoing the like ambiguous.
2. The Two Collections
likes โ on the object
An object (Note, Article, Video, etc.) MAY expose a likes property linking
to an OrderedCollection of Like activities received for that object:
{
"id": "https://bob.example/users/bob/statuses/456",
"type": "Note",
"likes": "https://bob.example/users/bob/statuses/456/likes",
...
}
This collection is maintained by the author's server. It contains one
Like activity per liking actor (unique by actor id). The count of items in
this collection is what platforms display as the "like count."
The collection MAY be hidden (its items not publicly enumerated) while still
exposing a totalItems count. This is common practice โ servers often expose
the count but not the list of who liked the post.
liked โ on the actor
An actor MAY expose a liked property linking to an OrderedCollection of
objects that actor has liked:
{
"id": "https://alice.example/users/alice",
"type": "Person",
"liked": "https://alice.example/users/alice/liked",
...
}
This collection is maintained by the actor's server and contains the
objects (by id), not the Like activities themselves. It is unique by object
id โ an actor cannot like the same object twice. It is often private or
semi-private.
3. Client-to-Server Flow (C2S)
When a client (app) submits a Like to the actor's outbox:
- Server checks the object exists.
- Server checks the object is not already in the actor's
liked collection.
- Server checks the actor has permission to view the object (is an
addressee of the object or its
Create activity).
- Server checks the actor is not blocked by the object's responsible actor.
- If all checks pass:
- Add the object to the actor's
liked collection.
- If the object is local: add the
Like activity to the object's
likes collection directly.
- If the object is remote: deliver the
Like activity to the inbox
of the actor responsible for the object (typically attributedTo or
actor on the object).
4. Server-to-Server Flow (S2S)
When a remote server delivers a Like to your inbox:
- Check the
object exists on the local server. If it doesn't (e.g. it's
on a third server), the Like can be treated as having no side effects
and quietly ignored.
- Check no
Like from this actor already exists in the object's likes
collection (deduplicate by actor id).
- Check the responsible actor for the object has not blocked the liking
actor.
- Check the liking actor has permission to view the object.
- If all checks pass: add the
Like activity to the object's likes
collection and update the displayed count.
5. Undoing a Like โ Undo{Like}
Unlinking a like is done with an Undo activity wrapping the original Like:
{
"@context": "https://www.w3.org/ns/activitystreams",
"id": "https://alice.example/likes/abc123/undo",
"type": "Undo",
"actor": "https://alice.example/users/alice",
"object": {
"id": "https://alice.example/likes/abc123",
"type": "Like",
"actor": "https://alice.example/users/alice",
"object": "https://bob.example/users/bob/statuses/456"
}
}
The object of the Undo is the original Like activity, identified by
its id. This is why the original Like must have had a stable id.
The object may be embedded (as above) or referenced by id alone โ
implementations should accept both.
Validation on receiving an Undo{Like}:
- The
Like activity must exist (in the likes collection).
- The actor of the
Undo must be the same as the actor of the Like.
- The
object of the Like must be local.
If valid: remove the Like from the object's likes collection and
decrement the displayed count.
6. Delivery Target
The Like is delivered to the inbox of the actor responsible for the
object, not to the liking actor's followers and not to the public. The
"responsible actor" is typically the attributedTo field on the object.
This means:
- Likes are not broadcast to followers (unlike boosts/announces).
- Like counts on remote posts are only known by the post's origin server.
- A server only knows about a Like on a remote post if it happened to
receive the notification through some other path (e.g. a local user
is the author, or the remote server proactively forwarded it).
7. The Dislike Type
ActivityStreams 2.0 defines a Dislike activity type. It is not used in
standard ActivityPub. The W3C ActivityPub primer explicitly states this.
Exception: PeerTube supports both Like and Dislike for videos,
federating them to update video likes and dislikes counts. PeerTube
exposes both as named collections on the video object. This is a PeerTube
extension and not interoperable with Mastodon-lineage software.
Do not implement or depend on Dislike unless you are specifically building
PeerTube-compatible software.
8. Multiple Likes for the Same Object
The ActivityPub spec does not address what happens if an actor sends multiple
Like activities for the same object. In practice:
- Both
liked (actor side) and likes (object side) are treated as unique
by the relevant id (object id and actor id respectively).
- Originating servers should avoid sending duplicate
Like activities.
- Receiving servers should silently ignore all but the first
Like from the
same actor for the same object.
9. Emoji Reactions
Emoji reactions are a popular extension to the basic Like model. They allow
reacting with a specific emoji instead of (or in addition to) a plain like.
There is no single standard โ two incompatible approaches exist in the wild.
9.1 EmojiReact โ Pleroma/Akkoma style (FEP-c0e0)
Pleroma introduced EmojiReact as a new activity type in the LitePub
namespace. This has since been formalised in FEP-c0e0, which is the
emerging community standard.
{
"@context": [
"https://www.w3.org/ns/activitystreams",
{
"toot": "http://joinmastodon.org/ns#",
"EmojiReact": "http://litepub.social/ns#EmojiReact"
}
],
"id": "https://alice.example/reactions/xyz",
"type": "EmojiReact",
"actor": "https://alice.example/users/alice",
"object": "https://bob.example/users/bob/statuses/456",
"content": "๐"
}
For a custom emoji (not a Unicode emoji), the tag property is added:
{
"type": "EmojiReact",
"actor": "https://alice.example/users/alice",
"object": "https://bob.example/...",
"content": ":blobcat:",
"tag": [{
"type": "Emoji",
"name": ":blobcat:",
"icon": {
"type": "Image",
"url": "https://alice.example/emoji/blobcat.png"
}
}]
}
Akkoma/Pleroma behaviour:
- A user MAY react multiple times with different emoji to the same post.
- A user MAY NOT react more than once with the same emoji.
EmojiReact is distinct from Like โ a user can both Like and
EmojiReact to the same post; they are separate.- Duplicate reactions (same actor, same emoji) MUST be silently ignored.
- Unicode emoji:
tag MAY be omitted.
- Custom emoji:
content contains the shortcode with colons (:blobcat:);
tag contains the Emoji object with the image URL.
Undo: wrapped in Undo{EmojiReact} the same way as Undo{Like}.
9.2 Misskey-style reactions (overloaded Like)
Misskey (and its forks: Calckey, Firefish, Catodon) does NOT use a separate
activity type. Instead it sends a standard Like activity with an additional
non-standard _misskey_reaction property carrying the emoji string:
{
"@context": "https://www.w3.org/ns/activitystreams",
"type": "Like",
"actor": "https://misskey.example/users/alice",
"object": "https://bob.example/users/bob/statuses/456",
"_misskey_reaction": "๐"
}
Misskey behaviour:
- Likes and reactions are equated โ reacting replaces any previous reaction.
- Only one reaction per post per user is allowed (unlike Pleroma which
allows multiple different emoji).
- Custom emoji:
_misskey_reaction contains the shortcode (:blobcat:@.
for local or :blobcat:@misskey.example for remote); the emoji image
is resolved separately.
9.3 Interoperability between the two approaches
| Pleroma/Akkoma (EmojiReact) | Misskey-lineage (Like + _misskey_reaction) |
|---|
| Activity type | EmojiReact (new type) | Like (standard type, extended) |
| Multiple reactions per post | Yes (different emoji) | No (one per user) |
| Distinct from plain Like | Yes | No |
Custom emoji in tag | Yes | Shortcode in _misskey_reaction |
| Standard | FEP-c0e0 (draft) | Proprietary |
Servers that don't understand EmojiReact will ignore it (unrecognised
activity types should be treated as unknown and discarded). Servers that
don't understand _misskey_reaction will process it as a plain Like โ
which means Misskey reactions do federate as likes to Mastodon and similar
platforms, they just lose the emoji identity.
Mastodon currently does not implement either emoji reaction system on the
sending side. It displays incoming Misskey reactions as plain likes. A PR for
Pleroma-style reactions was opened (#13275) but has not been merged.
FEP-c0e0 is the recommended approach for new implementations that want
to add emoji reactions, as it uses a distinct activity type, allowing servers
that don't support reactions to simply ignore them without inflating like counts.
10. Stale Like Counts on Remote Posts
A persistent and well-known limitation: like counts displayed on remote posts
are frequently stale or incomplete. This happens because:
- Likes are delivered only to the post's author's server. They are not
broadcast to every server that has seen the post.
- A server that learns about a remote post (e.g. because a local user
boosted it) receives the post object at that moment in time, including
its
totalItems count in the likes collection โ but that count is a
snapshot, not a live feed.
- The receiving server typically does not subscribe to updates of the remote
likes collection. Counts only update if the server re-fetches the object.
- Some implementations never re-fetch remote objects at all after initial
discovery.
This is not a bug in the protocol โ it is a consequence of decentralisation
combined with the delivery model. Wikipedia's ActivityPub article notes this
explicitly as a known criticism.
Implications for implementors:
- Do not claim that like counts shown for remote posts are authoritative.
- If freshness matters, re-fetch the remote object before displaying its count.
- Do not use a remote
likes collection count as a trust or ranking signal.
11. The liked Collection and Privacy
The liked collection on an actor is often kept private or unexposed. The
ActivityPub spec does not require it to be publicly readable. Implementations
vary:
- Mastodon: exposes a
liked URL on the actor but requires authentication
to read; effectively private.
- Many others: expose the collection URL but return an empty collection
or a 403/404 without auth.
Do not rely on being able to read another server's liked collection to
reconstruct what a user has liked. The only reliable signal is receiving a
Like activity in your inbox.
12. Summary of Activity Types
| Activity | Sent to | Effect |
|---|
Like | Author's inbox | Adds to object's likes collection; notification to author |
Undo{Like} | Author's inbox | Removes from likes collection |
EmojiReact (FEP-c0e0) | Author's inbox | Adds emoji reaction; ignored by non-supporting servers |
Undo{EmojiReact} | Author's inbox | Removes emoji reaction |
Like + _misskey_reaction | Author's inbox | Misskey reaction; treated as plain Like by others |
Dislike | Author's inbox | PeerTube only; not used elsewhere |
