As one may know, most Atmosphere accounts use the Public Ledger of Credentials (née Placeholder) Decentralised Identifier (did:plc) method. This is all well and good for basic usage, but the problem here is that you can't change what method your account is tied to. In effect, this means that, if Bluesky goes and dies or "becomes evil," your account is potentially unrecoverable in event of catastrophic failure, such as a PDS dying without any backups.
This is why, I find, supporting the did:web method alongside did:plc on the same identity to be a intriguing prospect. For example, let's take my DID document:
{
"@context": [
"https://www.w3.org/ns/did/v1",
"https://w3id.org/security/multikey/v1",
"https://w3id.org/security/suites/secp256k1-2019/v1"
],
"alsoKnownAs": [
"at://ewancroft.uk"
],
"id": "did:plc:ofrbh253gwicbkc5nktqepol",
"service": [
{
"id": "#atproto_pds",
"serviceEndpoint": "https://altq.net",
"type": "AtprotoPersonalDataServer"
}
],
"verificationMethod": [
{
"controller": "did:plc:ofrbh253gwicbkc5nktqepol",
"id": "did:plc:ofrbh253gwicbkc5nktqepol#atproto",
"publicKeyMultibase": "zQ3shiWqnLJj3G6493xztcy9wFGf1rpSarMKmEmiwUpG4mBzY",
"type": "Multikey"
}
]
}
The Safety Net Approach
Now, if we were to implement did:web alongside this existing did:plc setup, we'd essentially be creating a safety net whilst maintaining all the benefits of the current system. The beauty of did:web lies in its simplicity and independence. It's hosted on your own domain, which means you're not beholden to any particular organisation's infrastructure. Should Bluesky's PLC directory vanish tomorrow, your did:web would remain perfectly accessible so long as you control your domain.
Comparing the Two Methods
Consider the fundamental differences between these two approaches. The did:plc method, whilst convenient, creates a dependency on Bluesky's infrastructure. Yes, it's designed to be cryptographically verifiable and theoretically portable, but in practice, if their servers go down or their policies change dramatically, you're rather stuck. It's a bit like having all your eggs in one basket, albeit a very sophisticated cryptographic basket.
did:web, by contrast, is delightfully straightforward. Your DID document lives at https://yourdomain.com/.well-known/did.json, and that's that. No special infrastructure required beyond standard web hosting. The trade-off, naturally, is that you need to maintain your own domain and hosting, but for many users (particularly those who already run their own websites) this is hardly a burden.
Why Not Both?
What I'm proposing isn't an either-or situation, though. Rather than forcing users to choose between the convenience of did:plc and the independence of did:web, why not allow both to coexist for the same identity? The DID specification already supports multiple verification methods within a single document, so extending this concept to support multiple DID methods pointing to the same cryptographic identity seems entirely reasonable.
Imagine if my DID document could be resolved via both did:plc:ofrbh253gwicbkc5nktqepol and did:web:ewancroft.uk, with both methods returning equivalent documents that prove control over the same cryptographic keys. This would provide remarkable resilience. If Bluesky's infrastructure became unavailable, applications could seamlessly fall back to the did:web resolution. If my domain hosting went wonky, the did:plc method would still function perfectly.
Implementation Considerations
The implementation wouldn't be terribly complex either. The existing alsoKnownAs field in DID documents could be extended to include equivalent DID identifiers, creating a cryptographically verifiable link between the methods. Applications would simply need to understand that these different DIDs represent the same entity and should be treated as equivalent for verification purposes.
Of course, this does introduce the requirement that both DID documents remain synchronised. When you update your keys or service endpoints in one method, you'd need to ensure the other reflects the same changes. But I suspect this isn't terribly onerous in practice. Most users aren't constantly rotating their cryptographic keys or switching PDSs (like I am, eheh...), so synchronisation events would be relatively infrequent. For those who do need regular updates, it could be automated fairly straightforwardly with tooling that updates both the PLC directory and the did:web document simultaneously.
Handling Conflicts and Preferences
The synchronisation challenge I mentioned could certainly be mitigated through automated tooling, but there's an important question about how clients should handle conflicts when the two DID documents inevitably diverge. I'd suggest implementing a preference order system where did:plc takes priority for routine operations (given its integration with existing AT Protocol infrastructure), whilst did:web serves as the fallback when the primary method is unavailable. This approach maintains consistency during normal operation whilst providing the safety net functionality when it's most needed.
Alternatively, one could implement a simple timestamp-based resolution system where the most recently updated document takes precedence, though this introduces additional complexity around clock synchronisation and could lead to confusing behaviour if updates don't propagate properly.
User Experience Considerations
The user experience question is rather crucial here. Most users shouldn't need to think about these implementation details at all. The tooling would need to abstract away the complexity entirely for casual users, perhaps presenting it as simply as "Enable backup identity recovery" in the settings. For those users, the system would automatically maintain both DID methods behind the scenes.
However, more technical users should have full visibility and control over both methods. They might want to manually manage their did:web document, choose which services are advertised in each method, or temporarily disable one method whilst performing maintenance. The key is providing sensible defaults whilst preserving the flexibility that power users require.
Adoption Incentives and Platform Philosophy
The adoption question is perhaps the most politically interesting one. On the surface, supporting did:web might seem to reduce Bluesky's platform stickiness, but I'd argue it actually strengthens their position in the long term. By demonstrating genuine commitment to decentralisation principles, they differentiate themselves from platforms that merely pay lip service to user autonomy.
Moreover, users who feel confident that they're not locked into the platform are paradoxically more likely to invest deeply in it. It's the same principle that makes open-source software so compelling—knowing you can leave if necessary often means you're more comfortable staying. Bluesky's bet on the AT Protocol is fundamentally about creating a more robust and trustworthy social media ecosystem, and supporting multiple DID methods aligns perfectly with that vision.
From a practical standpoint, most users would likely continue using did:plc as their primary method anyway, given its seamless integration with the existing infrastructure. The did:web support would primarily benefit the subset of users who are already running their own domains and infrastructure—precisely the sort of technically-minded users who are most likely to contribute to the protocol's development and evangelise its benefits.
Accommodating Different User Needs
This approach acknowledges a rather important reality: different users have different risk tolerances and technical capabilities. Some users are perfectly content to rely on Bluesky's infrastructure and appreciate the seamless experience that did:plc provides. Others, particularly those running their own domains and infrastructure, might prefer the independence that did:web offers. Rather than forcing everyone into the same mould, supporting both methods allows users to choose their preferred balance between convenience and control, or indeed, to hedge their bets and use both.
Moving Forward
The AT Protocol's strength lies in its flexibility and decentralised design principles. Supporting multiple DID methods for the same identity would be a natural extension of this philosophy, providing users with genuine choice about how they manage their digital identities whilst maintaining interoperability across the network. It's not about replacing did:plc with did:web, but rather about giving users the tools to build more resilient and autonomous digital identities in an uncertain digital landscape.