jdev - 2023-12-19

  1. flow

    which is probably a pitty

  2. flow

    as is the name <delay/> for that element

  3. flow

    I think a <hop/> element where each hop can record the time it processed the stanza would be better

  4. jonas’

    <received/> :)

  5. flow

    yes, that's an even better name, or even <received-at/>

  6. singpolyma


  7. Kev

    Ticking away, the moments that make up a dull day.

  8. jonas’

    flow, nonono, <Received by=".."/> ;)

  9. flow


  10. Zash

    <delay/> is appropriate for the semantics it conveys, namely "this could not be delivered instantly"

  11. flow

    the way I see it, nothing is delivered isntantly, there is always a queing delay

  12. flow

    so why have a special case when we could simply add a timestamp

  13. flow

    so why have a special case when we could simply add a timestamp unconditionally

  14. Zash

    why do you need a timestamp if it differs from 'now' by maybe a second?

  15. Zash

    I mean I (read: the server) couldn't stop you if you added an <origin-time/> next to your <origin-id/> and 38 id carrier elements and whatnot.

  16. Zash

    > the way I see it, nothing is delivered isntantly, there is always a queing delay I find your lack of ~faith~ optimization ... disturbing. If we haven't delivered your message by the time your finger leaves the ⏎ key, what are we even doing here??? :P

  17. lovetox

    That would add many elements that are not relevant in most cases

  18. Zash

    I would personally prefer to keep those extra random id or timestamp elements to a minimum.

  19. flow

    Zash, I hear you. although I find a model where every hop adds its metadata, similar to stmp, more compelling. I think it helps with debugging and message retrival/archival

  20. Zash

    flow, while I agree such things would be interesting for debugging and tracing, those things should normally not be enabled all the time

  21. lovetox

    Also nobody asked for it.

  22. Zash

    In my experience, turning debug logging *off* is one of the most impressive perforance improvements you can do to an XMPP server ;)

  23. flow

    Zash, mind that it's not allways the server's fault (i.e, your fault ;)) if a mesasge is delivered slowly. the outbound link could also be simply have a low throughput and/or high packet loss

  24. Zash

    In my experience, turning debug logging *off* is one of the most impressive performance improvements you can do to an XMPP server ;)

  25. flow

    Zash, I don't think you can compare this with debug logging, timestamp generation is cheap, so should be adding an element to a stanza

  26. Zash

    Timestamp generation is a syscall, I thought those were expensive.

  27. Zash

    Plus each element adds parsing and serialization overhead.

  28. flow

    timestamps are done via vdso and hence are pretty cheap

  29. Zash

    Kindly expand your acronyms on first use :)

  30. flow

    there is no syscall

  31. flow

    happy to explain the vdso (virtual dynamic shared object) mechanism in more detail, but I think it's irrelevant for the discussion

  32. Kev

    Hang on, you're saying that timestamps are cheap on all platforms these days?

  33. flow

    well certainly on linux, I think the BSD* do similar stuff, no idea about windows

  34. flow

    however since timestamp are a very frequent operation, I would assume that windows also has those kind of optimization

  35. moparisthebest

    Hey my Nintendo 64 has no clock at all

  36. moparisthebest

    And it runs mainline Linux...

  37. flow

    related cliff click talk: https://youtu.be/uL2D3qzHtqY?t=1185

  38. moparisthebest

    flow: I don't think anyone is sending XMPP stanzas fast enough that this matters in any way, it's gotta be many more orders of magnitude slower to approach the pcie bus to reach your network card than even the slowest version of getting the current time?

  39. moparisthebest

    Still interesting talk :)

  40. Guus

    Hey, I've build a thing. This site draws a network graph of XMPP domains that are registered with it: https://xmppnetwork.goodbytes.im/ The data format is described in a new ProtoXEP that I submitted minutes ago: https://github.com/xsf/xeps/pull/1312 - I'd love some feedback.

  41. MattJ

    Guus: ha, what's old is new again 🙂

  42. MattJ

    But I don't think previous iterations had a XEP, that could make it more sticky

  43. Guus

    MattJ: yeah. I only know of Thomas' server info thing. That was http based

  44. Guus

    Now we only need server support. 😊 (And maybe a bug fix or three...)

  45. MattJ

    We used to host one at map.prosody.im, I presented it as a demo at FOSDEM many many years ago

  46. Guus

    I'm trying to bribe our favourite Swede...

  47. Guus

    Oh, I never saw that

  48. MattJ

    I don't know what became of it, it wasn't widely used and was mostly broken

  49. MattJ

    But I think the principle is good, so I'll be glad if we can get cross-server support and some standard implementations

  50. MattJ

    One thing that has often stopped me is that s2s links can leak private information, especially for smaller servers

  51. Guus

    If anything, I fixed a couple of bugs in Openfire because of this.

  52. MattJ

    I have some private domains, and I wouldn't necessarily want a server I federate with to publish them

  53. Guus

    Yeah, that's true. The page already shows if dwd is away from his computer...

  54. MattJ

    And for smaller domains you can determine likely contacts

  55. MattJ

    I thought about publishing hashes of the domains instead, which might help a bit

  56. Guus

    Yeah, I've been toying with that idea too. I first wanted to get a graph to render though.

  57. Guus

    And/or some list of suppressed domains