Metadata key registry

[attilamolnar]

We need a registry for metadata keys, otherwise metadata usage is problematic in a heterogenous environment.

Some ideas, imported from the metadata draft from 2012:

Key	Meaning
server.certfp	SSL certificate fingerprint
user.email	User's email address
user.phone	User's phone number
user.website	User's website
user.im.*	IM handles; the * is replaced with the relevant service name
user.playing	Music the user is currently listening to
user.status	The user's current status
client.name	Client's name
client.version	Client version

@jwheare has indicated that he wants to work on this (eventually).

[grawity]

Looks good, I'd use conn(ection).certfp for the first item though – server.* seems a bit confusing.

[ghost]

At the time it was written, the server.* portion was a namespace for server-set keys which clients could not influence.

[jwheare]

An updated preliminary list, dropping top-level namespaces for now, but we can discuss again whether they're even needed. Their previous definitions are included below.

Key	Meaning
icon	Avatar/icon URL
email	Email address
tel	Phone number
city	Current city
country	Current country
coords	Comma separated latitude/longitude coordinates, e.g. 65.83028,-144.07556
tz	Current timezone name, DST aware e.g. Europe/London or UTC
url	Website URL
desc	Long description, e.g. profile text
status	Status update
playing	Current music
client	Client user agent string
pgp.url	PGP public key URL, e.g. https://example.com/key.asc
pgp.fp	PGP fingerprint, e.g. E582 94F2 E9A2 2748 6E8B 061B 31CC 528F D7FA 3F19
username.*network	IM/social network username, e.g. username.twitter.com OR username.last.fm OR username.keybase.io
certfp	Client certificate fingerprint, only settable by the server

---

Historical namespace definitions:

• The server namespace is intended for keys which the user cannot set, such
  as SSL certificate fingerprints.
• The user namespace is intended for keys which the user can set and which
  carry meaning relevant only, or mostly, to users.
• The client namespace is intended for keys which the user can set and which
  describe the user's client.
• The ext namespace is intended for keys which have not been formally
  registered. Server and client authors are advised that they cannot rely on
  this namespace to carry any standardized meaning. The main namespaces may be
  replicated under this namespace, except for 'private'.
• The private namespace is intended for server-internal keys and may only be
  seen with the appropriate server operator permissions. Keys in this
  namespace are not required to be registered.

[DanielOaks]

So are we going to extend Metadata to have explicitly server-defined keys? We can simply emit ERR_KEYNOPERMISSION when users try to set it (for instance, in the case of certfp listed above. However, right now there's no way for clients to know that those keys are specifically set and confirmed by the server, rather than just an allowed key that the other client has set for themselves. I think we may have already had this conversation in previous Metadata issues, but if we want to have keys like this then we should add it to the tracker as something to take care of.

[jwheare]

In terms of clients knowing about keys, is it enough to just define that behaviour in the registry?

[DanielOaks]

If we have proper server-only namespaces and such, I think it should also be defined in the spec. It needs to be explicitly stated for servers that <x, y, and z> keys, or <x, y, and z> key namespaces MUST NOT be writable by users. Otherwise, some server could just implement no explicit checking of keys, conform with the spec, and clients could get confused when the server-only keys defined here were really set by the other user (server.operclass / etc).

This would probably require an explicit new cap or using a character not defined in the metadata-3.2 as the namespace separator, so clients can confirm the server behaves and treats these keys that way.

[jwheare]

One idea is we could steal from c2c tags and require a +prefix on user settable keys.

[kaniini]

What about keys that need to persist vs. ones that need to not.

[jwheare]

What's an example of a key that shouldn't persist? Or do you mean keys that services might persist for e.g. a NickServ account? Persistence in services should be managed by services. By default keys should probably only persist for as long as a client is connected.

[ghost]

In re non-persistent keys: if namespaces are reintroduced, a 'transient' namespace would basically be for keys whose state shouldn't be stored.

One idea is we could steal from c2c tags and require a +prefix on user settable keys.

👎

[kaniini]

@jwheare and what about persistence in a serviceless-network like mammon?

[kaniini]

An example of a key that shouldn't persist would be playing. It is probably only relevant for the current session.

[jwheare]

Clients can manage transience by simply unsetting their keys. This can be suggested on a per-key basis in a registry. I don't think there should be any concept of timeouts in the spec.

[kaniini]

@Aerdan I think that namespaces for keys overcomplicate the spec, I certainly have no plans of implementing any support for namespaces.

[ghost]

Clients can manage transience by simply unsetting their keys.

👎 This requires an extra roundtrip and notification.

[kaniini]

I think the IRCd or services should have the right to garbage collect keys that are not relevant anymore when a client exits. How can a client signal which keys are relevant?

[ghost]

I was interpreting 'transient' to mean "relevant only enough to pass through a notification, but not enough to keep around", but deleting keys when no longer relevant is fine for longer-term transience.

[DanielOaks]

I'll write up a persistence draft. I think it could be useful to keep specific keys around.

In terms of differentiating user-settable keys vs keys that are always server-set (ie, special server-set keys where clients may come to rely on the values as being server-set, things like certfp maybe), imo the only things we could do would either be some special not-client-settable namespace(s) (something like conn, server, etc), or reserving specific keys in the spec (which isn't scalable because servers making new keys), or the prefixing client-set or server-set keys which seems a little ugly but could be done without a big issue. Any other ideas come to mind?

This is something along the lines of what I was thinking for the server-set prefixes stuff, but if there are other ideas on how to handle these sort of keys so clients can be assured they're treated specially then that'd be good.

[MrBenC]

Originally I brought this up on IRC, but I think I should mention it here.

<MrC> Hm, I guess there's no provision for duplicate metadata keys with the same name, but with different values?
<MrC> While most should probably have only one instance per client, or per channel, I could see certain cases where you might want to have multiples. Looking at issue #228, some examples that come to mind immediately are user.phone/tel, user.email/email, and url.
<MrC> An alternative may be to append a number to the field names (since the names aren't actually defined yet), e.g. tel1, tel2, tel3, ... However, such a naming convention should probably be standardized, so another implementation won't do something like tel01, emailB, and so on.

As the metadata key names have not yet been defined, I see an opportunity to address this in the form of standardizing the numbering convention. I.e. if the following fields (tel1, email2, url3, etc.) are utilized, servers and clients MUST start from 1, without leading zeros.

This has the advantage of being compatible with the metadata spec as it exists today, in particular the SET command, and would still have the same effect even without any one key being technically duplicated, as url1 and url2 are different, even if they have similar meanings.

Ben

[jwheare]

Closing this in favor of documenting what's starting to be used in the wild #336

If any keys need to be transferred they should be added over there.