While building it I looked at my own PGP setup and felt like a hypocrite.
My public key lived on keys.openpgp.org. A keyserver I don’t run, don’t control, and can’t guarantee will exist tomorrow. Anyone wanting to verify my signatures had to trust a third party to serve them the right key. That’s not self-sovereign. That’s just outsourcing the problem.
Web Key Directory (WKD) fixes this. It’s a simple protocol that lets email clients and other tools fetch your public key directly from your domain. No keyserver. No third party. Just an HTTP request to a path you control, answered by a file you put there.
Here’s how it works and how to set it up.
The spec is simple. When someone wants your key for you@yourdomain.com, their client:
you) using a specific Z-Base-32 encodinghttps://openpgpkey.yourdomain.com/.well-known/openpgpkey/yourdomain.com/hu/{hash}https://yourdomain.com/.well-known/openpgpkey/hu/{hash}The advanced method is preferred. It uses a dedicated subdomain, which is cleaner and sidesteps potential conflicts with existing web server config. The direct method is the fallback. Implement both.
The file at that path is just your exported public key, in binary (not ASCII-armored).
That’s it. The protocol is not complicated. The implementation is mostly NGINX config and a gpg --export command.
GnuPG can compute the WKD hash for you:
gpg --with-wkd-hash --fingerprint you@yourdomain.com
Look for the line that says uid. The hash appears in brackets after your email address, something like dizb37aqa5h4skgu7jf1xjr4q71w4paq. That’s the filename you need.
Export in binary with the minimal flag. Stripping third-party certifications avoids a false-positive revocation warning that some WKD checkers will flag:
gpg --export --export-options export-minimal you@yourdomain.com > {hash}
No --armor. Binary only. The file has no extension.
On your server, create the following. I’m using /var/www/yourdomain.com as the web root but adjust for your setup:
/var/www/yourdomain.com/.well-known/openpgpkey/
policy ← empty file, required by spec
hu/{hash} ← direct method key file
/var/www/yourdomain.com/.well-known/openpgpkey/yourdomain.com/
policy ← empty file
hu/{hash} ← advanced method key file
The policy files are empty. Their presence is required by the spec even though they carry no content.
Copy your exported key file to both hu/ directories.
For the advanced method, you need an A record pointing openpgpkey.yourdomain.com at your server. Add that wherever you manage DNS.
Two pieces. First, add a location block to your existing yourdomain.com server block for the direct method:
location /.well-known/openpgpkey/ {
root /var/www/yourdomain.com;
default_type application/octet-stream;
add_header Access-Control-Allow-Origin "*";
try_files $uri $uri/ =404;
}
Put this before any catch-all redirect rules or you’ll redirect the WKD requests away.
Second, create a new server block for the openpgpkey subdomain:
server {
listen 443 ssl;
server_name openpgpkey.yourdomain.com;
ssl_certificate /etc/letsencrypt/live/openpgpkey.yourdomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/openpgpkey.yourdomain.com/privkey.pem;
root /var/www/yourdomain.com;
location /.well-known/openpgpkey/ {
default_type application/octet-stream;
add_header Access-Control-Allow-Origin "*";
try_files $uri $uri/ =404;
}
}
WKD requires HTTPS. Get a cert for the subdomain:
certbot --nginx -d openpgpkey.yourdomain.com
Test your NGINX config before reloading:
nginx -t && systemctl reload nginx
wkd.dp42.dev will check both methods and tell you exactly what’s passing and what isn’t. You want green on both advanced and direct. If you get a false revocation warning, double-check that you used --export-options export-minimal on your key export.
Keyservers are not the enemy. keys.openpgp.org is a good service run by good people. But it’s still someone else’s server, someone else’s uptime, someone else’s decision about what to serve.
When you set up WKD, key discovery for your address becomes a function of your domain. If you control your domain, you control your key. Your personal site is yours, not a profile on someone else’s platform. Your key should be yours too, not a record in someone else’s database.
This is a small piece of a larger thing I’ve been thinking about: what does genuinely self-sovereign identity look like? Not a product someone sells you. Not a profile you rent. Cryptographic identity anchored to infrastructure you own, verifiable by anyone, dependent on no one.
Signet is one piece of that. It’s a mutual attestation between a PGP key and an Ethereum address, each signing a commitment to the other. Scry lets you explore the resulting identity graph. WKD is a quieter piece: just making sure that when someone looks for your key, they find it from you.
That’s worth spending a little extra time in your NGINX configs.
Have questions or ran into something weird with your setup? Find me at bendoubleu.eth or via my Scry Profile.
The honest answer is that I didn’t need to do this. A VPS running nginx works fine for a personal blog. Nobody’s trying to take down my posts about amateur radio and Solidity contracts. But there’s something philosophically satisfying about publishing to infrastructure that doesn’t require permission. My content exists because the math says it does, not because I’m paying someone to keep a server running. The same post you’re reading at benwoodall.com is also available at benwoodall.eth.limo—two completely different infrastructures, same content, same hash. That’s the magic of content addressing. The data is the address.
When I’m ready to publish, I run a deploy script. Here’s what happens:
┌──────────┐ ┌────────┐ ┌───────────────┐
│ Jekyll │───▶│ Pinata │───▶│ VPS (nginx) │
│ build │ │ pin │ │ IPFS node │
└──────────┘ └────────┘ └───────────────┘
│ │
▼ ▼
┌──────────┐ ┌─────────────┐
│ IPFS │ │ benwoodall │
│ network │ │ .com │
└──────────┘ └─────────────┘
│
▼
┌──────────┐
│ ENS │──▶ benwoodall.eth.limo
└──────────┘
Jekyll builds static HTML, which gets uploaded to Pinata. Pinata returns a CID—a cryptographic fingerprint of everything in that folder. Same content always produces the same CID. Change a single character and you get an entirely different hash. That CID then gets pinned to my own IPFS node on a VPS for redundancy, and nginx gets updated to proxy requests to it. When you visit benwoodall.com, nginx fetches from the local IPFS node and serves it like any normal website. You’d never know the difference unless you looked under the hood.
Here’s something I learned the hard way: deploying to IPFS is immutable, but your nginx config isn’t. If something goes wrong mid-deploy, you can end up with your domain pointing at a broken CID. So the script captures the current working CID before doing anything else. If any step fails, it rolls back automatically. The broken content still exists on IPFS—that’s the immutability—but nobody sees it because the domain points elsewhere. One of those “obvious in retrospect” things.
IPFS has a reputation for being slow, and it can be. The solution is boring but effective: run your own node, proxy through nginx. Adding a swarm connect to Pinata’s node right after upload—basically saying “hey, connect directly to this node that has my content”—took propagation from minutes to seconds.
The piece that ties it together is ENS. My benwoodall.eth has a content hash pointing to the IPFS CID. If my VPS dies, content is still on Pinata and accessible through ENS gateways. If Pinata dies, my VPS has everything pinned. The content persists independent of any single point of failure.
Is it worth it? For practical purposes, probably overkill for a blog. But I write about digital sovereignty and censorship resistance; it would feel hollow to host that on infrastructure that could disappear with a terms-of-service violation. Plus, every time I deploy, I get a little hit of satisfaction watching the CID propagate. My words, addressed by their content, retrievable by anyone who knows the hash. That’s pretty cool.
]]>.eth name might be the most important crypto purchase you never considered
When most people think about cryptocurrency, they think about money—Bitcoin, trading, getting rich quick. But what if I told you that one of the most transformative aspects of crypto has nothing to do with financial speculation and everything to do with something far more fundamental: your digital identity?
Enter ENS (Ethereum Name Service), a technology that’s quietly revolutionizing how we think about identity, privacy, and ownership in the digital age.
Think of ENS as the phone book for the decentralized web. Just like how google.com is easier to remember than 142.250.191.14, an ENS name like alice.eth is infinitely more human-friendly than 0x742d35Cc6b... (a typical Ethereum address).
But ENS is so much more than just a convenience layer. It’s your sovereign digital identity—a name that you truly own, that no corporation can take away, and that works across the entire decentralized web.
When you register yourname.eth, you don’t just get a cool username. You get cryptographic proof of ownership that’s enforced by code, not corporate policy. Twitter can suspend your account, Instagram can delete your handle, but nobody can take your .eth name without your private key.
Your ENS name works everywhere in web3. One identity across:
vitalik.eth in a web3 browser)ENS isn’t just a wallet address—it’s also your decentralized domain name. You can host entire websites on IPFS and point your ENS name to them, creating truly censorship-resistant web presence.
For example, I use benwoodall.eth to host my content on IPFS. You can visit it directly in web3-enabled browsers, or through traditional browsers using gateways like benwoodall.eth.link. This creates multiple ways for people to find your content:
benwoodall.ethThis redundancy means your content stays online even if traditional hosting fails. No single point of failure, no corporate overlord deciding whether your voice deserves to be heard.
Unlike traditional domain names, ENS gives you granular control over what information you share. You can associate your name with just a wallet address, or build a rich profile with social links, avatars, and contact information—all on your terms.
ENS serves as an ideal introduction to web3 concepts because it’s:
Immediately Useful: Even crypto beginners understand the value of a memorable name over a hexadecimal address.
Non-Financial: You’re not gambling on price movements—you’re investing in digital infrastructure and identity.
Educational: The registration process naturally introduces you to:
Future-Proof: As web3 grows, your ENS name becomes more valuable as digital real estate, not just as a speculative asset.
This is where ENS reveals crypto’s true potential. We’re not just building a new financial system—we’re architecting a new internet where:
In an age where tech giants control our digital identities, ENS offers something revolutionary: digital sovereignty.
Ready to claim your digital identity? Here’s how:
yourname.eth instead of your wallet addressWe’re at an inflection point. The next wave of internet users will expect:
ENS isn’t just a technical innovation—it’s a statement about the kind of internet we want to build. One where you own your identity, control your data, and can’t be de-platformed by corporate decree.
ENS represents something profound: proof that cryptocurrency is about much more than money. It’s about building infrastructure for human dignity in the digital age.
Your .eth name is more than a domain—it’s your flag planted in the digital frontier.
So the next time someone asks you about crypto, don’t start with Bitcoin prices or trading strategies. Start with ENS. Start with identity. Start with the revolutionary idea that in web3, you truly own your digital self.
]]>I plan to share thoughts and experiences about:
This site is built with Jekyll and designed to be:
The same codebase serves content for benwoodall.com, bendoubleu.llyxx.me, and bendoubleu.eth with appropriate branding adjustments.
Feel free to reach out via the usual channels. You can find my contact info and public keys linked in the navigation.
73, Ben / W0ODL
]]>