search

estroBiologist / pluralchum

PluralKit integration for BetterDiscord
MIT License
41 stars 11 forks source link

Server display names don't work #4

Closed deesoff closed 10 months ago

deesoff commented 2 years ago

The plugin seems to always overwrite server specific display names with whatever that member's base display name is.

soulslabsys commented 2 years ago

This issue also occurs with server tags, including disabling your tag in a server. Example of this issue below:

Expected behaviour when setting server display names or tags (example used is disabling the tag in a server): a Server tag doesn't display, as per the server's settings

What actually happens when the plugin is enabled: b Server tag still displays, despite it being disabled for that server

estroBiologist commented 2 years ago

Aware of this, and working on it. The difficulty is that getting this info properly requires both authenticating and doing follow-up requests with the API, which is both a performance hit, and a security responsibility I'm not really qualified to handle. As of right now, the plugin uses only public information from the API, and I'd like to keep it that way if possible.

I appreciate the report, though, and I'll hopefully at least have a solution for servernames in the next release.

ghost commented 2 years ago

right now the servername API is authentication locked since I don't want to leak "this user is in this server". it might be possible in the future to log in to the pluralkit API with Discord OAuth2 so an API user can read other people's server settings if they share a server - would that work for you?

(love this plugin, btw!)

estroBiologist commented 2 years ago

thanks, but i don't know of any way i could use that 😕. PChum isn't a Proper Discord App, just a bit of JS that latches onto the message render function.

from my understanding of the Discord API (which, to be fair, is a few years out of date at this point), i can't really make it work as a proper app. not without giving its users a one way ticket to Ban Boulevard for selfbotting. i could totally be wrong about that, though.

completely understand why the server-specific API endpoints need authentication, though. i think at the end of the day, the real solution is just to use the tokens, assuming that can be done securely, considering PChum stores everything locally. for now, i can pull off some string hacks to make the servername thing work most of the time.

(and thanks! PK rules, y'all are doing some great work 😊)

HarmonyFriends commented 2 years ago

server system tags also do not work. it would be wonderful if we could get a string hack for that as well, though it's understandable if you feel that time is better spent elsewhere. thank you for all your hard work!

estroBiologist commented 2 years ago

i do plan to fix these, it's just that right now the plugin doesn't have enough data to figure out what the servername and servertag is reliably. i'll need to make the plugin authenticate itself with PK's web api to do that, which is a security headache-and-a-half. it might take a while, but they're at the top of my to-do list!

estroBiologist commented 2 years ago

also, about a potential similar hack for servertags: right now, the servername hack works on the assumption that there's no special servertag set. it uses the default system tag to try to deduce what the servername is from the full webhook name.

tldr: if a webhook's displayed name is adam (he/him) | Demo System and it knows that system's regular tag is | Demo System, it can use that to determine your servername is adam (he/him) (barring Unicode weirdness). that only works if it can rely on | Demo System to be unchanged, though. so i wouldn't hold my breath for a similar hack for servertags.