XSF Discussion - 2022-11-24

edhelas: let us know your feedback.once your have reviewed!

feedback.once would be a great domain name for throwaway accounts

I also would not want to run it

😂🤣😂🤣 that is a great idea

^^ my onscreen keyboard has a narrow spacebar :-)

emus Looks interesting, I just asked a small question MattJ regarding the fundraising restrictions, I currently have a Patreon

Ok!

I have another small question related to MUC

If I receive a chat message from a MUC and that I am considered disconnected, should I guess that I'm still connected ?

(it's a bit like a reversed Shrödinger :p)

hmm good question, I wonder if there is a "Am I still joined" query clients could perform

edhelas: the matrix bridge used to ignore presence-unavailable sent to it.

edhelas: I documented the ways in https://xmpp.org/extensions/xep-0410.html#selfpresencecheck

meanwhile, we got GC 1.0 joins banned from most server implementations! \o/

I have the issue with biboumi actually, I'll have to investigate the logs, but looks like I receive some disconnection presence, but still be connected behind

edhelas: biboumi also has configurable persistent rooms, so it stays joined even if you disconnect from the bridge, and it used to have issues with multiple clients connected at the same time

edhelas: maybe there are also issues with Carbons of messages on your end

Is ```foo@bar ``` trailing space a valid jid?

Is tripple backquotes used as span valid?

No. Spaces not allowed in domainpart

Spaces are allowed in nameprep, but not in DNS. HAVE FUN!

As in, IDNA will be unhappy about spaces

What about unqualified hostnames ie text labels that can be resolved on a local network? ✏

Which RFCs are you thinking of? The dejure or defacto ones? :)

RFC-7622 says it needs to be a valid FQDN or IP address, but couches that FQDN isn't a properly defined term. It also refers to RFC-5890, which does get specific about character sets, but I've not properly parsed them.

I'm reading 7622

https://www.rfc-editor.org/rfc/rfc3491#section-5 note the absense of 'Table C.1.1' which is the one containing regular space https://www.rfc-editor.org/rfc/rfc3454#appendix-C

Daniel, > The domainpart for every XMPP service MUST be a fully qualified > domain name (FQDN), an IPv4 address, an IPv6 address, or an > *unqualified hostname* (i.e., a text label that is resolvable on a > local network).

https://www.rfc-editor.org/rfc/rfc7622#section-3.2

s/FQDN/DNS name/

also https://www.rfc-editor.org/errata/eid5769

7622 points to IDNA2008 which points to STRINGPREP which defines nameprep which does not forbid 0x20 in its output.

So it's a valid jid?

at least we can not come up (yet) with something that forbids "bar " as domainpart

if leading and trailing spaces in domainpart are sensible is another question (I want to say, no)

You can't look up such a domain in DNS tho, because something somewhere in IDNA2008 forbids that

Suddenly too dizzy for reading RFCs.

And still waiting for https://unicode-org.atlassian.net/browse/ICU-11981 for Prosody :/

We've asked a dozen xmpp libraries if a single space is a valid xmpp address and here are the results. 🥁

jxmpp's string-testframework only reports rocks-xmpp-precis rejecting "foo@bar " as jid

that said, simply always trim user-provided JID strings and hope for the best when encountering them over the wire

and I think there must be somting prevting whitespace in U-labels

the protocol laywer in me wants to find out, but first SIGFOOD

Catch 22: Must have energy to make food. Must have food to have energy.

so U+0020 is IDNA2008 disallowed

https://www.unicode.org/Public/idna/idna2008derived/Idna2008-15.0.0.txt

which makes it invalid in U-labels

assuming a domainpart can be either (A) a DNS name, (B) an IP address or (c) a "hostname"

we just established that spaces are not allowed in (A)

no production of IP addresses allows spaces, so it's also not (B) ✏

which only leaves C, but since hostnames are often modelled after DNS names, it should be also safe to say that spaces are there not allowed

I would imagine a "hostname" to be a single U-label or somesuch

I think most Unixes allow hostname to be longer than DNS labels are allowed to be

But every sane person would choose a hostname that qualifies as U-label (if not A-label)

7622's ABNF says > domainpart = IP-literal / IPv4address / ifqdn > ifqdn = 1*1023(domainbyte) > ; a "domainbyte" is a byte used to represent a > ; UTF-8 encoded Unicode code point that can be > ; contained in a string that conforms to RFC 5890 so, whatever the _meaning_ of "ifqdn" is, I think it's pretty clear that it only allows IDNA chars

but I dunno if comments in ABNF are normative ;) ✏

flow [19:32]: > But every sane person would choose a hostname that qualifies as U-label (if not A-label) Are you calling pentesters insane?

Or regular old QA testers?

And once we are through U+20, there is the non breaking space and the invisible space as well!

those are forbidden for real tho

Nobody forbade space because it's so obviously wrong?

:D

There's "forbidden" and there's "technically allowed but so likely to cause issues everywhere no one should do it"

I recall once dealing with a poor lady who's email was something like "Mary.O'Brien@domain.com" and you wouldn't believe the problems she had

On the other hand she found many a SQL injection vulnerability...

Thank glob we have stricter rules for addresses than email :) ✏

Has there ever been a proposal for a disco feature to say "doesn't expect chats"?

Not that I can recall.

Some complain that the baseline feature set of XMPP is too sparse, and here I too wish basic messaging was opt-in too. :)

singpolyma, what's your use case?

Zash: being able as a client to default to something other than chat ui for contacts that don't take chats, which includes most but not all components

It would be good, but does it make sense to advertise negative features?

I note that Converse.js won't show a message input box if you open a chat with a host jid (without localpart), which made it awkward when I made a chat interface for pubsub

Zash: yeah, I'd like to avoid "just assuming" for exactly that kind of reason

I can't really think of another negative feature that makes sense

It's basically a UI hint

Explicit > implicit