Bluesky: change fediverse handle format?

[snarfed]

I'm considering changing our Bluesky handle format.

Right now, we use subdomain labels liberally to convert fediverse addresses like @[email protected] to Bluesky handles like user.example.com.ap.brid.gy. This works, and it's simple, but it has drawbacks. We've been struggling to plan for how to scale handle verification, #744.

If I switch to the - character for the fediverse address part, eg user-example-com.ap.brid.gy, the resulting handles are more complicated, but I can switch to Bluesky's HTTPS handle verification method, and I'd only need a single wildcard DNS record and a single wildcard SSL cert.

I'm inclined to do it.

[andrewtj]

Just in case it's not on your radar, DNS names do have a 63-byte label length limit. (Label being the bit between dots.)

I'd guess it's unlikely that this would be a problem in practice but I don't have anything really substantive to support that feeling.

[snarfed]

Thanks, yes! 63 chars per label, 253 chars total.

I also need to look at allowed characters. For DNS it's just alphanumeric and -, right? WebFinger usernames may allow a few more, eg .s, which users would also need to translate to -s.

[snarfed]

Based on https://datatracker.ietf.org/doc/html/rfc7565#section-7 and https://datatracker.ietf.org/doc/html/rfc3986#section-2.3 , WebFinger usernames also allow _ and ~.

[jfietkau]

Also notably, as I understand the RFCs, WebFinger usernames are case sensitive while hostnames are not. In theory, an ActivityPub server using WebFinger may have two or more distinct user accounts whose account names differ only by capitalization.

I don't think this has happened in practice and it would probably cause untold havoc with interoperability if it were tried, but I figured I'd let you know if you're aiming for full spec compliance.

[andrewtj]

I also need to look at allowed characters. For DNS it's just alphanumeric and -, right?

Kinda. DNS labels are arbitrary bytes but case insensitive to a-z. Hostname labels are alphanumeric and dash (for the most part). To enable internationalisation IDNA (RFC 5890 and RFC 5891) then represents a normalised subset of unicode in a hostname label compatible format. If that's something you want to handle dnspython has some helpers for marshalling names to and from IDNA.

[WisTex]

Some platforms support - and _ in their handles. Even domains can have a - in it.

You would need to account for this when you create the Bluesky version of the handle.

[snarfed]

Yup, absolutely true. Ugh.

I'm sure I/we can come up with an encoding that can turn every fediverse handle into a single DNS compliant label, and it might still be worth it to avoid the DNS zone scaling issue...but UX-wise, it's getting uglier and uglier. Sigh.

Damn you, @zooko and your Triangle. (Kidding! Been a while, hope you're good!)

[WisTex]

Would making it two levels help? (i.e. separating username and server)

username.social-example-com.ap.brid.gy for [email protected]

That would reduce the number of zones, although that may not matter depending on how you implemented creating the zones.

[snarfed]

Yeah I've considered various multi-level formats like that. The DNS scaling concern (more in #744) is mainly the number of records, regardless of how they're organized into zones.

The win of going fully flat under ap.brid.gy, as is proposed here, is that we can drop DNS entirely and use ATProto's HTTPS-based handle resolution method instead. That scales better in number of accounts, but SSL certs only support a single level of wildcards, ie *.ap.brid.gy but not *.*.ap.brid.gy, so the namespace would need to be flat. 🤷

[zooko]

Hi Ryan, nice to hear from you! :-)

…

On Thu, Feb 22, 2024 at 11:06 AM Ryan Barrett ***@***.***> wrote: Yeah I've considered various multi-level formats like that. The DNS scaling concern (more in #744 <#744>) is mainly the number of records, regardless of how they're organized into zones. The win of going fully flat under ap.brid.gy, as is proposed here, is that we can drop DNS entirely and use ATProto's HTTPS-based handle resolution method <https://atproto.com/specs/handle#https-well-known-method> instead. That scales better in number of accounts, but SSL certs only support a single level of wildcards, ie *.ap.brid.gy but not *.*.ap.brid.gy, so the namespace would need to be flat. 🤷 — Reply to this email directly, view it on GitHub <#830 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADSHPCHZIFCLJD6H6PPLTTYU6CJ5AVCNFSM6AAAAABDEDH4OOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJZHE4TAOBYG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[WisTex]

And with the number of subdomains, AutoSSL for each one will become a pain.

The tricky part will be handling domains and usernames with - in it.

[snarfed]

Given that this is only a win if it's entirely flat (#830 (comment)), and that means we'd need to come up with a more complicated encoding to handle -, _, ~, and similar characters, which would significantly hurt UX, I'm now less inclined to do this. Sigh.

[snarfed]

Decided against this, sadly.