search

sm00th / bitlbee-discord

Bitlbee plugin for Discord (http://discordapp.com)
GNU General Public License v2.0
290 stars 27 forks source link

Converting server custom emojis #60

Open zertap opened 7 years ago

zertap commented 7 years ago

Incoming emojis should have links included. For example. <:PepeFedora:235125303926718466> -> :PepeFedora: ( https://cdn.discordapp.com/emojis/235125303926718466.png )

And outgoing should be converted to emojis. Sending <:PepeFedora:235125303926718466> would work in this case, but if possible, :PepeFedora: should be converted to that.

jwheare commented 6 years ago

I've PRed incoming conversion here: #106

zertap commented 6 years ago

Thanks! Closing the issue as it has been merged in https://github.com/sm00th/bitlbee-discord/commit/4f1671c93f7515c1a5adc913abbcb93ec080aff8

jwheare commented 6 years ago

Bear in mind outgoing conversion still doesn’t happen so might be worth leaving this open.

zertap commented 6 years ago

Oh yeah, that is true.

Outgoing could be a bit tricky since afaik there can be duplicate emoji names? Or is that only with nitro and multiple servers? Maybe default to the first available emoji?

Well anyways I'll reopen since this is only half-implemented.

dgw commented 6 years ago

I was curious enough to look into this a bit.

Discord's API returns a list of available emoji/emotes per "guild" (server) from the GET /guilds/{guild.id}/emojis endpoint.

From that API call (sent once per server on connect) the plugin could build a hash/map of emoji names to IDs on each joined Discord server for outbound translation.

That's as far as I've thought, but there's plenty of little details to think about. Some emoji can be sent without colons, for example. And it's possible to allow only certain roles to use a given emote, so the plugin would have to track the logged-in user's roles if it doesn't already.

sm00th commented 6 years ago

From that API call (sent once per server on connect) the plugin could build a hash/map of emoji names to IDs on each joined Discord server for outbound translation.

You will have to then monitor websocket data for Guild Emojis Update events and make sure your list is up to date.

Some emoji can be sent without colons, for example.

We don't have to emulate every aspect of the official client, we can establish our own rules.

the plugin would have to track the logged-in user's roles if it doesn't already.

Unfortunately not: #49

dgw commented 6 years ago

You will have to then monitor websocket data for Guild Emojis Update events and make sure your list is up to date.

Thanks. I don't even have an excuse for not including this in my comment. It was one of the first things I brought up when discussing this in the Discord channel that got me to look into this in the first place.

As far as colons go, I'm still not entirely sure what that actually means. I suspect it's used for emotes that are represented in Unicode somewhere, and can be sent as straight-up Unicode emoji instead of emote names, but that's just speculation at the moment.

I did just think of a UX consideration though. If the user tries to send an emoji that they don't have access to (assuming it's not in the plugin's list, or is not available to their role if role tracking is added), should the plugin return an error and not send the message, or should it simply pass the message through without translating the emote? Probably the latter, though it could be hard for users to determine that the emote they thought they sent didn't work without checking in an official client.

sm00th commented 6 years ago

I did just think of a UX consideration though. If the user tries to send an emoji that they don't have access to (assuming it's not in the plugin's list, or is not available to their role if role tracking is added), should the plugin return an error and not send the message, or should it simply pass the message through without translating the emote? Probably the latter, though it could be hard for users to determine that the emote they thought they sent didn't work without checking in an official client.

We should never refuse to send messages. It can be a warning (with an opt-out option) in the control channel.

jwheare commented 6 years ago

I’d say the same thing applies to any message you might send that would appear differently after processing by the discord server. You can’t know for sure until bitlbee gets echo-message functionality.

No need for a warning imo.