Metadata key proposals

[jwheare]

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]

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]

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]

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

[jwheare]

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: https://github.com/ircv3/ircv3-ideas/issues/16 and here https://github.com/ircv3/ircv3-ideas/issues/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]

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]

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

The nick is in brackets after the display name.

[RyanSquared]

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 :+1: for that solution, still keeping the identifier while the display can change.

[progval]

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

[jwheare]

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]

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

[luxaritas]

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]

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

[SadieCat]

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]

Edited to add the bot-url key.

[jwheare]

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]

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]

as per https://github.com/ircv3/ircv3-ideas/issues/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]

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]

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]

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