Reaction lexicon

[zappy-bit]

i think it would be cool if we had a lexicon that allowed people to submit emoji reactions (both in unicode and as an image) alongside regular likes (just like that mastodon fork)

[snarfed]

Yes! Obviously lots of precedent for these in all kinds of apps. I think Pleroma pioneered them in the fediverse, and Misskey and others now support them too. Background: snarfed/bridgy-fed#484

[zappy-bit]

made drafts for reaction records

text reaction:

{
  "lexicon": 1,
  "id": "community.lexicon.reaction.text",
  "defs": {
    "main": {
      "type": "record",
      "description": "A text reaction",
      "key": "tid",
      "record": {
        "type": "object",
        "required": ["symbol", "shortcode"],
        "properties": {
          "symbol": {
            "type": "string"
          },
          "shortcode": {
            "type": "string"
          }
        }
      }
    }
  }
}

image reaction:

{
  "lexicon": 1,
  "id": "community.lexicon.reaction.image",
  "defs": {
    "main": {
      "type": "record",
      "description": "An image reaction",
      "key": "tid",
      "record": {
        "type": "object",
        "required": ["image", "alt", "shortcode"],
        "properties": {
          "image": {
            "type": "blob",
            "accept": ["image/*"],
            "maxSize": 1000000
          },
          "alt": {
            "type": "string"
          },
          "shortcode": {
            "type": "string"
          }
        }
      }
    }
  }
}

[wont-work]

For "image reactions" (I assume the use case there is custom emoji), using https://github.com/aendra-rininsland/bluemoji (or some other "custom emoji" lexicon, if a better maintained one exists) may be a better idea than throwing ad-hoc images at the problem.

For "text reactions", (presumably Unicode emoji reactions), I would strongly advise explicitly defining what is considered an emoji. AP emoji reactions already have interoperability problems in this regard and I do not want atproto to repeat those mistakes:

Misskey and Mastodon both use their separate emoji pickers' list of renderable characters as a lookup table (which are not necessarily valid emoji characters). Iceshrimp.NET uses this abomination auto-generated from the Unicode data, Pleroma has silly hacks to attempt to interpret anything it can as emoji (to fix compatibility with Misskey). Additionally, there are multiple different "red/neutral heart" characters which should probably be canonicalized into one, preferably by a client before the reaction hits the protocol.

[LemmaEOF]

I might look into PRing this soon! I'd probably use an open union for reaction type to support Unicode emoji, Bluemoji, and any future custom emote lexica that crop up in future.

[gxjansen]

Hi all, I'm building https://github.com/barazo-forum, a forum on AT Protocol. We need typed reactions and would like to help move this forward.

Here's a concrete proposal that picks up where @wont-work left off (missing subject, emoji interop mess) and follows the community.lexicon conventions already in the repo.

Proposed schema: community.lexicon.interaction.reaction

{
  "lexicon": 1,
  "id": "community.lexicon.interaction.reaction",
  "defs": {
    "main": {
      "type": "record",
      "description": "A typed reaction to an AT Protocol record.",
      "key": "tid",
      "record": {
        "type": "object",
        "required": ["subject", "value", "createdAt"],
        "properties": {
          "subject": {
            "type": "ref",
            "ref": "com.atproto.repo.strongRef",
            "description": "The record being reacted to."
          },
          "value": {
            "type": "string",
            "description": "The reaction value. Known values are common reactions; apps may use any single Unicode emoji or custom token.",
            "knownValues": [
              "community.lexicon.interaction.reaction#like",
              "community.lexicon.interaction.reaction#heart",
              "community.lexicon.interaction.reaction#thumbsUp",
              "community.lexicon.interaction.reaction#thumbsDown",
              "community.lexicon.interaction.reaction#laugh",
              "community.lexicon.interaction.reaction#fire"
            ]
          },
          "createdAt": {
            "type": "string",
            "format": "datetime",
            "description": "Client-declared timestamp when this reaction was created."
          }
        }
      }
    },
    "like": { "type": "token", "description": "Generic approval." },
    "heart": { "type": "token", "description": "Love/appreciation." },
    "thumbsUp": { "type": "token", "description": "Agreement/approval." },
    "thumbsDown": { "type": "token", "description": "Disagreement/disapproval." },
    "laugh": { "type": "token", "description": "Funny/amusing." },
    "fire": { "type": "token", "description": "Excitement/trending." }
  }
}

Design rationale:

1. One record type, not two. knownValues is open in AT Protocol: unknown values pass through, they're not rejected. So a single value field handles both named tokens (#like, #heart) and raw Unicode emoji. No need for separate text/image record types.
2. Same pattern as RSVP. community.lexicon.calendar.rsvp already does this: subject (strongRef) + status (string with knownValues + tokens). Seemed worth staying consistent.
3. strongRef on subject. Per @wont-work's point: CID integrity matters here.
4. Emoji without the AP mess. Common reactions get unambiguous token values. Unicode emoji go directly in value as codepoints. This avoids the Misskey/Mastodon lookup table divergence because tokens handle the common cases and Unicode is already canonical for the rest. Custom image emoji (Bluemoji etc.) could come later as an optional customEmoji ref field without changing this schema.
5. No app-specific fields. This is a generic record. Apps that need extra context (community scoping, for example) can use the NSID alias pattern from the PR The community.lexicon.interaction.like type #20 discussion to wrap it in their own namespace.
6. How this relates to interaction.like. The existing like record is bare approval: no type, just "I liked this." This reaction record is the typed version. The two can coexist: like for apps that only need a simple thumbs-up, reaction for apps that want hearts, laughs, fire, thumbsUp/thumbsDown, or anything else.
7. This also covers directional voting. Forums and link aggregators want up/down voting for ranking. Since interaction.like already handles bare approval, directional voting is just #thumbsUp/#thumbsDown on this record: a separate vote type isn't needed. Apps that want one-vote-per-user (vs. multiple reactions) can enforce that in their AppView.

Existing implementations for reference:

• blue.skytalk.talk.reaction: subject (strongRef) + emoji (string, maxGraphemes:1) -- active project, single Unicode emoji per reaction
• forum.barazo.interaction.reaction: subject (strongRef) + type (string) -- our current schema (will align with whatever is standardized here)
• Frontpage vote: upvote-only (no typed reactions)
• dev.fudgeu.experimental.atforumv1.feed.vote: integer -1/1 (abandoned, used bare at-uri)

I'm prepared to do the PR work if there's consensus on the general shape. @LemmaEOF: are you still planning to PR this Happy to collaborate or take the lead, whichever works.