The AT Protocol URI Syntax Issue: Non-Compliance with RFC-3986 Sparks Debate and Search for Solutions
The AT Protocol's AT URI has surfaced as non-compliant with RFC-3986, posing challenges for IETF standardization and sparking heated debates among developers.
The AT URI scheme, a core component of the decentralized social networking protocol known as the AT Protocol, has come under scrutiny for not complying with the internet standard RFC-3986. Bryan Newbold, a protocol designer at Bluesky, detailed the issue in a blog post, sending shockwaves through the community. The non-compliance poses hurdles not only for standardization with the Internet Engineering Task Force (IETF) but also for compatibility with existing URI parsers, such as those used in HTML <link> tags.
The Crux of the Problem
The AT URI takes a format similar to at://did:plc:vwzwgnygau7ed7b7wt5ux7y2/app.bsky.feed.post/3k5nobkf2w72g. In this scheme, a Decentralized Identifier (DID) such as did:plc:... is placed in the “authority” component immediately following the scheme. However, this design conflicts with the hierarchical structure of host-and-port as defined by RFC-3986.
According to section 1.2.3 of RFC-3986, some URI schemes are allowed to limit their visible hierarchy to the scheme itself, treating the portion after the scheme delimiter as “opaque.” Based on this provision, Newbold initially determined in 2022 that the AT URI complied with RFC-3986. However, stricter interpretations have since revealed that using a DID in the authority section is not allowed.
Why Has This Issue Surfaced Now?
Although this was first flagged in a GitHub issue back in 2025, two recent developments have brought the problem to the forefront. First, there has been an increase in cases where AT URIs are used in contexts like HTML <link> tags, which expect properly formatted URIs or URLs. Second, the AT Protocol Working Group has set a goal of permanent registration of the AT URI scheme with the IETF, where this non-compliance has emerged as a barrier in the standardization process.
The Gap Between Design Philosophy and Reality
Newbold has described the AT URI as one of the most important and outstanding features of the protocol. The design places an individual account identifier, rather than a provider’s hostname, in the authority section, embodying the AT Protocol’s core principle that accounts should have ultimate authority over their content and should be able to move seamlessly between providers. Newbold argues that this principle should not be compromised.
However, within the IETF framework, which prioritizes standardization and interoperability, this innovative design is being pressured to conform.
Scope of the Impact
The ramifications of this issue are far-reaching. Many existing URI parser libraries are unable to correctly process AT URIs. Under the URL specifications of the Web Hypertext Application Technology Working Group (WHATWG), AT URIs are not recognized as valid web URLs. Additionally, AT URIs cannot be used in <link> or <a> tags, hampering their ability to be shared outside the Bluesky ecosystem. Permanent registration with the IETF essentially requires compliance with RFC-3986, making standardization unlikely under the current design.
Potential Solutions
Newbold has proposed several forward-compatible solutions, though none are without drawbacks. The options under discussion include:
-
Modifying the syntax of the authority section to escape the DID specifically. While this would allow existing URI parsers to process AT URIs, it would break compatibility with existing AT URIs.
-
Expanding the semantics of the URI scheme to create a new RFC that permits DIDs in the authority section. However, this approach would require extensive consensus-building within the IETF, a time-consuming process.
-
Replacing AT URI with an entirely new URI scheme, such as
atdid:. While this would be the most disruptive option, it could also provide the cleanest long-term solution.
Newbold has cautioned that any of these paths would entail some level of pain and confusion for developers within the ecosystem. For now, discussions are ongoing within Bluesky and its community to reach a consensus.
Editorial Opinion
In the short term, the non-compliance issue with AT URIs could slow down the adoption of the AT Protocol. While this problem may not be immediately apparent to users of Bluesky as a social networking platform, third-party developers attempting to build applications may encounter parsing errors, negatively impacting their development experience. If standardization at the IETF is delayed, efforts to achieve interoperability with other decentralized protocols, such as ActivityPub, could also suffer.
In the long term, this issue raises a fundamental question about how much decentralized protocol design should prioritize alignment with internet standards. While the AT Protocol’s innovative principle of “account as authority” is groundbreaking, a compromise to align with existing standards may be necessary. If this challenge is successfully overcome, the AT URI could set a precedent for integrating decentralized identifiers into URIs, shaping the future of protocol design. As a publication, we will closely monitor how the IETF Working Group navigates this challenge and what compromises are proposed.
References
- The AT-URI Syntax Mess — Published June 29, 2026
Frequently Asked Questions
- What is an AT URI?
- AT URI is a URI scheme used in the AT Protocol, a decentralized social networking protocol developed by Bluesky. It begins with `at://` and places a Decentralized Identifier (DID) in the authority section. It is used to uniquely identify individual posts or records.
- What are the practical issues of non-compliance with RFC-3986?
- AT URIs cannot be directly embedded in HTML `<link>` or `<a>` tags, cannot be properly parsed by existing URI parser libraries, and cannot be permanently registered with the IETF, creating significant obstacles for interoperability and standardization.
- What are the potential solutions to this problem?
- Discussions are ongoing within Bluesky and its community. Options include altering the syntax of the authority section, extending URI parser semantics via a new RFC, or replacing the AT URI with an entirely new scheme. Each solution would involve some degree of disruption to existing AT URIs.
Comments