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 tracker #244

Closed
jwheare opened this Issue Mar 8, 2016 · 3 comments

Comments

Projects
None yet
2 participants
@jwheare
Member

jwheare commented Mar 8, 2016

  • PR #250 New spec with explicit key subscriptions
    • Issue #278 Additional non-normative sections
    • PR #245 Rate limiting (needs rebasing on #250 after that gets merged)
  • Issue #228 Key registry

Additional proposals

  • Issue #173 Lists in metadata

Closed

  • #219 Initial issue discussing problems with 3.2 spec
  • #279 Deprecate metadata-3.2

@jwheare jwheare added this to the Roadmap milestone Mar 8, 2016

@kaniini

This comment has been minimized.

Show comment
Hide comment
@kaniini

kaniini Mar 10, 2016

Contributor

Just leaving this here, but in my view these are some problems to look at:

  • Persistence - clients should be able to specify whether or not a key should persist beyond the current session (i.e. be remembered by services or whatever). It is not acceptable to leave this to the client, as the client may ping out instead of deleting the keys when they issue a QUIT, at least a setting to allow those keys to be forgotten when the client session is ended is necessary.
  • Moderation of metadata keys - this is for stuff like icon, some networks may wish to approve these changes out of band, to ensure that you do not set goatse as your avatar, for example.
  • Optional specific keys for METADATA SYNC. This is so that you can pull only icon on JOIN of a channel, for example, instead of getting your entire subscription list.

I'm sure I'll think of some other things later.

Contributor

kaniini commented Mar 10, 2016

Just leaving this here, but in my view these are some problems to look at:

  • Persistence - clients should be able to specify whether or not a key should persist beyond the current session (i.e. be remembered by services or whatever). It is not acceptable to leave this to the client, as the client may ping out instead of deleting the keys when they issue a QUIT, at least a setting to allow those keys to be forgotten when the client session is ended is necessary.
  • Moderation of metadata keys - this is for stuff like icon, some networks may wish to approve these changes out of band, to ensure that you do not set goatse as your avatar, for example.
  • Optional specific keys for METADATA SYNC. This is so that you can pull only icon on JOIN of a channel, for example, instead of getting your entire subscription list.

I'm sure I'll think of some other things later.

@jwheare

This comment has been minimized.

Show comment
Hide comment
@jwheare

jwheare Mar 10, 2016

Member
  • Persistence: my view is that there should be no expectation of persistence at all with metadata, just as there currently isn't with away status, realname, hostname, user, ident, nick, etc. Services/IRCds might well build an extra persistence layer, just as they have with NickServ/ChanServ/etc, but that layer is proprietary, and outside the scope of this spec.
  • Moderation: Yes, a non-normative section should be added with recommendations for servers to handle this alongside their existing moderation tools, e.g. /spamfilter, extbans, etc. Again, it's a proprietary concern for now.
  • I'd much favour letting clients specify keys on METADATA SYNC over the PRIORITY suggestion. Allowing clients to make simple explicit requests, rather than wrangle complex generalised systems.
Member

jwheare commented Mar 10, 2016

  • Persistence: my view is that there should be no expectation of persistence at all with metadata, just as there currently isn't with away status, realname, hostname, user, ident, nick, etc. Services/IRCds might well build an extra persistence layer, just as they have with NickServ/ChanServ/etc, but that layer is proprietary, and outside the scope of this spec.
  • Moderation: Yes, a non-normative section should be added with recommendations for servers to handle this alongside their existing moderation tools, e.g. /spamfilter, extbans, etc. Again, it's a proprietary concern for now.
  • I'd much favour letting clients specify keys on METADATA SYNC over the PRIORITY suggestion. Allowing clients to make simple explicit requests, rather than wrangle complex generalised systems.

@jwheare jwheare added the metadata label Jan 7, 2017

@jwheare

This comment has been minimized.

Show comment
Hide comment
@jwheare

jwheare Jan 7, 2017

Member

Closing in favour of the metadata label and individual roadmapped issues.

Member

jwheare commented Jan 7, 2017

Closing in favour of the metadata label and individual roadmapped issues.

@jwheare jwheare closed this Jan 7, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment