jdev - 2019-09-07

stringprep with unicode 3.2, as specified in RFC 6122, does not allow that nickname ✏

It's the revenge of the 🤖

R-R-R-Robot face

is that so

�"Z▒u$�܀�w����Bs��ё.�B�}Q������yu WK����'=J06��W�E�!��▒�ܖ�[�ڃ5���2&K�x�s��c �d� ^M���S���*I��(�3��xo�C�FKG%��3��^ݜ�������6`6�Y+"U�0n^V�4�ʔ^m%�Q=�K�z&閈B4�Ex��\�����h�Q[��{�ᤉ!'�6���\+K�E98c���K�@N��++x�R�T|H�-���Ϙ�,���$�

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.

My client gives me a popup saying that a stanza was received from an invalid jid and therefor ignored

whenever that person with a lips pictogram in their name changes presence state in the chat

that's also strange because I can't join groupchats with emojis for username

tom, you may want to update your client, I believe it was fixed in the following version.

tom: upgrade your Gajim

i see so that's not a protocol limitation

Would you prefer your server to stop talking to the MUC?

no

i'll just change the code

*in the client

Now maybe you understand why I mentioned trying to backport master stuff, or starting from master even :)

Fixes, fixes everywhere! (And bugs)

Unicode is fun :)

Forward compatibility is fun!

This is me now

How are references like this updated in RFCs? (Unicode has a bit more than 3.2 releases now)

pep.: another rfc that updates or replaces it

Well we could move to precis

But it's complicated

No implementation we can use yet that I'm aware of

But then precis also uses a specific version of Unicode right

Someone said yesterday they wanted to add PRECIS support to jid-rs!

Does it?

it's not finished until you can implement a full virtual machine in it plus 2 variants of javascript

Does it?

I thought that was the point of precis not to

It doesn't?

Ah ok

Who knows

Cool then

Kinda moot until there are implementations

Bootstrap issues?

Is it hard to implement? I thought the point was also to make it easier

It's going to be fun when things start breaking because somebody does something else than stringprep

Robot face all over again

Microsoft will just make another special snowflake encoding before that

Just ensure that your implementation breaks in the most annoying way possible on remote-attacker-controlled data. You'll be fine.

Will do

pep., no, precis does not use a specific version of unicode, which will be a rats nest of trouble

given that Unicode does make breaking changes between releases

there goes any validation we can reasonably do without breaking federation

except if we do things like rolling unicode-release upgrades through the network, which seems like a PITA to do

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

problem is, there’s no updating of the RFC involved for unicode upgrades

there’s no way to tell what version your peer uses

(for any definition of peer)

this also affects normalisation of stuff during login, which has the potential to lock folks out of their accounts

Is that also a reason we need <moved/>? :/

I don’t think this has anything to do with <moved/>?

stuff like that can happen on minor glibc upgrades for example

see the breakage that one glibc (unicode) update caused on postgres indices

I mean, people locked out of their accounts, that could be one use-case

yeah, eh, I don’t think that we should let it come to that?

:x

Amnezia 😕 😕 😕