jdev - 2021-01-24

any client dev here that preservs notifications across app restarts?

i would be intersted how this is implementd

I see in RFC 6120 that there is a rule that says that IDs must be unpredictable (of course), but I thought it also said that you must not attribute any meaning to them. I don't see that anywhere now though. Is this actually a rule somewhere for ID attributes or did I just dream it up? I know it's true for resourceparts, so maybe I'm just remembering that and getting confused

What's the meaning of "meaning"?

eg. if I abuse IDs as an extension point and send "<stanzacount>-randomstuff" or something as the ID instead of using stream management acks (or anything really, just embedding some info in the ID). I'm trying to convince someone not to do this, but I can't find anything to quote that actually makes it illegal

(they're not doing that specific example, I just made that up, I have no idea what they want to shove into the ID)

It's this PR that someone opened that I'm trying to formulate a response to in case anyone else wants to comment that this is a bad idea: https://github.com/mattn/go-xmpp/pull/128

Sam Whited, xep359 (stanza-id) has that

potentially you are confusing if with that?

flow, which words say that?

flow: that's probably what I'm remembering. Drat, that doesn't help me though since now my argument has to be "this is a bad idea, just use XML" instead of "this is illegal, read the RFC" :)

Zash, "The value of the 'id' attribute should not provide any further information besides the opaque ID itself."

I note that this is not RFC keyworded

And that ejabberd does not follow that

and that I think that ejabberd has a good case for not following it

YOLO I'm using "date-random" in my IDs

flow: what does ejabberd do? I wasn't aware they were doing anything like this

as in yyyy-mm-dd-xxxxxxxx

Sam Whited, I think they simply use a nano or microseconds timestamp as ID

eww

That's actually a sensible thing I wanna do too

I think the eww'nes potentially depends on the use case

On the one side, it sure is always a good idea to not leak information

High-precision timestamp as ID, so you can sort things by it.

OTOH, it is really tempting to use timestamps for those IDs, and what could potentially go wrong?

That bothers me a lot. To be fair, I don't have a good reason why, it just seems like if you're going to do that you should put a <timestamp/> element or attribute or something in there and sort by that

eventually I think it is good that xep359 only recommends to not put any semantic in the ID, and it is good that implementations do not have to follow this

Semantics for yourself, but there's the risk of other entities starting to rely on that

It is kinda handy to encode data in IDs so you can do stateless things

Right, that's what ejabberd is doing in the IQ 'id' case.

(Not for sorting stuff but for routing responses without keeping state.)

I guess as long as the next 'id' value is not predictable

That makes sense to a certain extent if it's in an opaque way I suppose and not any info that someone else might decide is useful, rely on, and turn into a defacto API, but I don't know how to argue for "this is only okay sometimes"

flow: Nope, there's a random part.

High-precision timestamp with random noise in lowest bits. Mmmmmm.

Sam Whited: I'm not sure I'll buy this risk of my peers potentially doing stopid things as a show-stopper for me doing sane things. (While I would buy security worries of course.)

Holger: I don't think it means you shouldn't do it, but I don't think that means we should encourage it and add specific library support for it.

~Do not look at this: https://modules.prosody.im/mod_client_proxy.html~ nevermind, that does resource things, not ID things. ✏

If I were starting from scratch I would probably make it illegal so that most things wouldn't support it, then if you wanted to support it "who cares?" It's not breaking anything and if you accept the risk you can do it.

Anyways, sounds like it's not actually forbidden, so I'll have to make my argument some other way.

There are some limited cases where M-Link uses IDs for encoding information, too.

Although I hope to remove them at some point.