go-xmpp icon indicating copy to clipboard operation
go-xmpp copied to clipboard

Prefix for ID in send message and Markable stanza

Open sashati opened this issue 4 years ago • 1 comments

In this PR, I added a Prefix for ID generation, since some applications use prefix in ID for some logics. Also I added a Markable flag to the Chat struct, then we can embed the Markable stanza in Send message

sashati avatar Jan 24 '21 17:01 sashati

TL;DR — There's no rule that a dog can't play basketball, but that doesn't mean it's actually a good idea.


While I don't think anything in RFC 6120 specifically forbids embedding information in the id attribute (as long as it's still unique and unpredictable, as this is), this isn't a thing anyone should be doing IMO. It's not part of the spec and it's creating a sort of side-channel unstandardized extension point in the protocol. This may seem harmless if it's just your server or client using it, but eventually other entities that haven't read the spec may end up relying on it and it's a way to create unnamespaced defacto extensions.

Instead you should embed your payload properly with a custom namespace, or define a new extension if it's something that you need mirrored with similar rules to IDs (which may be mirrored in IQ and some presence stanzas). I do know of at least one server doing this to embed IQ routing information so that their cluster routing can be stateless, but I don't think this means it's something we should encourage for the reasons I've already stated.

While this doesn't apply in a normative sense to stanza IDs, please see the Security Consideration section of XEP-0359: Unique and Stable Stanza IDs which specifically forbids this for the IDs generated in that spec. The same sorts of considerations likely apply to stanza IDs.

EDIT: if this is something you absolutely must have, maybe it's worth having some sort of "advanced user" API that lets you set your own IDs entirely instead of randomly generating one and mixing it with a prefix? That way people who want to do this have the flexibility to do so, but we don't make it so easy that we're encouraging something that's not really part of the protocol.

SamWhited avatar Jan 24 '21 17:01 SamWhited

Yup. Id attribute does not meant to store some metainfo and assumption that it can is unnecessary complication and bogus. If you need to, you always can cache all messages for at least last 15 minutes (if you want for example to catch muc ping timeouts and re-join stoned mucs) or so and refer for their id when needed.

eleksir avatar Oct 06 '24 05:10 eleksir

I agree with Sam and eleksir, therefore I'm going to close this.

mdosch avatar Oct 06 '24 08:10 mdosch