Ratify Message IDs

[DanielOaks]

I reckon we've shown this to be stable enough, we have a few server implementations and all. Should be right to ratify as-is it feels like?

[jwheare]

Might be worth some further thought around whether we suggest encoding account ids in msgids to allow for eg certain editing proposals #304 (comment)

[DanielOaks]

Definitely an interesting idea. Message editing/deletion is an interesting case in particular (imo seems a lot more suited to server-side checking of those kinds of things than doing it client-side), but in general I'm on the side of preserving the opacity of the message IDs.

[slingamn]

IMO the essential features of draft/msgid are:

1. The server has freedom to generate arbitrary IDs as long as they are unique-per-network and "sane" (not ridiculously long? no weird bytes?)
2. The IDs are completely opaque from the client's perspective (the client is only allowed to compare them for uniqueness)

Server implementations should be free to use uuidv4s (pure randomness), or stuff trusted data in them protected by an AEAD (as in the editmsg proposal), or whatever --- the client shouldn't care. I think embedding a client-server protocol inside msgid is very much out of scope.

[SadieCat]

If there's no more objections can we ratify this?

[jwheare]

Not really an objection, I just still think it's worth mentioning explicitly that while ids are to always be treated as opaque by clients, servers might wish to encode specific information in them that they can reuse for authenticated actions like edits/deletes.

[jwheare]

Two simple style/clarity suggestions and something to address recent thread comments.

---

Change:

The tag value is chosen by the originating server and MUST be unique, meaning any other message transmitted on the entire network at any time MUST NOT share the same value.

to:

The tag value MUST be a unique ID chosen by the originating server. Uniqueness in this context means that any other message transmitted on the entire network at any time MUST NOT share the same value.

---

Change:

The tag value MUST be treated as a case sensitive opaque identifier. Clients MUST NOT use case folding or normalization when comparing IDs.

to

Clients MUST treat the ID as a case sensitive opaque identifier. Clients MUST NOT use case folding or normalization when comparing IDs.

---

Add a paragraph at end of non-normative "Choosing an ID format" section:

Servers might wish to encode additional information within the ID, for internal use only. This could allow further actions to be taken on a message. For instance, including account information for the author in an ID could enable authenticated message edits or deletes, without having to maintain and consult a separate message store. Take care not to include private data without appropriate encryption.

[DanielOaks]

Have considered other suggested text from @slingamn. While I like the gist of it and that middle sentence feels cool, it feels like it removes a bit too much context on this 'may' at all. I'm leaving that PR as-is since... it works fine, and feels reasonable. Esp for a single-para 'maybe'. No other changes made to it in this PR.

Servers might wish to encode additional information within the ID, for internal use only. This requires careful attention to several concerns: security, privacy, and backwards and forwards compatibility of different ID generation schemes. Clients should treat such identifiers as opaque, making no assumptions about them beyond per-network uniqueness.

[slingamn]

My proposal for a compromise wording:

Servers might wish to encode additional information within the ID, for internal use only. For instance, including account information for the author in an ID could enable authenticated message edits or deletes, without having to maintain and consult a separate message store. This requires careful attention to several concerns: security, privacy, and backwards and forwards compatibility of different ID generation schemes.

[jwheare]

@slingamn yup that works for me

[jwheare]

In Motivation, a small edit, replace:

the protocol lacks an ability

with:

the protocol lacks the ability

[jwheare]

LGTM, happy to merge

[jwheare]

Will do so tomorrow if no other comments. I strongly recommend reading the whole spec again, not just this changeset.

[jwheare]

This was published to the website in ircv3/ircv3.github.io#252