tom, your server would abort your connection if you were to send non-UTF-8 characters, so your client most likely prevented you from doing so.
tom
My client gives me a popup saying that a stanza was received from an invalid jid and therefor ignored
lksjdflksjdfhas joined
tom
whenever that person with a lips pictogram in their name changes presence state in the chat
tom
that's also strange because I can't join groupchats with emojis for username
linkmauve
tom, you may want to update your client, I believe it was fixed in the following version.
Ge0rG
tom: upgrade your Gajim
tom
i see so that's not a protocol limitation
Zash
Would you prefer your server to stop talking to the MUC?
tom
no
tom
i'll just change the code
tom
*in the client
pep.
Now maybe you understand why I mentioned trying to backport master stuff, or starting from master even :)
pep.
Fixes, fixes everywhere! (And bugs)
Zash
Unicode is fun :)
Ge0rG
Forward compatibility is fun!
͡ ͡_has left
͡ ͡
This is me now
pep.
How are references like this updated in RFCs? (Unicode has a bit more than 3.2 releases now)
Zash
pep.: another rfc that updates or replaces it
Daniel
Well we could move to precis
Daniel
But it's complicated
Zash
No implementation we can use yet that I'm aware of
pep.
But then precis also uses a specific version of Unicode right
linkmauve
Someone said yesterday they wanted to add PRECIS support to jid-rs!
Daniel
Does it?
͡ ͡
it's not finished until you can implement a full virtual machine in it plus 2 variants of javascript
Zash
Does it?
Daniel
I thought that was the point of precis not to
pep.
It doesn't?
pep.
Ah ok
Daniel
Who knows
pep.
Cool then
Zash
Kinda moot until there are implementations
pep.
Bootstrap issues?
Daniel
Is it hard to implement? I thought the point was also to make it easier
pep.
It's going to be fun when things start breaking because somebody does something else than stringprep
Zash
Robot face all over again
͡ ͡
Microsoft will just make another special snowflake encoding before that
Ge0rG
Just ensure that your implementation breaks in the most annoying way possible on remote-attacker-controlled data. You'll be fine.
Zash
Will do
rionhas left
rionhas joined
͡ ͡has left
rionhas left
rionhas joined
͡ ͡has joined
jonas’
pep., no, precis does not use a specific version of unicode, which will be a rats nest of trouble
jonas’
given that Unicode does make breaking changes between releases
jonas’
there goes any validation we can reasonably do without breaking federation
jonas’
except if we do things like rolling unicode-release upgrades through the network, which seems like a PITA to do
pep.
But then are you happy being stuck with Unicode 3.2? If Unicode breaks then we'll have to break anyway whenever we update the RFC. And of course it won't happen all at the same time in implementations
jonas’
problem is, there’s no updating of the RFC involved for unicode upgrades
jonas’
there’s no way to tell what version your peer uses
jonas’
(for any definition of peer)
jonas’
this also affects normalisation of stuff during login, which has the potential to lock folks out of their accounts
pep.
Is that also a reason we need <moved/>? :/
jonas’
I don’t think this has anything to do with <moved/>?
jonas’
stuff like that can happen on minor glibc upgrades for example
jonas’
see the breakage that one glibc (unicode) update caused on postgres indices
pep.
I mean, people locked out of their accounts, that could be one use-case
jonas’
yeah, eh, I don’t think that we should let it come to that?