FEP-de8d: Emoji Catalogs

⁨0⁩ ⁨likes⁩

Submitted ⁨⁨1⁩ ⁨week⁩ ago⁩ by ⁨reesericci@socialhub.activitypub.rocks⁩ to ⁨Fediverse Enhancement Proposals@socialhub.activitypub.rocks⁩

https://socialhub.activitypub.rocks/t/fep-de8d-emoji-catalogs/8825/1

This FEP introduces Emoji Catalog, which provide a way for both clients and servers to publish and discover custom emoji.

ActivityPub implementations, including Mastodon, commonly support custom emoji. FEP-9098 defines how an Emoji is embedded in an Activity Streams object, but it does not define how a client discovers the emoji available for use when composing new content.

This leads to ActivityPub clients relying on implementation-specific APIs such as the Mastodon custom emoji endpoint.

A standardized emoji catalog allows a C2S client to:

Populate an emoji picker.
Determine which emoji the authenticated actor may use.
Retrieve emoji categories and static previews.
Update its local cache when the catalog changes.

Additionally, a standardized emoji catalog allows servers to publish custom emoji that other ActivityPub implementations can discover reliably.

Read full FEP at https://codeberg.org/fediverse/fep/pulls/888

original

Comments

Sort:hotnew top

tesaguri@socialhub.activitypub.rocks ⁨6⁩ ⁨days⁩ ago
(Sorry, I accidentally posted a draft.)

https://codeberg.org/fediverse/fep/src/commit/5259083e2ec463b6718fffe075c81d006002a12e/fep/de8d/fep-de8d.md

emojiCatalog

URI: https://w3id.org/fep/de8d#emojiCatalog

Domain: [ActivityPub] actor endpoints

What’s the rationale for the domain? I first thought that you intend the catalogue to be server-wide just like other endpoints properties, but that doesn’t seem to be the case since you use it for both the “actor-specific” and “server-level” catalogues.

An emoji MAY use the [Activity Streams] preview property to identify a non-animated representation of its icon.

This looks a little out-of-place to me for this FEP, as it’s not specific to the catalogue proposal. Maybe something like this could be proposed for consideration in the FEP-9098 discussion thread instead?

Removing an emoji from an actor-specific catalog means that the emoji
is no longer available for use by that actor in newly created content.

I think it’s too harsh to say that emojis that’s absent in the actor-specific catalogue is not available for use by that actor, because some implementations allow users to use any emojis, including ones from remote servers (e.g. for repeating a FEP-c0e0 emoji reaction that’s made by a remote user).

If this is intended to be a hint for the client rather than a strict authorisation of usage, I think “suggests that” (instead of “means that”) sounds appropriate here.

The optional emojiCategory property identifies the user-facing category in which a client may display an emoji.

Since the category is user-facing, I believe it should have an internationalisation consideration. My idea is to change the property’s range to an object that can have a name property (and hence nameMap).
original
- reesericci@socialhub.activitypub.rocks ⁨4⁩ ⁨days⁩ ago
  Thank you for the critique!
  
  What’s the rationale for the domain? I first thought that you intend the catalogue to be server-wide just like other endpoints properties, but that doesn’t seem to be the case since you use it for both the “actor-specific” and “server-level” catalogues.
  
  Yes, there are both actor and server-level endpoints. Currently, the way it works is depending on the type of actor determines which it is, like for a Service or Application actor, that’s a public catalog, whereas, if it’s a User or Person, it’s actor-specific. It’s a bit clunky, let me know if you have any ideas on how to improve it.
  
  This looks a little out-of-place to me for this FEP, as it’s not specific to the catalogue proposal. Maybe something like this could be proposed for consideration in the FEP-9098 discussion thread instead?
  
  Yes, good call.
  
  I think it’s too harsh to say that emojis that’s absent in the actor-specific catalogue is not available for use by that actor, because some implementations allow users to use any emojis, including ones from remote servers (e.g. for repeating a FEP-c0e0 emoji reaction that’s made by a remote user).
  
  If this is intended to be a hint for the client rather than a strict authorisation of usage, I think “suggests that” (instead of “means that”) sounds appropriate here.
  
  Maybe something like “Removing an emoji from an actor-specific catalog means that the emoji should not be surfaced as a member of the catalog by clients” could work?
  
  Since the category is user-facing, I believe it should have an internationalisation consideration. My idea is to change the property’s range to an object that can have a name property (and hence nameMap).
  
  Good call.
  original
  - tesaguri@socialhub.activitypub.rocks ⁨4⁩ ⁨days⁩ ago
    
    Image reesericci:
    
    What’s the rationale for the domain? I first thought that you intend the catalogue to be server-wide just like other endpoints properties, but that doesn’t seem to be the case since you use it for both the “actor-specific” and “server-level” catalogues.
    
    Yes, there are both actor and server-level endpoints. Currently, the way it works is depending on the type of actor determines which it is, like for a Service or Application actor, that’s a public catalog, whereas, if it’s a User or Person, it’s actor-specific. It’s a bit clunky, let me know if you have any ideas on how to improve it.
    
    Ah, my phrasing was not clear enough. I was wondering why the domain of the emojiCatalog property is the endpoints object instead of the Actor itself. The definition of the endpoints property says it’s “typically server/domain-wide” so I don’t think the endpoints object is suitable for actor-specific catalogues. If each actor (either a Person/the user or a Service/Application/the server) can have its own catalogue, I think the emojiCatalog can simply be a property of the Actor instead of its endpoints.
    
    Also, judging from the standard members of the endpoints object (proxyUrl, oauthAuthorizationEndpoint etc.), the endpoints seem to be intended for API endpoints that can have special/dynamic behaviour instead of just returning a mundane Activity Streams object like emojiCatalog. But we can only guess the intent of the spec authors, so it’s not a very strong factor.
    
    As for the way of representing actor-specific and server-level catalogues, I don’t have a strong opinion. Handling of “servers” in ActivityPub’s data model is a notoriously hard problem that doesn’t have a definite answer anyway.
    
    Image reesericci:
    
    Maybe something like “Removing an emoji from an actor-specific catalog means that the emoji should not be surfaced as a member of the catalog by clients” could work?
    
    I think that works (though it sounds a little tautology-ish?)
    original

FEP-de8d: Emoji Catalogs

Comments

emojiCatalog

`emojiCatalog`