jdev - 2021-01-24

  1. lovetox

    any client dev here that preservs notifications across app restarts?

  2. lovetox

    i would be intersted how this is implementd

  3. Sam Whited

    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

  4. Zash

    What's the meaning of "meaning"?

  5. Sam Whited

    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

  6. Sam Whited

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

  7. Sam Whited

    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

  8. flow

    Sam Whited, xep359 (stanza-id) has that

  9. flow

    potentially you are confusing if with that?

  10. Zash

    flow, which words say that?

  11. Sam Whited

    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" :)

  12. flow

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

  13. flow

    I note that this is not RFC keyworded

  14. flow

    And that ejabberd does not follow that

  15. flow

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

  16. Zash

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

  17. Sam Whited

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

  18. Zash

    as in yyyy-mm-dd-xxxxxxxx

  19. flow

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

  20. Sam Whited


  21. Zash

    That's actually a sensible thing I wanna do too

  22. flow

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

  23. flow

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

  24. Zash

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

  25. flow

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

  26. Sam Whited

    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

  27. flow

    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

  28. Zash

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

  29. Zash

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

  30. Holger

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

  31. Holger

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

  32. flow

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

  33. Sam Whited

    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"

  34. Holger

    flow: Nope, there's a random part.

  35. Zash

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

  36. Holger

    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.)

  37. jonas’

    Do not look at this: https://modules.prosody.im/mod_client_proxy.html

  38. Sam Whited

    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.

  39. jonas’

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

  40. Sam Whited

    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.

  41. Sam Whited

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

  42. Kev

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

  43. Kev

    Although I hope to remove them at some point.