-
Notifications
You must be signed in to change notification settings - Fork 554
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move handle resolution to .well-known #1048
Conversation
It feels to me like this is generic to DIDs in general, not just atproto, and we could represent that in the path name. Eg, Is it a requirement that the handle in the hostname match the handle in the path? |
I actually really like the sub-directory thing, makes it quite easy to do virtual hosting with a bunch of domains and DIDs using something like nginx |
While it is generic to dids, I think it's useful for different ecosystems to be able to differentiate the dids/handles associated with each. For instance, with the DNS records we do
I don't have a super strong opinion on this. But I do think it's reasonable to be able to ask an authority what a subdomain resolves to. ie: asking Though canonically, you're encouraged to ask the hostname that matches the handle |
I was trying to match our DNS semantics with the pathing here. maybe |
@@ -48,12 +48,12 @@ describe('handle resolution', () => { | |||
}) | |||
|
|||
it('handles a bad DNS resolution', async () => { | |||
await expect(resolveDns('bad.test')).rejects.toThrow(NoHandleRecordError) | |||
const did = resolveDns('bad.test') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should this be an await statement? it's failing tests
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yup 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
line 51 in the resolve test needs an await statement
take a look at https://github.com/protocol-registries/well-known-uris, it's not required obviously but does add some security to the path |
Yeah I think we'll need to wait until we have an actual spec before we can register there |
is the spec documented and will the lexicon work with the site? |
packages/identifier/src/resolve.ts
Outdated
const dnsRes = await dnsPromise | ||
if (dnsRes) { | ||
httpAbort.abort() | ||
return dnsRes | ||
} | ||
return httpPromise |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep I'm good with this
@@ -7,6 +7,7 @@ | |||
"description": "Provides the DID of a repo.", | |||
"parameters": { | |||
"type": "params", | |||
"required": ["handle"], | |||
"properties": { | |||
"handle": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should probs drop the "if not specified" bit of the description (at least it was still in the comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep I'm good with this
COPY ./packages/did-resolver ./packages/did-resolver | ||
COPY ./packages/identifier ./packages/identifier | ||
COPY ./packages/identity ./packages/identity |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for remembering this 👍
|
||
const url = `${pds.url}/.well-known/atproto-did` | ||
try { | ||
const res = await fetch(url, { headers: { host: handle } }) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💎
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good stuff!
Co-authored-by: devin ivy <devinivy@gmail.com>
For some reason I was expecting
To match the DNS form as closely as possible 🤷♂️ |
const data = await res.json() | ||
return data.did |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is going away soon so I don't think it's a biggie, but we might want to ensure that the result here is a string (if not a valid did).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah that's a good point 👍
* move handle resolution to .well-known * required handle on resolveHandle * rm test * tidy * tidy * fix up appview * missing await * atproto-handle -> atproto-did * shift did & handle resolution to new identity package * fix up network mocks * fix up another test * one more * drop lex comment * rm handle param * Update packages/identity/src/handle/index.ts Co-authored-by: devin ivy <devinivy@gmail.com> * still temporarily support xrpc handle resolution * typo * ensure return value is a string --------- Co-authored-by: devin ivy <devinivy@gmail.com>
Curious, how are you configuring your domains to support wildcard subdomains (ex. |
* move handle resolution to .well-known * required handle on resolveHandle * rm test * tidy * tidy * fix up appview * missing await * atproto-handle -> atproto-did * shift did & handle resolution to new identity package * fix up network mocks * fix up another test * one more * drop lex comment * rm handle param * Update packages/identity/src/handle/index.ts Co-authored-by: devin ivy <devinivy@gmail.com> * still temporarily support xrpc handle resolution * typo * ensure return value is a string --------- Co-authored-by: devin ivy <devinivy@gmail.com>
This moves handle resolution to
.well-known
Specifically, a handle is resolved by calling
GET http(s)://${handle}/.well-known/atproto-did
The expected response is
text/plain
and simply contains the associated DIDCloses #969