lambadalambda commented

Owner

NEW THOUGHTS SINCE ~06/02/2020

By now we have a working Emoji reaction system. There are a few things to wrap up.

Backend

As pointed out by misskey people at https://github.com/syuilo/misskey/issues/5425, the choice of EmojiReaction seems weird, as noun types usually get created by a Create activity, while verbs usually act on nouns, which EmojiReaction does. Of course, in english many nouns are verbs and vice versa. Either way, I'll create an MR that changes EmojiReaction to EmojiReact to make it clearer.

Frontend

Mastodon implemented local reaction system for their admin announcements. The endpoints there are as follows:

Adding a reaction

PUT /api/v1/announcements/:id/reactions/:emoji

Removing a reaction

DELETE /api/v1/announcements/:id/reactions/:emoji

JSON representation
{
  // ...
  reactions: [
    { name: '👍', count: 123, me: false },
    { name: 'coolCat', count: 456, me: false, url: 'https://example.com/coolcat.png', static_url: 'https://example.com/coolcat.png' }, },
  ],
  // ...
}
The attribute me is true when the authenticated user has added that reaction. The attributes url and static_url are present for custom emojis.

I'll align our own api with this format to make it easier for clients to support this in the future.

OLD INFORMATION, DEPRECATED

Backend issue: pleroma/pleroma#5044

This makes it possible to 'react' to a post with a single character unicode emoji. This adds a new object type called EmojiReaction. It looks pretty much like a Like, except it also has a content property.

'Single characters' in this context means anything that will be displayed as a single glyph. Combined sequences like 👩‍👩‍👧 are valid.

NOTE: The current implementation in Pleroma will not accept sequences.

I decided against overloading Likes because they really are semantically different. Just as one aspect, there are a lot of 'negative' Emoji that should not be treated as a like.

A frontend could still decide to display the reaction and like count in a combined way and only differentiate on expanding a post.

No frontend issue yet.

The full type is litepub:EmojiReaction

An example reaction activity:

{
  "@context": [
    {
      "litepub": "http://litepub.social/ns#",
      "EmojiReaction": "litepub:EmojiReaction"
    }
  ],
  "type": "EmojiReaction",
  "id": "https://example.com/activities/1",
  "object": "https://example.com/posts/1",
  "actor": "https://example.com/users/1",
  "content": "😀"
}

# NEW THOUGHTS SINCE ~06/02/2020 By now we have a working Emoji reaction system. There are a few things to wrap up. ## Backend As pointed out by misskey people at https://github.com/syuilo/misskey/issues/5425, the choice of `EmojiReaction` seems weird, as noun types usually get created by a `Create` activity, while verbs usually act on nouns, which `EmojiReaction` does. Of course, in english many nouns are verbs and vice versa. Either way, I'll create an MR that changes `EmojiReaction` to `EmojiReact` to make it clearer. ## Frontend Mastodon implemented local reaction system for their admin announcements. The endpoints there are as follows: > ### Adding a reaction > > `PUT /api/v1/announcements/:id/reactions/:emoji` > > ### Removing a reaction > > `DELETE /api/v1/announcements/:id/reactions/:emoji` > > ### JSON representation > > ```javascript > { > // ... > reactions: [ > { name: '👍', count: 123, me: false }, > { name: 'coolCat', count: 456, me: false, url: 'https://example.com/coolcat.png', static_url: 'https://example.com/coolcat.png' }, }, > ], > // ... > } > ``` > The attribute `me` is true when the authenticated user has added that reaction. The attributes `url` and `static_url` are present for custom emojis. I'll align our own api with this format to make it easier for clients to support this in the future. # OLD INFORMATION, DEPRECATED Backend issue: https://git.pleroma.social/pleroma/pleroma/pulls/5044 This makes it possible to 'react' to a post with a single character unicode emoji. This adds a new object type called `EmojiReaction`. It looks pretty much like a `Like`, except it also has a `content` property. 'Single characters' in this context means anything that will be displayed as a single glyph. Combined sequences like 👩‍👩‍👧 are valid. NOTE: The current implementation in Pleroma will not accept sequences. I decided against overloading `Likes` because they really are semantically different. Just as one aspect, there are a lot of 'negative' Emoji that should not be treated as a like. A frontend could still decide to display the reaction and like count in a combined way and only differentiate on expanding a post. No frontend issue yet. The full type is `litepub:EmojiReaction` An example reaction activity: ```json { "@context": [ { "litepub": "http://litepub.social/ns#", "EmojiReaction": "litepub:EmojiReaction" } ], "type": "EmojiReaction", "id": "https://example.com/activities/1", "object": "https://example.com/posts/1", "actor": "https://example.com/users/1", "content": "😀" } ```

lambadalambda commented

2019-10-01 13:25:06 +00:00

Author

Owner

@shpuld you posted some ideas for this on irc IIRC, can you add them to this issue?

shpuld commented

2019-10-01 16:02:49 +00:00

Owner

yeah,

A quick drawing I made, the scale of things is pretty stupid and looks awkward but anyway: when expanding a status, you can see the different reactions as a list below the status content, should be ordered by count, if we want to copy slack/discord you can click on the existing reactions to add/remove your reaction of that particular emoji, favorites would be just star emoji reactions with the rest. I kept the list of interactors next to the repeats counter, but I don't really like it. on a non-focused status you'd just have a number of reactions instead of showing what kinds it has. In general I think this sort of a design is really clunky and inelegant, will try to do something else

yeah, ![reactions_ohno](/attachments/8ade00ad-e7b5-4c3c-8c91-4d1025ab620f) A quick drawing I made, the scale of things is pretty stupid and looks awkward but anyway: when expanding a status, you can see the different reactions as a list below the status content, should be ordered by count, if we want to copy slack/discord you can click on the existing reactions to add/remove your reaction of that particular emoji, favorites would be just star emoji reactions with the rest. I kept the list of interactors next to the repeats counter, but I don't really like it. on a non-focused status you'd just have a number of reactions instead of showing what kinds it has. In general I think this sort of a design is really clunky and inelegant, will try to do something else

reactions_ohno.PNG

42 KiB

shpuld commented

2019-10-01 16:38:42 +00:00

Owner

^ Some more ideas. I like how it looks when the RT is on the same line with reactions, just separated by a thin vertical line. Perhaps the reply button can be put before the repeats with the number of replies too, followed by a list of reactions. The small image in top right is an idea that allows us to get rid of the regular status interactions mostly for focused statuses but I don't like that, consistent UX is better imo.

What should be done when there's too many reactions to fit on a single line? this could easily happen on mobile especially if reply and repeat stuff is on the same line, I'm not sure how other software does it (slack or discord for example). If we do what mono suggested on fediverse and restrict one reaction per person it'd be much less common I'm sure, and I think it might be a very good idea regardless so that you can't spam a single post with 100 emojis (I can already imagine spam bots doing this)

![morereactions](/attachments/b20ef99a-b489-44a4-b63e-87e2661e168e) ^ Some more ideas. I like how it looks when the RT is on the same line with reactions, just separated by a thin vertical line. Perhaps the reply button can be put before the repeats with the number of replies too, followed by a list of reactions. The small image in top right is an idea that allows us to get rid of the regular status interactions mostly for focused statuses but I don't like that, consistent UX is better imo. What should be done when there's too many reactions to fit on a single line? this could easily happen on mobile especially if reply and repeat stuff is on the same line, I'm not sure how other software does it (slack or discord for example). If we do what mono suggested on fediverse and restrict one reaction per person it'd be much less common I'm sure, and I think it might be a very good idea regardless so that you can't spam a single post with 100 emojis (I can already imagine spam bots doing this)

morereactions.png

558 KiB

lambadalambda commented

2019-10-01 17:55:56 +00:00

Author

Owner

also cc @sheueyen

lanodan commented

2019-10-07 09:32:27 +00:00

Owner

Frontend/API kind of questions:

Looking at the current implementation: Do we only show the emoji reactions on a detailed/focused view of the status rather than a timeline/whole thread (as IIRC MissKey does)?
Also what happens for the UIs when there is too much reactions to be displayed on one line, show the most used/recent/old and is if any what way to see all the reactions?

Frontend/API kind of questions: - Looking at the current implementation: Do we only show the emoji reactions on a detailed/focused view of the status rather than a timeline/whole thread (as IIRC MissKey does)? - Also what happens for the UIs when there is too much reactions to be displayed on one line, show the most used/recent/old and is if any what way to see all the reactions?

shpuld commented

2020-01-09 22:10:30 +00:00

Owner

Been working on implementation, some notes:

if emoji reactions aren't given with a status, they can't be shown on timeline for all statuses. Could be ok if you can see the amount of reactions and then by clicking the number you'd see what kind of reactions they were. Still not as nice as just being able to see everything all the time I think.
react_with_emoji and unreact_with_emoji endpoints in the API return a status, statuses don't contain reactions, it's a useless response from UI point of view.

Edit: more points to discuss

Notifications, if we want to replace favs with reactions, we need notifications for reactions but one notif per reaction is probably too much when one user can spam much more than just one reaction, so maybe one notif per user no matter how many reactions

Edit:

Also maybe we should have information about when the reaction was added for consistent ordering for the reactions

Been working on implementation, some notes: - if emoji reactions aren't given with a status, they can't be shown on timeline for all statuses. Could be ok if you can see the amount of reactions and then by clicking the number you'd see what kind of reactions they were. Still not as nice as just being able to see everything all the time I think. - react_with_emoji and unreact_with_emoji endpoints in the API return a status, statuses don't contain reactions, it's a useless response from UI point of view. Edit: more points to discuss - Notifications, if we want to replace favs with reactions, we need notifications for reactions but one notif per reaction is probably too much when one user can spam much more than just one reaction, so maybe one notif per user no matter how many reactions Edit: - Also maybe we should have information about when the reaction was added for consistent ordering for the reactions

sheueyen commented

2020-01-19 12:20:02 +00:00

Member

I hope this help @shpuld @lambadalambda:

I hope this help @shpuld @lambadalambda: ![Mobile_-_Post_variations_-_Reaction](/attachments/ebd4faf0-f0e9-4cc3-a68a-311352d38268) ![Mobile_-_Reactions_-_Emoji_Selection](/attachments/cd515b80-33ce-4ff3-a023-893e58d09628)

Mobile_-_Post_variations_-_Reaction.png

172 KiB

Mobile_-_Reactions_-_Emoji_Selection.png

146 KiB

Rows
Columns

Emoji Reactions Final Steps #4

NEW THOUGHTS SINCE ~06/02/2020

Backend

Frontend

Adding a reaction

Removing a reaction

JSON representation

OLD INFORMATION, DEPRECATED