XSF Discussion - 2022-06-16

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

Correct

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

wrong room

im reading XEP-0388

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

why am i not allowed to send a whitespace?

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

> web definitely hate it

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

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?

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

Openfire might be doing 'any other message' wrong

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

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

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

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

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 ?

Not yet

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

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

Quite a few things, in fact

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

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

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

We already have framing in XMPP over websocket

Oh, I misread what you said, ignore me

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

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

:)

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

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

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)

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

Zash: yes that would make way more sense imho

But then web clients have to implement streaming parsers

No

Servers would need to support two methods

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

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

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

Therefore ... s2s over websockets?

We can save that for the upcoming replacement to websockets

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

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?

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

Gotta start somewhere I guess

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

Fix your providers and firewalls!

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

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

I don't want to live in that future

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

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

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

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

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

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

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

With s2s the hard part is usually the outgoing connections

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

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

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

https://cerdale.zash.se/s/2en3dRC9dwgWwPKHZtZr_yhq/284d07c9-6d8a-4efc-a985-abbb037e5650.png

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

Just 1 ! :)

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

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

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

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

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

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

I bet a ton of things let you send whitespace