It's confirmed in code (all paths run through this regex):

const webfingerRegex = /^(@|acct:)?[\p{L}\p{N}\p{M}_.-]+@.+$/u; 

There were two places that could be cause for concern:

1. My Activity Intents implementation (@benpate@mastodon.social) uses a naive regular expression that only accepts ASCII, but this is not webfinger and is a bug I can fix to use the proper regular expression.

2. Requests to NodeBB requesting the unicode form of a domain will not match, because NodeBB expects punycode. This is compliant with the RFC. Likely browsers will natively translate unicode to punycode over the wire, but uncertain here.

Both of those are relatively minor, so broadly, NodeBB checks all the boxes.

@evan@cosocial.ca

Support for non-ASCII Webfinger handles · Issue #282 · evanp/activitypub-bot

We need to confirm the following functionality: Receive: Can local users receive activities from a remote account with a non-ASCII handle? Send: Can local users send activities to a remote account with a non-ASCII handle? Link: Are non-A...

GitHub (github.com)

I'm going to go after onepage.pub next; it's a completely different codebase.

#ActivityPub #Webfinger #i18n #GloballyInclusiveHandles

https://www.npmjs.com/package/webfinger
https://www.npmjs.com/package/activitypub-webfinger

#ActivityPub #WebFinger #i18n #GloballyInclusiveHandles

PS. Weird that this time the opengraph preview of the issue carries complete information, including the title.

I am sorry, but without money and income looking for jobs I am holding off on any deeper fedi involvement rn. It just occurred to me there might be a small and steady no. of TF's around various cross-cutting concerns that neatly slice protocol design space into natural parts, and help attract stakeholders other than devs interested in one particular narrow theme.

More musing out loud..

- Interoperability and extensibility
- Security and privacy
- Connectivity and portability
- Internationalization and localization
- Trust and safety (DEI)
- Fediverse solution development

The last one would aggregate initiatives to define building blocks for common business and application domains (Groups, Forums, Geosocial). Particularly well-suited to set up a great web portal around.

For posterity I added this to an existing issue at the SWICG.. https://github.com/swicg/activitypub-api/issues/66

@jdlh @evanprodromou @swf

As a music major and a serious solfege geek, this seems so tailored to me.

@jdlh@mstdn.ca @evanprodromou@socialwebfoundation.org

@evan @evanprodromou @jdlh @Edent

I too think internationalized handles are a good idea. Sarcasm aside, it is not about fairness. That is not the point I raised. People will just never type a handle they are unable to type. Thus the fediverse while becoming more inclusive in one regard, on the other it will fragment. The issue comes up more often in other technology areas. See the response by @jdlh

Solresol - Wikipedia

(en.wikipedia.org)

@smallcircles @jdlh @Edent

We could make things fair by using character sets that are in Unicode but rare in every language, like Deseret, Bamum, or Glagolitic.

Deseret alphabet - Wikipedia

(en.wikipedia.org)

Bamum script - Wikipedia

(en.wikipedia.org)

Glagolitic script - Wikipedia

(en.wikipedia.org)

That way, everyone is doing the same amount of work with transliterating.

We also have biweekly meetings and a mailing list!

Some notion of an alternate, inter-operable address has also been proposed for email and postal addresses, e.g. S42 (https://www.address.post/Home/Addressstandard). We may eventually want something similar for the Fediverse.

Address Standard

address autocomplete, address cleansing, address data, address data quality, address format, address input, address input form, address lines, address quality, address solution, address validation, address verification, addressing, addressing solutions, addressing system, addressing systems, cleanse address, international address, international address format, international addressing, international addressing standard, international addressing standardisation, international postal data, mailing address format, postal address, postal address data, Postcode, postcode database, Postcodes, validate address, verify address, writting addresses

(www.address.post)

PS2. Noticing that #Github opengraph preview of an issue is non-descriptive, does not show the issue title, I can point anyone interested to @forgejo which does a better job here. Example:

Which ActivityPub applications support Client-to-Server (C2S)?

delightful-fediverse-experience - A curated list of server applications supported on the ActivityPub Fediverse and related standards.

Codeberg.org (codeberg.org)

PS. On the proliferation of SWICG task forces, just musing out loud..

The #ActivityPub Webfinger TF implies a flavor of the #Webfinger open standard. Webfinger is only a small 'moving part' within the AP protocol intrinsics.

A task force focusing more broadly on the cross-cutting concern of "Internationalization and Localization" of the entire protocol suite, might've been a better way to slice related activities.

Nice work! There's an interesting inclusion and diversity angle to this. On one hand it allows anyone to create handles in their own native language, and on the other hand it disallows most people from mentioning these handles. I'd not be able to reproduce a Japanese or Arabic handle easily, without keeping a cheat sheet somewhere, from where I copy/paste those handles. Who will do that in practice? I don't know the extent to which Latin is a common denominator between these languages and regions. Mass adoption might make the fediverse more inclusive, while driving fedizens apart in their own language bubbles. Perhaps there should be an ability to have an inclusive handle, and a Latin fallback for those not able to type the inclusive handle.

Update: Created an issue.. https://github.com/swicg/activitypub-webfinger/issues/33