@hongminhee @liaizon @Edent @north @Profpatsch (1/3)
-
@jdlh @hongminhee @liaizon @Edent @north
Cool overview, I didn’t know the same topic came up last time as well!
For flohmarkt, the current implementation uses a python module that implements https://www.rfc-editor.org/rfc/rfc8264 (the PRECIS framework), in particular the username profiles, and then does another check to prevent multiple scripts from being used (based on https://www.unicode.org/Public/UNIDATA/Scripts.txt )
though that’s just what I came up with myself.
@jdlh @hongminhee @liaizon @Edent @north The current source for this is here: https://codeberg.org/flohmarkt/flohmarkt/src/commit/58f4904f35956081ab34ac674e3e39cdef768cbb/flohmarkt/username_validation.py
-
@jdlh @hongminhee @liaizon @Edent @north The current source for this is here: https://codeberg.org/flohmarkt/flohmarkt/src/commit/58f4904f35956081ab34ac674e3e39cdef768cbb/flohmarkt/username_validation.py
@jdlh @hongminhee @liaizon @Edent @north The main problem I see with this rn is that not every language has a good library implementation of PRECIS, funnily enough golang has it in x/text https://pkg.go.dev/golang.org/x/text/secure/precis
-
@jdlh @hongminhee @liaizon @Edent @north
Cool overview, I didn’t know the same topic came up last time as well!
For flohmarkt, the current implementation uses a python module that implements https://www.rfc-editor.org/rfc/rfc8264 (the PRECIS framework), in particular the username profiles, and then does another check to prevent multiple scripts from being used (based on https://www.unicode.org/Public/UNIDATA/Scripts.txt )
though that’s just what I came up with myself.
@Profpatsch @hongminhee @liaizon @Edent @north
> Cool overview, I didn’t know the same topic came up last time as well!
I was the one who attended the 2025-10 Fediforum, and proposed the topic then. I am persistent. 
-
@jdlh @hongminhee @liaizon @Edent @north The main problem I see with this rn is that not every language has a good library implementation of PRECIS, funnily enough golang has it in x/text https://pkg.go.dev/golang.org/x/text/secure/precis
@jdlh @hongminhee @liaizon @Edent @north Another part of this is that the admin is allowed to choose which scripts are allowed in usernames, e.g. a flohmarkt hosted in India may allow Devanagaric but an admin in Europe who can’t read it usually does not want users to sign up with weird usernames.
-
@jdlh @hongminhee @liaizon @Edent @north Another part of this is that the admin is allowed to choose which scripts are allowed in usernames, e.g. a flohmarkt hosted in India may allow Devanagaric but an admin in Europe who can’t read it usually does not want users to sign up with weird usernames.
@jdlh @hongminhee @liaizon @Edent @north We also support Anatolian Hieroglyphs if you really want them
-
@jdlh @hongminhee @liaizon @Edent @north
Cool overview, I didn’t know the same topic came up last time as well!
For flohmarkt, the current implementation uses a python module that implements https://www.rfc-editor.org/rfc/rfc8264 (the PRECIS framework), in particular the username profiles, and then does another check to prevent multiple scripts from being used (based on https://www.unicode.org/Public/UNIDATA/Scripts.txt )
though that’s just what I came up with myself.
@Profpatsch @hongminhee @liaizon @Edent @north
> For flohmarkt, the current implementation uses a python module that implements … (the PRECIS framework), in particular the username profiles, and then does another check…This is a reasonable choice, since you had to come up with something for yourself. But for #GloballyInclusiveHandles to succeed long-term, I think there needs to be:
1. a specification which removes the burden from developers, of deciding which characters should be allowed and not allowed for creating handles. System admins should also be also be able restrict users to certain scripts within this specification.
2. Recognition that accepting handles is different from creating handles. It is important that most systems accept any handle which fits the whole specification, even if the system would not generate that handle itself. Otherwise users will get frustrated by their handle working then not working, depending on the system.
-
@Profpatsch @hongminhee @liaizon @Edent @north
> For flohmarkt, the current implementation uses a python module that implements … (the PRECIS framework), in particular the username profiles, and then does another check…This is a reasonable choice, since you had to come up with something for yourself. But for #GloballyInclusiveHandles to succeed long-term, I think there needs to be:
1. a specification which removes the burden from developers, of deciding which characters should be allowed and not allowed for creating handles. System admins should also be also be able restrict users to certain scripts within this specification.
2. Recognition that accepting handles is different from creating handles. It is important that most systems accept any handle which fits the whole specification, even if the system would not generate that handle itself. Otherwise users will get frustrated by their handle working then not working, depending on the system.
@jdlh @hongminhee @liaizon @Edent @north
Oh yeah, definitely I only do the validation on username selection, not when e.g. logging in a user or resolving webfinger.
But PRECIS is … precisely such a specification. Maybe not the best way to do it, I think @aumetra has a different approach based on unicode classes or something
-
@jdlh @hongminhee @liaizon @Edent @north
Oh yeah, definitely I only do the validation on username selection, not when e.g. logging in a user or resolving webfinger.
But PRECIS is … precisely such a specification. Maybe not the best way to do it, I think @aumetra has a different approach based on unicode classes or something
@Profpatsch @jdlh @hongminhee @liaizon @Edent @north
Yeah, my approach here is to use UTS#39, which is explicitly made with the intent of getting around the problem of confusables. I chose HighlyRestrictive for now since it still allows for things such as "지호Park", without maybe going into questionable territory.
In addition I have checks in place to only allow characters from the unicode classes alphabetical and numerical. So no random emoji, but you can have something like "二十五" as your username (which falls IIRC under the numeric class)(moved accounts recently, not on @aumetra anymore :P)
-
@Profpatsch @jdlh @hongminhee @liaizon @Edent @north
Yeah, my approach here is to use UTS#39, which is explicitly made with the intent of getting around the problem of confusables. I chose HighlyRestrictive for now since it still allows for things such as "지호Park", without maybe going into questionable territory.
In addition I have checks in place to only allow characters from the unicode classes alphabetical and numerical. So no random emoji, but you can have something like "二十五" as your username (which falls IIRC under the numeric class)(moved accounts recently, not on @aumetra anymore :P)
@Profpatsch @jdlh @hongminhee @liaizon @Edent @north ..and on the database level (in my case Postgres) I use a non-deterministic und-u-ks-level1 collation, which should take care of NFC vs NFD vs NFKC vs NFKD and ignore differences in casing and accents
-
@jdlh @hongminhee @liaizon @Edent @north
Oh yeah, definitely I only do the validation on username selection, not when e.g. logging in a user or resolving webfinger.
But PRECIS is … precisely such a specification. Maybe not the best way to do it, I think @aumetra has a different approach based on unicode classes or something
-
@Profpatsch @jdlh @hongminhee @liaizon @Edent @north @aumetra Have you considered publishing a FEP about this?
@silverpill @Profpatsch @hongminhee @liaizon @Edent @north @aumetra
I have considered publishing an FEP about #GloballyInclusiveHandles . At FediForum six months ago I got the advice to write three:
1. Advocating for #GloballyInclusive handles and laying out requirements and issues
2. Explaining prior art from #Unicode technical annexes on domain names and identifiers, #ICANN label generation rules for DNS, #UniversalAcceptance, email addresses, etc.
3. Advocating for linkification of globally inclusive handles and layout out requirements and issues.
Do those sound like good FEPs to write at this point? -
@silverpill @Profpatsch @hongminhee @liaizon @Edent @north @aumetra
I have considered publishing an FEP about #GloballyInclusiveHandles . At FediForum six months ago I got the advice to write three:
1. Advocating for #GloballyInclusive handles and laying out requirements and issues
2. Explaining prior art from #Unicode technical annexes on domain names and identifiers, #ICANN label generation rules for DNS, #UniversalAcceptance, email addresses, etc.
3. Advocating for linkification of globally inclusive handles and layout out requirements and issues.
Do those sound like good FEPs to write at this point?@jdlh @Profpatsch @hongminhee @liaizon @Edent @north @aumetra Yes, sounds good, though it might be better to combine these FEPs into a big one because the topics are related (perhaps in a collaboration with @Profpatsch ?)
-
@jdlh @Profpatsch @hongminhee @liaizon @Edent @north @aumetra Yes, sounds good, though it might be better to combine these FEPs into a big one because the topics are related (perhaps in a collaboration with @Profpatsch ?)
