AB Adrián Barrera

Project Post · AT Protocol

Bluesky Handles and Identity Automation

A practical exploration of decentralized identity in Bluesky: DNS verification, community domains, branded profile redirects, and the serverless architecture behind them.

Context

Bluesky handles are one of the most useful parts of the AT Protocol identity model. A domain can become a user handle, and the domain owner can prove ownership by publishing a DNS TXT record that points to the user's DID.

That model is powerful, but managing verification manually becomes repetitive when a community domain supports many users. This project explores how small serverless components can make that workflow easier to operate.

The work includes two related systems: automated DNS TXT updates for handle verification, and branded subdomain redirects that point people to the matching Bluesky profile.

Project Focus

  • Identity automation: Reduce manual DNS work for AT Protocol handle verification.
  • Community domains: Support handles under domains such as bsky.ar and profile redirects under bsky.uy.
  • Serverless design: Use AWS Lambda, API Gateway and Route 53 instead of a dedicated backend server.
  • Operational safety: Keep permissions narrow, validate inputs, and use CloudWatch for logs and debugging.
  • User experience: Make Bluesky identities easier to share through short, branded links.

DNS Update Architecture

The DNS update workflow is intentionally small. API Gateway receives the request, Lambda validates and processes it, and Route 53 stores the TXT record required by the AT Protocol identity flow.

The endpoint receives JSON input with a subdomain and DID, then creates a TXT record such as _atproto.example.bsky.ar. This allows a Bluesky user under the community domain to complete handle verification without manual DNS edits.

{
  "subdomain": "example",
  "did": "did:example:123456789abcdef"
}
Bluesky DNS update workflow API Gateway sends a DNS verification request to Lambda. Lambda writes the corresponding TXT record to Route 53. Bluesky DNS Update Workflow DNS Update Workflow API Gateway POST /update-dns AWS Lambda DNS TXT Update Route 53

Redirecting Subdomains to Profiles

The second system focuses on user-facing identity links. Instead of sharing a long Bluesky profile URL, a branded subdomain can redirect directly to the matching profile.

For example, adrian.bsky.uy redirects to https://bsky.app/profile/adrian.bsky.uy. The same pattern can work for any supported subdomain.

This creates a more memorable identity layer while keeping Bluesky as the destination profile system.

Simplified redirect logic

function handler(event) {
  const host = event.request.headers.host.value;
  const subdomain = host.split('.')[0];

  if (subdomain !== 'www') {
    return {
      statusCode: 302,
      headers: {
        location: { value: `https://bsky.app/profile/${subdomain}.bsky.uy` }
      }
    };
  }

  return event.request;
}

Redirect Architecture

The redirect workflow keeps request handling lightweight. A browser requests the branded subdomain, the edge/serverless function derives the target handle, and the user is redirected to the corresponding Bluesky profile.

Bluesky profile redirect workflow A browser request goes to a redirect function, which sends the user to the matching Bluesky profile. Bluesky Redirect Workflow Redirect Workflow Browser Redirect Function Build profile URL Bluesky Profile Page

Takeaways

These projects highlight the developer-first nature of Bluesky and the AT Protocol. With a small set of AWS primitives, it is possible to automate handle verification, support community domains and provide branded, human-readable identity links.

From an architecture perspective, the main lesson is that decentralized identity still benefits from simple operational tooling. Automation reduces manual work, lowers error rates and makes community infrastructure easier to maintain.

Links

Community domains

← Back to home