XSF Discussion - 2024-05-22

MSavoritias fae.ve, I think there are multiple proposals. the problem probably isn't lack of proposals, it is lack of consensus (as so often) :) ✏

maybe. also lack of a person with time to actually push this forward i would say

(not pointing any fingers obviously, we all have our own projects/things)

sure

> Well iirc some domains cannot be used in a jid ever is that true? the JID spec just points to the IDNA2003 spec ↺

lovetox: JIDs are encoded in unicode instead of using idna. JIDs also must pass stringprep...

> lovetox: JIDs are encoded in unicode instead of using idna. JIDs also must pass stringprep... this sentence is on many levels wrong, maybe read https://xmpp.org/rfcs/rfc6122.html#addressing-domain As i wound have understood is, every domain is supported, especiall internationalized ones with non-ascii characters, should be no problem in xmpp ↺

lovetox: yes, that section easily describes the problem

enlighten me?

The domainpart is encoded as unicode

And then we apply stringprep

it's the same problem as for resources, but for domain names

you mean we apply the nameprep profile, the profile specifically made for Internationalized Domain Names ?

and this would be only the case if you follow the obsolete rfc6122, if you follow the rfc7622 it completely offloads to the IDNA2008 spec

so you would interpret https://www.rfc-editor.org/rfc/rfc7622.html#section-3.2 to mean not to run nameprep?

> and this would be only the case if you follow the obsolete rfc6122, if you follow the rfc7622 it completely offloads to the IDNA2008 spec Can't do it without fracturing the public federated network ↺

as the whole section does not mention nameprep, it would be surprising to me if you read that

> Can't do it without fracturing the public federated network i highly doubt it, the whole world moved from idna2003, to idna2008, email clients, browsers, etc., not saying that this is painless, but saying its impossible and no jid "ever" will be able to contain these characters .. is a bit hyperbolic ↺

particular for domain names i think it would be not a big deal there exist even compatibility mappings which soften the transition

https://www.unicode.org/reports/tr46/

are we expecting many xmpp servers running on IDNA2008 incompatible domain names?

It's been a long time since I looked up the details but iirc precis isn't backwards compatible with stringprep, validates and changes JIDs differently, and there's no negotiation so: 1. The entire network, all clients and servers, have to update all at once on a flag-day (never gonna happen) 2. Bits update individually breaking everyone (so never gonna happen)

yes and there are IDNA2003 Domains that are incompatible with IDNA2008 domains, did the world have a flag day?

if you think im proposing everyone should uncoordinate just go for precis and yolo it

We not only have domains (we could roughly check those) but also localparts we cannot check

no, of course not, but a plan can be formulated and then executed

yes localparts are surley the biggest problem

Please do so then, but I'm skeptical it can be done

first step would be to give server operators a tool that lets them check if they even have incompatible localparts

If you pulled off a miracle and got all code updated tommorow, Arch users would be running it next week and Debian users not for a decade

For domains, registrars can just not let you register domains where there would be idna 2003 vs 2008 problems

moparisthebest, we could also propse a new rfc, that says localpart stays the same

and only resources and domains are upgraded

I only heard of one case where ß was involved

yeah i think domain is the least problem, i think all servers could simply check for idna2008 compatibility and its fine

this transition was already done by other people for us

lovetox: so when you find users that are broken... Then what?

You can just migrate them to another jid with... Oh right that doesn't exist 💀

Option 1: New spec that says localpart stays at strinprep, i see no problem with that, we dont need precis there. Option 2: Tell the users with a long perioid of time, to register a new account

Option 3: Define new MUC spec that makes nickname independent from resource -> No precis for resource necessary

there are 3 problems, and i think they should be split up into its own solutions

https://xkcd.com/1172/

> Option 2: Tell the users with a long perioid of time, to register a new account "Did you just tell me to go fuck myself?" "I believe I did, Bob" https://howfuckedismydatabase.com/nosql/

I would be *very* annoyed if my jid, which is the same as my email, and my name, ever had to change ever...

It's not a problem for me personally but I assume some Germans out there feel the same

you picked a bad example, precis is better for german names

there are only 4 special chars in german, ßöäü

öäü behave the same between strinprep and precis

and ß is mapped in strinprep to "ss" which means the user cannot have this char in his jid

but with precis its now possible.

so everything fine, german usernames -> ✅️

yeah, the localpart and resourcepart things are annoying from time to time, but the domain one is really my main concern. if no one is actually using nameprep in their code in practise then maybe it's fine?

Is there an example of an actual problem in real life?

thats also was interesting, everyone is always stating theoretical problems .. lets get down to it, provide tools for server operators to check their userbase

and get some stats on it

For example with my jid :). But actually it wasn't really a problem

IIRC there was a domain like straße.example (xn--something) where strasse.example was owned by a different party, but I believe registrars try harder to avoid that kind of thing these days.

There's also some kind of IDNA 2008 compatibility processing so ß == ss still

Yes I posted the link above

tr46? ah, right yes precisely

> thats also was interesting, everyone is always stating theoretical problems .. lets get down to it, provide tools for server operators to check their userbase I mean, the question just comes down to if any servers or clients are currently running nameprep on jids or not

In Gajim we accept both standards

And so in my opinion every client should

I see no reason for a client to strictly enforce stringprep

I see the need sometimes to pre validate a jid in the GUI. But it's ok if this check is not 100%.

lovetox: do you do any normalization for display though?

for localparts? how would that be possible?

this is not a reversible mapping

for a reversible mapping we have XEP-0106

Well, anything, might open up some impersonation attacks

have some http://www.unicode.org/reports/tr39/ for that

dont we have this problem "simply" because we have usernames and users can pick their name in a chat?

It applies to muc nicks and JID localparts the same no?

precis filters out look a likes

or better said, maps them to other characters ✏

but to answer your question, no we dont have any measures for look a like usernames in Gajim

> It applies to muc nicks and JID localparts the same no? right that was my understanding

here some stats i quickly gathered between precis and stringprep *just for localpart*

Codepoints: Allowed 88476 Allowed only in nodeprep 6259 Allowed only in precis 43350 Allowed but differently mapped 72

here i gathered all codepoints

https://share.hoerist.com/philipp/pVfdRcGzuw4Js1hS/precis_nodeprep_analysis.txt

i think the differnet mappings are not really a problem

and its suprising what is allowed in nodeprep

this is currently an allowed JID, ⢸⢸⢸⢸⢸⢸⢸⢸⢸⢸⢸⢸⢸@test.com

:D

or ⥂⥂⥂⥂@test.com

i hope to god my jid preparation is not completely wrong :D

here for resourceprep the analysis

https://share.hoerist.com/philipp/JkU6D6KaNswNUr8j/resourceprep_preics_analysis.txt

only 285 ! characters are only in resourceprep allowed

lovetox: I'm working on a C++Qt PRECIS lib. Can you help me validate it when ready? :)

i simply looped through the intergers 1 -> 1.000.000 and passed them to this python lib https://pypi.org/project/precis-i18n/