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

Metadata key proposals #336

Closed
jwheare opened this issue Feb 22, 2018 · 20 comments
Closed

Metadata key proposals #336

jwheare opened this issue Feb 22, 2018 · 20 comments
Labels
Milestone

Comments

@jwheare
Copy link
Member

jwheare commented Feb 22, 2018

Edit (2020-04-21): Some of these are now documented on https://ircv3.net/registry.html#user-metadata

I've started using draft/metadata-notify-2 from #250 with a few metadata keys in IRCCloud, and in the absence of that spec being finalised and no registry yet existing (#228) I thought I'd briefly document how I'm using these keys.

Obviously if we want to change how these work based on discussion it's not an issue, but the draft status allows us to experiment:

Key Meaning Value Example
avatar User avatars to show along with messages/whois info/etc (see ircv3/ircv3-ideas#16) URI template with an optional {size} modifier denoting a square dimension pixel value to allow UI customisation https://example.com/avatar/{size}/asdf.jpg
display-name Alternative name to use instead of a nick for display purposes. Useful for gateways to chat services that allow spaces and other characters in nicks. A nick is still required for standard protocol level stuff but can be less prominent in the UI Any string James Wheare
status Lets people set a status text without having to be marked as "away" Any string Working from home
bot-url Lets you provide a URL for more info on a bot user so they can be identified as such in UI Valid url https://example.com/bot-info.html
@DanielOaks
Copy link
Member

Agreed, colcool. With regards to a registry, since that issue was created we introduced the registry page, so we'll document our preferred keys there once Metadata is rolling again proper.

@TingPing
Copy link
Contributor

URI template with an optional {size} modifier denoting a square dimension pixel value to allow UI customisation

How does one know the possible sizes?

Also the idea of users setting random urls for the client to download sounds slightly terrifying :P

@TingPing
Copy link
Contributor

Arbitrary display names also have a security concern for impersonating users.

@jwheare
Copy link
Member Author

jwheare commented Feb 22, 2018

Well, if you're using a url with {size} in it, you're implicitly saying that any value will be accepted in that url. The actual size may end up being smaller or larger, but it's a hint that can help optimise images. You can also just not include that modifier at all.

More discussion on arbitrary urls here: ircv3/ircv3-ideas#16 and here ircv3/ircv3-ideas#14

The idea with display names is that for general purpose IRCds the actual nick will still be visible in the UI to prevent impersonating. But for something like a Slack gateway, you can hide it (because slack themselves hide the "nick" username in their UI).

@jwheare
Copy link
Member Author

jwheare commented Feb 22, 2018

Arbitrary images URLs in avatars are no more of an issue than clients that already embed arbitrary image URLs. Clients that want to support this are free to provide controls to limit how big those images are, restrict them to certain domains, proxy them through an anonymising/optimising service, disable them entirely, let users ignore them, etc etc.

And yes, we should certainly suggest these sorts of things in a proper spec or recommendation document.

@jwheare
Copy link
Member Author

jwheare commented Feb 22, 2018

Here's an example of a prototype Twitch integration I've been working on where someone is using Twitch's @displayname message tags:

image

The nick is in brackets after the display name.

@RyanSquared
Copy link
Contributor

Arbitrary display names also have a security concern for impersonating users.

That's something I've been discussing with some people about the Discord system of changeable nicks with the same username. I personally always put my nick to username [nickname] but am often left confused because while there's still a username if I hover over their name, the nickname can change even mid-conversation. I was talking with someone and then suddenly they changed nicks, but I missed the context on why because it was from another channel... so I was completely thrown off.

I think a good solution would be to always show the identifier (nicks for IRC, username for Discord) while allowing the display name (display name for IRC, nickname for Discord) to be changed. And of course while I'm typing this @jwheare posts a comment explaining everything with one picture. :P

@jwheare definitely a 👍 for that solution, still keeping the identifier while the display can change.

@progval
Copy link
Contributor

progval commented Feb 22, 2018

Why use a metadata key for displayname instead of the user's "real name"?

@jwheare
Copy link
Member Author

jwheare commented Feb 22, 2018

Cos e.g. I still want to use real name for my full name, but have a shorter displayname that isn't my nick.

@DanielOaks
Copy link
Member

You also can't update gecos after connection, and some clients also just put the client name/version and similar in there.

@luxaritas
Copy link

Is this a good place to broach the idea of using metadata for authorization/permissions? Basically, I'd like to see MODE and OPER replaced/superseded with account and group/role-based, granular, named permissions. I can go into more detail if there's interest.

@jwheare
Copy link
Member Author

jwheare commented Feb 22, 2018

@lfp6 that sounds like it would be worth a separate discussion in it's own thread.

@SadieCat
Copy link
Contributor

Basically, I'd like to see MODE and OPER replaced/superseded with account and group/role-based, granular, named permissions. I can go into more detail if there's interest.

You can do this for operators using existing IRCd features. InspIRCd in a future release will also have this for prefix modes.

@jwheare
Copy link
Member Author

jwheare commented Apr 4, 2018

Edited to add the bot-url key.

@jwheare
Copy link
Member Author

jwheare commented Apr 4, 2018

Switched to using hyphens in keys consistently. Note that hyphens aren't considered valid in the deprecated metadata spec, for reasons that seem lost to the sands of time, but we should bring them back. CAPs and tag keys use hyphens so we shouldn't really deviate.

@Herringway
Copy link

Earlier this month I brought up language (channel, user) and timezone (user) as possible candidates for keys and reactions seemed positive. So I'm making note of that here.

@jesopo
Copy link

jesopo commented May 16, 2019

as per ircv3/ircv3-ideas#43 - I would suggest adding a bot key which can have any value but will be expected to be the name of the bot software (e.g. bot=BitBot) and a homepage key which, in the event of a bot user, will be assumed to be what bot-url would have been.

@k4bek4be
Copy link

We are also using "color" key, denoting a color the user likes to be associated with. The value format is HTML-style 6 hexadecimal digits, like "#800040". Client designers should decide, which UI elements are using this color - our client use this data for the display of avatar placeholders, nicknames and otherwise-uncolored message text.

@RyanSquared
Copy link
Contributor

Is this now an ongoing issue for all metadata keys (given https://ircv3.net/registry.html#user-metadata) and if so can we pin it?

@jwheare jwheare added this to the Roadmap milestone Apr 21, 2020
@jwheare
Copy link
Member Author

jwheare commented Feb 25, 2021

Closing, there's a registry on the site now.

@jwheare jwheare closed this as completed Feb 25, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

10 participants