XSF Discussion - 2023-01-16


  1. Daniel

    Entity caps 2 hashing for Conversations 3 ✅

  2. Zash

    🎉

  3. Tobi

    is that the same XEP or a new one?

  4. Daniel

    390

  5. Daniel

    Council issued a last call

  6. Tobi

    Ta

  7. edhelas

    Oh that's a nice XEP :)

  8. edhelas

    Might be interested to implement is as well

  9. emus

    If I get technical assitance I am always happy to make tweets and toots out of it

  10. Daniel

    would 0390/caps2 be a good place to create something like: <query xmlns="disco#items"><item jid="foo"><c xmlns="urn:xmpp:caps"><hash xmlns="urn:xmpp:hashes:2" algo="sha-256">…</c></item></query>

  11. Daniel

    i really want _something_ like this; doesn’t necessarily have to be that syntax

  12. Zash

    Me too! Recursive caps-disco something something

  13. Daniel

    it doesn’t necessarily have to be recursive

  14. Daniel

    just the caps hash of each item in the items response

  15. Zash

    Also something in stream:features on connect for local components etc

  16. Daniel

    (that the server knows)

  17. Daniel

    the next step would be to put the items in the bind2 response…

  18. Zash

    Negotiated with `<iq><{disco#info}query><{ecaps}plz-include-in-items/></query></iq>` or something ?

  19. Daniel

    does it have to be negotiated if it's just an extension?

  20. Daniel

    but yes that's an option to save traffic I guess

  21. Zash

    Dunno how careful we need to be with unexpected items in these very core pieces

  22. moparisthebest

    TLS land (including QUIC) does a whole bunch of purposefully putting random unexpected items in core places so that new things will work in the future, maybe we should do the same?

  23. moparisthebest

    https://www.rfc-editor.org/rfc/rfc9287.html for example

  24. moparisthebest

    https://www.rfc-editor.org/rfc/rfc8701

  25. moparisthebest

    8701 is probably what we should emulate with bind2, register a few useless extensions, have servers randomly insert them

  26. flow

    are we facing the same issues that causes TLS to do so?

  27. moparisthebest

    If Zash is afraid of putting unexpected things in there then maybe...

  28. MattJ

    We used to be a lot less scared of breaking changes :)

  29. MattJ

    I'm inclined to just go for it in this case - it *is* how XMPP is meant to work

  30. Daniel

    what's the X for again?

  31. moparisthebest

    eXcept too many implementations failed on uneXpected values...

  32. Dele Olajide

    >Daniel : what's the X for again? X factor. eXciting, eXtendable, eXtensible, eXtraordinary, ineXhaustible and uneXceptional

  33. Zash

    Daniel, point about conserving size might be relevant, but otoh caps helps with caching so probably won't matter

  34. flow

    moparisthebest> eXcept too many implementations failed on uneXpected values... not in my experience. I believe, at least in the FOSS space, the majority of XMPP implementations correctly handle unknown extensions at the well defined extensions points

  35. flow

    and even if not, say if you use exotic extensions points like namespace attributes, then I still would be willing to accept the fallout of implementations not handling namespace attributes like they should and tell those to fix their implementation

  36. flow

    and even if not, say if you use "exotic" extensions points like namespaced attributes, then I still would be willing to accept the fallout of implementations not handling namespace attributes like they should and tell those to fix their implementation

  37. moparisthebest

    TLS was extensible in the same way and failed hard this way, and we have very popular servers that can't parse stream features if you format them in a totally valid but unexpected way, so I'd disagree...

  38. moparisthebest

    Write a server and send: <features xmlns="http://etherx.jabber.org/streams"><starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"><required/></starttls></features> Then be surprised you can only federate with ~half the network, because the other half fails if you don't send <stream:features ...

  39. MattJ

    Hash the remote domain, and feed that into a probability function that gradually increases the percentage of domains which we send prefix-free <features/> to, until it reaches 100% on a certain date

  40. Zash

    Phased rollout strategies, on my federated network?

  41. MattJ

    Something we should do more of :)

  42. Zash

    Wait, aren't we already?

  43. MattJ

    By upgrading software?

  44. Zash

    Yeah. Not everyone does it at the same rate etc.

  45. MattJ

    With an algorithm we get to control the rate though, I guess

  46. Zash

    Yeah.

  47. MattJ

    If we want to be able to send prefix-free features, we can't just release that today or it will break for 50% of remote domains

  48. MattJ

    if we want to make that change within a year, we can't just release it in a year either

  49. moparisthebest

    For that particular bug I suppose we should just fix the offending server and wait, but I'm theory something like GREASE would prevent the same thing from happening with bind2 etc

  50. moparisthebest

    For that particular bug I suppose we should just fix the offending server and wait, but in theory something like GREASE would prevent the same thing from happening with bind2 etc

  51. Zash

    Prosody trunk, enabled by default, see who notices anything :)

  52. Guus

    Roughly 75% of the servers running the server software that I'm working on have not updated in the last 2 years. 😨 About 3% has not updated in more than 10 years. 😱

  53. Alex

    never change a running system 😀️

  54. flow

    moparisthebest, your example falls more into the namespaced attributes category than into what I consider "well defined extension points"

  55. flow

    and the latter is what I understand you want to feed with "random unexpected items", but maybe I misunderstood that

  56. moparisthebest

    flow: I think it's all basically the same, that programmers handle things they see and not things they don't

  57. moparisthebest

    Maybe xmpp-proxy could have a mode where it inserts random caps, randomly changes single quotes to double quotes, randomly changes prefixes etc etc

  58. Menel

    moparisthebest: that sounds honestly really good for testing😀

  59. flow

    In general, an interoperability testsuite that checks for such mistakes implementations are known to make would be a good idea

  60. pep.

    chaosproxy

  61. moparisthebest

    GREASE is about testing the points we know should be flexible, but in production where, let's face it, is the only place many things are actually tested lol

  62. moparisthebest

    pep.: hmm very nice I might steal that name lol

  63. stpeter

    Have we had any discussion about the forthcoming CRA legislation? I just now glanced at https://blog.nlnetlabs.nl/open-source-software-vs-the-cyber-resilience-act/ and https://www.internetsociety.org/blog/2022/10/the-eus-proposed-cyber-resilience-act-will-damage-the-open-source-ecosystem/ - their warnings are concerning.

  64. Ellenor Malik

    empp

  65. flow

    In general, an interoperability testsuite that checks for such mistakes, implementations are known, to make would be a good idea

  66. wurstsalat

    Hi folks! I plan to let go of our renewal policy for the software listing on xmpp.org. Until now, every maintainer had to update "last_renewed" once per year. We now have DOAP files for many actively developed clients, servers, libraries, and tools. Software providing a DOAP file would be listed in a rich list (like it is now), and software without would be listed in a simple table below, behind a "Show List" button. Any objections?

  67. Peter Waher

    👍

  68. Guus

    wurstsalat: None here

  69. stpeter

    @wurstsalat that sounds reasonable

  70. emus

    👍

  71. emus

    wurstsalat: can you call via member, jdev and standards to update and provide doaps one last time? should I?

  72. wurstsalat

    that's probably a good idea

  73. emus

    done

  74. wurstsalat

    thanks a lot!