3 ms·

Is it possible to implement a functional subset of just serving one’s own DID identities using serverless functions? Then that would enable every average Joe to

by xeonmc 2y ago

Is it possible to implement a functional subset of just serving one’s own DID identities using serverless functions? Then that would enable every average Joe to make their own with Cloudflare Pages Workers

verdverm 2y ago
You shouldn't need that much for a single DID. If you want to serve an org DID, like a bunch of users under the same domain, you need to do something like this. https://atproto.com/guides/identity https://atproto.com/guides/identity
- xeonmc 2y ago
  where are you supposed to put the DID document on your domain? All documentation describes putting the .well-known/atproto-did file but not the actual DID document.
  - verdverm 2y ago
    From https://atproto.com/specs/handle https://atproto.com/specs/handle section "HTTPS well-known Method" It is unclear where the handle query goes However, you don't need a document per day. It can be dynamically generated by a handler or server less function on that route. This is important as employees at an org change, this information could be obtained from a database You can for example: `curl https://verdverm.bsky.social/.well-known/atproto-did https://verdverm.bsky.social/.well-known/atproto-did` So for an organization, one might have a single handler responding to `*.atproto.company.com/.well-known/atproto-did` with the subdomain becoming the primary input variable
    - xeonmc 2y ago
      no, like I said I already know that .well-known/atproto-did returns the DID value, but there doesn't seem to be any documentation for where the inquirer will next expect to fetch the actual DID document to complete the circular verification.
      - verdverm 2y ago
        This peer-thread might offer us some clues: https://news.ycombinator.com/item?id=42750241 https://news.ycombinator.com/item?id=42750241 `curl -s "https://plc.directory/$(curl https://plc.directory/$(curl -s https://verdverm.bsky.social/.well-known/atproto-did https://verdverm.bsky.social/.well-known/atproto-did)" | jq .`

by xeonmc 2y ago

verdverm 2y ago

You shouldn't need that much for a single DID. If you want to serve an org DID, like a bunch of users under the same domain, you need to do something like this. https://atproto.com/guides/identity https://atproto.com/guides/identity

xeonmc 2y ago
where are you supposed to put the DID document on your domain? All documentation describes putting the .well-known/atproto-did file but not the actual DID document.
- verdverm 2y ago
  From https://atproto.com/specs/handle https://atproto.com/specs/handle section "HTTPS well-known Method" It is unclear where the handle query goes However, you don't need a document per day. It can be dynamically generated by a handler or server less function on that route. This is important as employees at an org change, this information could be obtained from a database You can for example: `curl https://verdverm.bsky.social/.well-known/atproto-did https://verdverm.bsky.social/.well-known/atproto-did` So for an organization, one might have a single handler responding to `*.atproto.company.com/.well-known/atproto-did` with the subdomain becoming the primary input variable
  - xeonmc 2y ago
    no, like I said I already know that .well-known/atproto-did returns the DID value, but there doesn't seem to be any documentation for where the inquirer will next expect to fetch the actual DID document to complete the circular verification.
    - verdverm 2y ago
      This peer-thread might offer us some clues: https://news.ycombinator.com/item?id=42750241 https://news.ycombinator.com/item?id=42750241 `curl -s "https://plc.directory/$(curl https://plc.directory/$(curl -s https://verdverm.bsky.social/.well-known/atproto-did https://verdverm.bsky.social/.well-known/atproto-did)" | jq .`