A Bio Page With No Backend

Most "link in bio" tools (Linktree, Beacons, etc.) are centralized SaaS products: you sign up, they host your links, and they can suspend, rate-limit, or monetize your page however they like. HNS.BIO, an open-source project by developer H4ckB4s3, replaces the entire stack with a single DNS identity mechanism already available to every Handshake domain owner: the TXT record.

The idea is simple. You add a TXT record to your HNS TLD or SLD in the format <prefix>:<value>, and the hns.bio resolver reads it, interprets the prefix, and renders a bio page at yourname.hns.bio. There's no account to create and nothing to host — the page is generated live from whatever is published on-chain.

The Prefix System

What makes this a genuinely useful teaching example is how far a plain-text convention can be pushed. HNS.BIO defines dozens of prefixes across six categories:

  • Layout — pfp: for a profile picture, bgcolor: and bg: for styling
  • Communication — mail:, tel:, tg: (Telegram), wa: (WhatsApp), sn: (Signal), matrix:
  • Web — link: for any URL, ens: for an Ethereum Name Service handle, onion: for a Tor address, ipfs: for content-addressed storage
  • Social — x:, gh:, bsky:, ig:, nostr:
  • Wallet — btc:, hns:, eth:, xmr:, and roughly thirty more chains, all as one flat namespace
  • Chaining — ext:, which fetches TXT records from a different TLD or SLD entirely, letting one identity reference another

That last one is worth sitting with. An ext: record means a Handshake identity isn't confined to a single name — it can point outward and compose with other domains, other chains, other identity systems. It's a small feature, but it's a real demonstration of what programmable naming infrastructure means in practice, not just in pitch decks.

Why This Matters Beyond One Repo

HNS.BIO isn't trying to be a product roadmap — it's a proof of concept, unlicensed and free to fork. But it does something LearnHNS keeps coming back to: it shows a TXT record functioning as a structured data field rather than a static string. The same pattern shows up in DANE/TLSA records anchoring TLS certificates to a domain, and in how DNMT and ROSSOBAY bind media and real-world assets to Handshake names. HNS.BIO applies it to something almost anyone can understand at a glance — a bio page — which makes it a good on-ramp for explaining the bigger idea to people who've never touched a TLD manager.

It also quietly bridges ecosystems. The resolver reads Handshake TLDs, HNS SLDs, ENS domains, and ICANN SLDs through the identical prefix convention. Your identity page doesn't care whether the name underneath it is HNS or ENS — it just reads the TXT record. That's a useful data point in any conversation about whether decentralized naming systems compete with each other or interoperate.

Trying It Yourself

Setup is three steps: add a TXT record at your domain manager (Shakestation, Namebase, or similar) with Name: @ and Value: prefix:value, then visit https://yourdomain.hns.bio. You can also browse published SLDs at hns.bio directly.

For resolving Handshake names reliably while you experiment with projects like this, we recommend SkyInclude Browser — it handles HNS resolution natively without extra configuration. If you want your identity page's TLS trust anchored the same way its records are — on-chain instead of via a centralized CA — pair it with DANE HNS Browser, which validates certificates against DANE/TLSA records published under your Handshake name rather than trusting a third-party certificate authority.

NIHON — Handshake Infrastructure & Web3 Identity.