linkmauvetom, 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.
tomMy client gives me a popup saying that a stanza was received from an invalid jid and therefor ignored
lksjdflksjdfhas joined
tomwhenever that person with a lips pictogram in their name changes presence state in the chat
tomthat's also strange because I can't join groupchats with emojis for username
linkmauvetom, you may want to update your client, I believe it was fixed in the following version.
Ge0rGtom: upgrade your Gajim
tomi see so that's not a protocol limitation
ZashWould you prefer your server to stop talking to the MUC?
tomno
tomi'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)
ZashUnicode is fun :)
Ge0rGForward 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)
Zashpep.: another rfc that updates or replaces it
DanielWell we could move to precis
DanielBut it's complicated
ZashNo implementation we can use yet that I'm aware of
pep.But then precis also uses a specific version of Unicode right
linkmauveSomeone said yesterday they wanted to add PRECIS support to jid-rs!
DanielDoes it?
͡ ͡it's not finished until you can implement a full virtual machine in it plus 2 variants of javascript
ZashDoes it?
DanielI thought that was the point of precis not to
pep.It doesn't?
pep.Ah ok
DanielWho knows
pep.Cool then
ZashKinda moot until there are implementations
pep.Bootstrap issues?
DanielIs 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
ZashRobot face all over again
͡ ͡Microsoft will just make another special snowflake encoding before that
Ge0rGJust ensure that your implementation breaks in the most annoying way possible on remote-attacker-controlled data. You'll be fine.
ZashWill 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?