@atcute/identity-resolver

中文文档
2.0.3发布于 2026/10/100BSDES Module近 30 天下载 35万

atproto handle and DID document resolution

原始使用文档
文档目录14 节
  1. usage
  2. resolving handles
  3. resolution strategies
  4. resolving DID documents
  5. resolving actors
  6. handling errors
  7. caching and abort signals
  8. custom fetch function
  9. server-side resolution and SSRF
  10. custom PLC directory
  11. resolver classes
  12. handle resolvers
  13. DID document resolvers
  14. actor resolvers

@atcute/identity-resolver

handle and DID document resolution for AT Protocol.

npm install @atcute/identity-resolver

in AT Protocol, handles (like alice.bsky.social) need to be resolved to DIDs, and DIDs need to be resolved to DID documents (which contain the user's PDS location and keys). this package provides resolvers for both.

usage

resolving handles

handles can be resolved via DNS TXT records or HTTP well-known endpoints. use the composite resolver to try both:

import {
    CompositeHandleResolver,
    DohJsonHandleResolver,
    WellKnownHandleResolver,
} from '@atcute/identity-resolver';

const handleResolver = new CompositeHandleResolver({
    methods: {
        dns: new DohJsonHandleResolver({ dohUrl: 'https://mozilla.cloudflare-dns.com/dns-query' }),
        http: new WellKnownHandleResolver(),
    },
});

const did = await handleResolver.resolve('bsky.app');
// -> "did:plc:z72i7hdynmk6r22z27h6tvur"

resolution strategies

the composite resolver supports different strategies for combining DNS and HTTP resolution:

const handleResolver = new CompositeHandleResolver({
    strategy: 'race', // default - first successful response wins
    methods: { dns: dnsResolver, http: httpResolver },
});

available strategies:

  • race - returns whichever method succeeds first (default)
  • dns-first - try DNS first, fall back to HTTP if it fails
  • http-first - try HTTP first, fall back to DNS if it fails
  • both - require both methods to agree (throws AmbiguousHandleError if they differ)

resolving DID documents

DID documents can be resolved for did:plc and did:web methods:

import {
    CompositeDidDocumentResolver,
    PlcDidDocumentResolver,
    WebDidDocumentResolver,
} from '@atcute/identity-resolver';

const didResolver = new CompositeDidDocumentResolver({
    methods: {
        plc: new PlcDidDocumentResolver(),
        web: new WebDidDocumentResolver(),
    },
});

const doc = await didResolver.resolve('did:plc:z72i7hdynmk6r22z27h6tvur');
// -> { '@context': [...], id: 'did:plc:...', service: [...], ... }

resolving actors

the ActorResolver interface provides a way to resolve an actor identifier (handle or DID) to the essential info needed to interact with them: their DID, verified handle, and PDS endpoint.

LocalActorResolver implements this by combining handle and DID document resolution locally:

import { LocalActorResolver } from '@atcute/identity-resolver';

const actorResolver = new LocalActorResolver({
    handleResolver,
    didDocumentResolver: didResolver,
});

// resolve from handle
const actor = await actorResolver.resolve('bsky.app');
// -> { did: "did:plc:...", handle: "bsky.app", pds: "https://..." }

// resolve from DID
const actor2 = await actorResolver.resolve('did:plc:z72i7hdynmk6r22z27h6tvur');
// -> { did: "did:plc:...", handle: "bsky.app", pds: "https://..." }

the local resolver performs bidirectional verification: it checks that the handle in the DID document resolves back to the same DID.

other implementations of ActorResolver can get this info from dedicated identity services (like Slingshot) without needing to fetch and parse full DID documents.

handling errors

each resolver throws specific error types for different failure cases:

import {
    DidNotFoundError,
    InvalidResolvedHandleError,
    AmbiguousHandleError,
    FailedHandleResolutionError,
    HandleResolutionError,
} from '@atcute/identity-resolver';

try {
    const did = await handleResolver.resolve('nonexistent.invalid');
} catch (err) {
    if (err instanceof DidNotFoundError) {
        // handle has no DID record
        console.log('handle not found');
    } else if (err instanceof InvalidResolvedHandleError) {
        // handle returned an invalid DID format
        console.log('invalid DID:', err.did);
    } else if (err instanceof AmbiguousHandleError) {
        // multiple different DIDs found (with 'both' strategy)
        console.log('ambiguous handle');
    } else if (err instanceof FailedHandleResolutionError) {
        // network or other unexpected error
        console.log('resolution failed:', err.cause);
    } else if (err instanceof HandleResolutionError) {
        // catch-all for any handle resolution error
    }
}

DID document resolution errors:

import {
    DocumentNotFoundError,
    UnsupportedDidMethodError,
    ImproperDidError,
    FailedDocumentResolutionError,
    DidDocumentResolutionError,
} from '@atcute/identity-resolver';

try {
    const doc = await didResolver.resolve('did:example:123');
} catch (err) {
    if (err instanceof DocumentNotFoundError) {
        // DID document doesn't exist
    } else if (err instanceof UnsupportedDidMethodError) {
        // resolver doesn't support this DID method
    } else if (err instanceof ImproperDidError) {
        // DID format is invalid for this method
    } else if (err instanceof FailedDocumentResolutionError) {
        // network or other unexpected error
    } else if (err instanceof DidDocumentResolutionError) {
        // catch-all for any DID resolution error
    }
}

caching and abort signals

all resolvers accept options for cache control and cancellation:

// skip cache
const did = await handleResolver.resolve('bsky.app', { noCache: true });

// with abort signal
const controller = new AbortController();
const did = await handleResolver.resolve('bsky.app', { signal: controller.signal });

// cancel the request
controller.abort();

custom fetch function

all resolvers accept a custom fetch implementation:

const dnsResolver = new DohJsonHandleResolver({
    dohUrl: 'https://mozilla.cloudflare-dns.com/dns-query',
    fetch: customFetch,
});

const httpResolver = new WellKnownHandleResolver({
    fetch: customFetch,
});

const plcResolver = new PlcDidDocumentResolver({
    fetch: customFetch,
});

server-side resolution and SSRF

resolving untrusted identities on a server can expose internal services to server-side request forgery (SSRF). for example, did:web:localhost%3a6379 targets a loopback address over HTTP, and did:web:169.254.169.254 targets a link-local address.

the resolvers do not restrict destination IPs. pass a custom fetch that rejects non-public addresses at connection time. checking the hostname alone is insufficient: DNS can resolve a public hostname to a private IP.

const didResolver = new CompositeDidDocumentResolver({
    methods: {
        plc: new PlcDidDocumentResolver({ fetch: safeFetch }),
        web: new WebDidDocumentResolver({ fetch: safeFetch }),
    },
});

on Cloudflare Workers, enable global_fetch_strictly_public in the Wrangler configuration. on Node.js, use a fetch dispatcher that checks destination IPs at connection time.

custom PLC directory

by default, did:plc resolution uses https://plc.directory. you can specify a different directory:

const plcResolver = new PlcDidDocumentResolver({
    apiUrl: 'https://plc.wtf', // mirror of plc.directory
});

resolver classes

handle resolvers

classdescription
DohJsonHandleResolverresolves via DNS-over-HTTPS (TXT record at _atproto.{handle})
WellKnownHandleResolverresolves via HTTP (https://{handle}/.well-known/atproto-did)
XrpcHandleResolverresolves via XRPC (com.atproto.identity.resolveHandle)
CompositeHandleResolvercombines DNS and HTTP resolvers

DID document resolvers

classdescription
PlcDidDocumentResolverresolves did:plc from PLC directory
WebDidDocumentResolverresolves did:web from domain
XrpcDidDocumentResolverresolves via XRPC (com.atproto.identity.resolveDid)
CompositeDidDocumentResolverroutes to resolver by DID method

actor resolvers

classdescription
LocalActorResolvercombines handle and DID resolution with bidirectional verification

版本与发布记录

@atcute/identity-resolver 共发布 19 个版本,首次发布于 2025/03/13;过去 12 个月发布了 8 个版本。

版本发布日期距今
2.0.3latest2026/10/1028 天前
2.0.22026/09/121 个月前
2.0.12026/06/294 个月前
2.0.02026/05/095 个月前
1.2.32026/05/086 个月前
1.2.22026/01/0310 个月前

关于 @atcute/identity-resolver 的常见问题

@atcute/identity-resolver 是什么?

atproto handle and DID document resolution

如何安装 @atcute/identity-resolver?

在项目目录运行 npm install @atcute/identity-resolver,或使用 pnpm add / yarn add / bun add。它还需要宿主项目提供 peer 依赖:@atcute/identity(^2.0.0)、@atcute/lexicons(^2.0.0)。npm 7 及以上与 pnpm 8 及以上默认会自动安装必需的 peer 依赖,Yarn 需要手动安装。

@atcute/identity-resolver 支持 TypeScript 吗?

该包的 package.json 没有声明类型入口。需要类型提示时,可以在 npm 上查找社区维护的 @types/atcute__identity-resolver 是否存在。

@atcute/identity-resolver 支持 ESM 还是 CommonJS?

以 ES Module 形式发布,推荐使用 import 引入。在 CommonJS 项目中,Node.js 20.19+ / 22.12+ 可以直接 require() 不含顶层 await 的 ES Module,更早的版本需要改用动态 import()。

@atcute/identity-resolver 可以商用吗?

@atcute/identity-resolver 使用 0BSD 许可。几乎没有限制:可自由使用、修改和分发,连保留版权声明也不要求。以上为概括,不构成法律意见,请以许可原文为准。

@atcute/identity-resolver 的下载量有多少?

根据 npm 官方下载统计,@atcute/identity-resolver 在 2026/10/07 – 2026/11/05 这 30 天内被下载 349,902 次,日均约 11,663 次。下载量会把 CI 构建、镜像同步和作为其他包依赖的安装一并计入,适合横向比较热度,不能直接等同于使用人数。

@atcute/identity-resolver 还在维护吗?

最新版本 2.0.3 发布于 2026/10/10(28 天前);至今共发布 19 个版本,其中过去 12 个月发布了 8 个;首次发布于 2025/03/13。发布频率只是参考信号:功能稳定的工具可能很少需要更新,建议结合源码仓库的 issue 和提交记录判断。