Support did:web #311
Support did:web #311
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
3 Skipped Deployments
|
There was a problem hiding this comment.
Pull request overview
This PR adds support for did:web identifiers alongside the existing did:plc support, enabling the application to resolve decentralized identifiers from web-based sources in addition to the PLC directory.
Key changes:
- Updated the DID type definition to accept both
did:plcanddid:webformats - Replaced single
PlcDidDocumentResolverwithCompositeDidDocumentResolverthat handles both DID methods - Integrated
isAtprotoDidfrom@atcute/identityfor standardized DID validation
|
Instead of accepting the potential concerns of did:web, maybe we just continue to prevent did:webs from logging in or creating records? But still keep the did:web implementation there for eg. feedgen servers. |
|
|
||
| type Brand<K, T> = K & { __brand: T }; | ||
| export type DID = Brand<`did:plc:${string}`, "DID">; | ||
| export type DID = Brand<`did:${"plc" | "web"}:${string}`, "DID">; |
There was a problem hiding this comment.
Now that we have the template literal type the brand has less value, but it's still nice to have because it's much easier to trace where exactly DID values are being created. Compared to just the template literal where any line of code can just do
`did:web:example.com` as constAnd that is now a value assignable to something that accepts a DID.
|
I don't think we should support did:webs for user accounts but will need to be able to handle them for service accounts like feedgens. I can't find a nice way to support separate functions to support both. Separate types (eg. |
|
Gonna sleep on that. |
Closes #241
There are potential edge cases to consider around account deletion eg. what if someone takes hold of the domain, they have then taken over the account. I'm just choosing to ignore this for now, we can cross that bridge when we come to it.