Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Option to use display name rather than mxid #61

Open
ToxicFrog opened this issue Feb 2, 2024 · 3 comments
Open

Option to use display name rather than mxid #61

ToxicFrog opened this issue Feb 2, 2024 · 3 comments

Comments

@ToxicFrog
Copy link
Contributor

For native Matrix users, the mxid is usually at least somewhat descriptive, but for users bridged in from other protocols the mxid is almost universally useless. For example, any matrix channel that bridges in users from discord is going to have a lot of users that look fine in (say) Element but show up as "discord_1234567890:example.com" in M51.

It looks like M51 sends this in the draft/display-name tag, but weechat doesn't support this.

I suspect that doing this as a quick hack wouldn't be particularly hard, and I may prototype it locally -- write a mangler that flattens Matrix display names into something IRC can compass, change the m.room.message handler and send_multiline_batch so that use that instead of nick2nuh(mxid) as the sender. Making it an option (not necessarily stateful, it can be a command line flag or envar or so) will be more annoying, making it robust (so that, e.g., @- or :-mentions of the munged name on the IRC side get translated into @-mentions of the correct mxid matrix-side) will, I think, take it well past "quick hack" status -- but I may accept an inability to reliably @ people if the alternative is not being able to tell who's talking at all, which is the status quo.

@knolley
Copy link

knolley commented Feb 2, 2024

weechat workaround:
/trigger addreplace matrix2051 modifier "weechat_print" "${server} == matrix2051 && ${tg_tag_irc_+draft/display-name}" "/(.*)/${info:nick_color,${tg_tag_irc_\x2bdraft\x2fdisplay-name}}${tg_tag_irc_\x2bdraft\x2fdisplay-name}\t${tg_message}" "" "" "none"
replace the ${server} == matrix2051 part with whatever you named the server in weechat

bonus to mark replies with a ,:
/trigger addreplace matrix2051reply modifier "weechat_print" "${server} == matrix2051 && ${tg_tag_irc_+draft/reply}" "/^.+$/${color:red},${re:0}" "" "" "none"

@ToxicFrog
Copy link
Contributor Author

ToxicFrog commented Feb 2, 2024

Oh nice, that works great. Doesn't help with the nicklist, but it's fine for most day to day chatting.

I think fixing the nicklist client-side would require an actual plugin or script; it looks like WC's internal concept of the nicklist doesn't include anything that could function as a display name, so -- at a first guess -- it would entail something like stuffing all the real nicks into a hidden group, then generating visible synthetic nicks based on the display-name. And getting the display name without waiting for them to speak would at least require M51 to put their display name in the gecos, which it looks like it does not do but has a TODO for doing someday.

After sleeping on this, I think to get what I want client-side (use display names for nicks and channels, group channels by Space), the minimally intrusive and fragile changes on the server-side would be something like:

  • display name for nick in gecos
  • display name and enclosing space for channel as a prefix in channel topic

And then in weechat:

  • weechat trigger as above to display messages using display name
  • weechat script to replace nicklist with display name
  • weechat script to extract the topic prefix into buffer localvars that can be easily used in buflist formatting rules, possibly with a mapping from matrix space names to more concise IRC-friendly ones¹

To make the "group channels by space" part less gruesome, it might prove convenient to add a "single-space" mode to M51, where you give it a space ID (as part of the gecos in USER? As a vendor-specific capability?) during connection registration and it reports only channels in that space, and then have one client-side server configuration per space. I am however less confident in my ability to implement that.

¹ so that, for example, the space "a grand adventure in terrible ideas" just shows up as "[terrible ideas]"

@ToxicFrog
Copy link
Contributor Author

Whoops, the workaround doesn't work for the relay. Which makes sense, rendering of buffer names is entirely a client-side thing. But it is unfortunate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants