XSF Discussion - 2022-06-16

  1. Tobias

    HTTP File Upload should work from within a browser, considering correct CORS headers are set, right?

  2. MattJ


  3. Tobias

    https://pastebin.com/raw/DeG71TxK any clues why it would say "unknown slot"

  4. Tobias

    wrong room

  5. lovetox

    im reading XEP-0388

  6. lovetox

    > At any time while authentication is in progress, neither Client nor Server sends any element (including stanzas) or other data except the top-level elements defined herein. Clients MUST NOT send whitespace, and MUST send only <response/> elements as appropriate or an <abort/> element to immediately cause an error.

  7. lovetox

    why am i not allowed to send a whitespace?

  8. moparisthebest

    Unsure about this, I think I hate it https://delta.chat/en/2022-06-14-webxdcintro

  9. Zash

    > web definitely hate it

  10. moparisthebest

    I can't find info about how they are sandboxed, which makes me think they put no thought into that and assumed ancient vuln riddled Android bundled webview is enough, yikes

  11. Guus

    what is the intended behavior in pubsub, when a subscriber (subscribed with a bare JID) is online with more than one resource, when a new publication occurs?

  12. Zash

    Guus: event notification sent to the bare jid, receiving server does forking like with any other message?

  13. Guus

    Openfire might be doing 'any other message' wrong

  14. MattJ

    moparisthebest: time to bundle converse.js as a .xdc?

  15. moparisthebest

    MattJ: ooh ingenious, suddenly all 50 deltachat users are now XMPP users

  16. MattJ

    https://docs.webxdc.org/spec.html#messenger-implementation has some notes about sandboxing

  17. moparisthebest

    So... No internet access other than they can transmit unlimited messages? :thinking:

  18. moparisthebest

    Anyone get a chance to look at https://xmpp.org/extensions/inbox/xmpp-over-quic.html or https://xmpp.org/extensions/inbox/websocket-s2s.html yet ?

  19. MattJ

    Not yet

  20. Zash

    They looked short and I'm skeptical of keeping the framing that was added because browser clients supposedly can't parse streaming XML.

  21. MattJ

    Zash, even before websockets there were people arguing for framing. I'm not strongly one way or the other, but it certainly makes some things easier

  22. MattJ

    Quite a few things, in fact

  23. moparisthebest

    Not changing websocket at all makes it trivial to add support with approximately one if statement

  24. moparisthebest

    I would argue for XMPP 2.0 we should add explicit framing even for TLS/quic streams

  25. moparisthebest

    Not having it is the source of countless bugs and security issues

  26. MattJ

    We already have framing in XMPP over websocket

  27. MattJ

    Oh, I misread what you said, ignore me

  28. Zash

    I mean the XML fiddlery that makes xmpp-over-ws ≠ xmpp + ws

  29. Zash

    MattJ, weren't all our recent security and memory consumption issues _because_ of per-message XML parsing?

  30. MattJ


  31. moparisthebest

    Yea I don't like the changing namespace, I would love to keep it jabber:server actually

  32. Zash

    And I think I just dropped 25% of RSS by cutting down on similar stuff.

  33. Zash

    If anything I'd want a websocket subprotocol where you just send normal XMPP over websocket (with the websocket framing, but without the <open/> and whatnot)

  34. moparisthebest

    The prosody memory hog bug was due to lack of framing and so was the recent zoom ejabberd/gloox bug

  35. moparisthebest

    Zash: yes that would make way more sense imho

  36. MattJ

    But then web clients have to implement streaming parsers

  37. Zash


  38. Zash

    Servers would need to support two methods

  39. moparisthebest

    They can just pretend the stream header is a stand alone stanza

  40. MattJ

    Zash, I'm not a fan of yet more ways to do things

  41. MattJ

    More ways to do things -> more surface area to maintain and for bugs and security issues to hide in

  42. Zash

    Therefore ... s2s over websockets?

  43. moparisthebest

    We can save that for the upcoming replacement to websockets

  44. Zash

    s2s over tcp + s2s over tls isn't enough?

  45. Zash

    If it's meant to solve the problem that certain hosting providers are strictly http-only, isn't this _not_ going to solve that until 100% of servers implement it?

  46. Zash

    A problem IMO should be solved by not giving such providers any business whatsoever

  47. moparisthebest

    Gotta start somewhere I guess

  48. MattJ

    Yeah, I'm not really sure about s2s-over-ws

  49. Zash

    Fix your providers and firewalls!

  50. moparisthebest

    I've already seen a hundred questions in Snikket about why it can't run behind an http proxy

  51. Zash

    Working around those problems just moves us towards the future where only the web is allowed

  52. Zash

    I don't want to live in that future

  53. moparisthebest

    It's already here, we live in the bad place

  54. MattJ

    moparisthebest, and you want to replace them with "why can't I contact someone on <any other XMPP domain>?" :)

  55. moparisthebest

    I get the impression those people don't know federation exists anyway

  56. Zash

    Other wording of that is that you have the same deployment problem as DANE&DNSSEC

  57. MattJ

    We already have some of that simply due to requiring valid TLS certificates!

  58. MattJ

    Which you would think wouldn't be too much to ask in 2022

  59. moparisthebest

    I think the whole point is servers that already implement c2s websocket can turn this on easily

  60. Zash

    With s2s the hard part is usually the outgoing connections

  61. Zash

    At least it has been in Prosody every time, i.e. for IPv6 and direct TLS

  62. Zash

    and unless you mean your proxy, I imagine some refactoring would be needed for incoming too

  63. moparisthebest

    Fair... I just took all that away from prosody, xmpp-proxy does all the lookups and TLS

  64. Zash


  65. moparisthebest

    Prosody just accepts plan TCP on localhost and makes plain TCP connections to a hardcoded localhost port for everything outgoing and that's it

  66. moparisthebest

    Just 1 ! :)

  67. Zash

    That's how it starts. Just ask the web people

  68. flow

    lovetox, good question why it's strictly forbidden, however there also doesn't seem to be much use of whitespace pings during SASL auth

  69. flow

    as there is always one entity that needs to send something at any point in time during auth

  70. Zash

    Doesn't that text exist about the existing SASL exchange?

  71. Zash

    Yeah, https://xmpp.org/rfcs/rfc6120.html#sasl-rules-data

  72. Zash

    I think Dave or someone said it's a leftover from when SASL also provided the security layer that these days are provided by TLS

  73. moparisthebest

    I bet a ton of things let you send whitespace