The thing that pushed Sigil off the road came out of Germany, in a sentence I read twice to make sure I had it right. Their mobile driver’s license, the country’s official state-issued mDL, would REQUIRE Apple or Google’s wallet to function. Not as a recommended client. As a requirement.

I closed the tab and didn’t open it again for a while.

This is an honest accounting of why Thurin Labs has quietly shelved its first product, why the math being right wasn’t enough (zero-knowledge math, mind you), and what I think people building privacy-preserving identity systems should be paying attention to in 2026.

What Sigil Was Supposed to Be

Sigil’s pitch was small and clean: prove you’re a unique human being, without revealing who you are. Connect a wallet. Share your mobile driver’s license. Choose what gets revealed. A zero-knowledge circuit, written in Noir and verified via UltraHonk (always fun to say and write), generates a proof of personhood with a nullifier. A one-time, unlinkable claim that yes, this is a real person, and no, this isn’t the same person twice. The proof mints a soulbound token. No KYC database. No PII stored. The state-issued credential never leaves the device.

It was meant to slot into a fourth category that Vitalik’s proof-of-personhood taxonomy didn’t quite cover. Not biometric. Not social-graph. Document-backed. A real credential, signed by a real DMV, proven without ever being shown. It was the version of the system I would have wanted as a user. Use the credential I already carry. Throw away everything else.

I built it. The circuits compiled. The contract verified. The flow worked. You can prove YOU.

And then the world began re-arranging the input pipeline underneath it.

The First Crack

The first sign was Apple. To read an mDL from an iOS device, you have to go through Apple’s “Verify with Wallet” API. It is closed. It is proprietary. It is mediated entirely by a company whose business model has shifted, year by year, toward becoming the identity arbiter of the consumer internet.

So we pivoted. The Android path, via the W3C Digital Credentials API and OID4VP, used open web standards instead of vendor APIs. I told myself this was actually more aligned with what Thurin was for. The cypherpunk path over the locked one. Not a workaround. The principled implementation.

I still believe that’s true, in the narrow technical sense.

But then I started reading the implementation guidance more carefully. The announcements out of various states. The eIDAS 2.0 timelines. The fine print of Germany’s mDL rollout.

And what is now plainly visible, if you read the documents instead of the press releases, is that the credential root is being captured at the operating system level. Not by accident. Not as a transitional detail. By design. The phone vendors are becoming the holders of state-issued identity, and the states are signing off on it because it solves their distribution problem in one move.

The Input Is the Problem

Here is the sentence I kept writing in my own notes:

Sigil’s ZKP layer is sound. The input to that layer is the problem.

You can write the most rigorous zero-knowledge circuit ever published. You can prove personhood, age, residency, anything you like, without revealing a single bit beyond what’s asked. And if the credential you’re proving over arrives at your device through Apple’s or Google’s wallet, gated by their attestation, signed under their key, presentable only when their software allows it, then your privacy guarantee is downstream of two surveillance companies.

That isn’t privacy. It’s compliance dressed in privacy-preserving aesthetics.

A ZKP on top of a captured input pipeline doesn’t fix the capture.

It launders it.

It makes the resulting credential look sovereign (auditable, math-backed, on-chain) while the actual moment of holding and presenting identity remains the property of someone else. The user is back inside the walled garden, just with a nicer view from the window.

I am not willing to ship that and call it Thurin.

What Forced Digital Identity Actually Looks Like in 2026

This is the part I’d ask people in the privacy space to internalize, because I think it’s still being discussed as something that might happen rather than something that is shipping right now. And it isn’t just Germany. It is shipping in the United States, with very little visible resistance.

The architecture is already built. Not “coming.” Built.

Federally, REAL ID enforcement went live in May 2025. Non-compliant state IDs are no longer accepted at airport checkpoints. Starting February 2026, the TSA introduced ConfirmID, a $45 fee for travelers without acceptable physical identification, with explicit acceptance of Apple Digital ID, Google ID pass, and Clear ID as alternatives. The federal government has, in practice, onboarded the consumer identity duopoly into air travel itself.

At the state level the rollout is faster than the public conversation. Thirteen states and Puerto Rico already have a mobile driver’s license available in Apple Wallet, with seven more committed. The TSA accepts these mDLs at over 250 airports. Georgia’s HB296 went a step further. It mandates that law enforcement accept the mDL at traffic stops, and that every officer carry a reader by mid-2027. The mDL is becoming, by statute, the way the state recognizes you.

The website side of this is moving faster still. Twenty-five U.S. states, half the country, now require a government-issued ID, a credit card, or a facial scan to access whole categories of legal websites. After the Supreme Court’s 2025 ruling in Free Speech Coalition v. Paxton, those laws survive on intermediate scrutiny, the lowest constitutional bar that still permits a law to stand. Nebraska’s age-verification statute takes effect July 1, 2026. California’s SB 976 takes full effect December 31, 2026. More are in flight in more states.

Internationally, eIDAS 2.0 is deploying its digital wallet framework across the EU. Germany’s mDL rollout will not function without Apple or Google.

The two viable mobile holders, for the vast majority of citizens of the vast majority of countries that are rolling any of this out, are Apple Wallet and Google Wallet. The “Verify with Wallet” and Digital Credentials APIs that downstream applications use to read these credentials route through, and can be revoked by, those same vendors.

There is no version of this stack where the user is in control of their own credential root. There is only the version where Apple and Google are. The cryptography downstream of that point is decoration. Beautiful decoration, in some cases. But decoration.

This isn’t a slippery slope argument. The slope already ended. We’re standing in the place the slope was supposed to lead.

Why Thurin Keeps Going Without Sigil at the Front

Putting Sigil down was hard. It was the showcase project, the one that demonstrated the most. It was also the one downstream of architecture I do not control and cannot reform from where I sit.

What I do control are the other two pieces of the Thurin stack. And they are, I think, more interesting precisely because they refuse the mDL pipeline entirely.

Signet doesn’t ask permission from any wallet vendor. It links a PGP key (one you generated, on a machine you control) to an Ethereum address you also control, with a mutual on-chain attestation. The credential root is you. Not a DMV. Not a phone OS. Not a corporate signer. The cryptography you publish is the cryptography you made.

Scry is the explorer that makes those self-issued identities discoverable and verifiable, client-side, without a server. It surfaces the PGP web of trust, on-chain attestations, social proofs, and the EFP social graph. Everything you’ve voluntarily made public, none of what you haven’t.

Together they describe a different architecture: identity that starts at the user and builds outward, instead of starting at a state-or-corporate root and trickling down. PGP is old. Bottom-up identity is old. The new piece is that on-chain attestation finally gives PGP a global, censorship-resistant verifiability layer it never had. Exactly the layer Vitalik gestured at in Make Ethereum Cypherpunk Again when he noted that cryptocurrency was the first thing to give PGP keys mass adoption.

It is slower. It is less shiny than a soulbound proof-of-personhood NFT. There is no government signature anywhere in the chain. That is the point.

On Putting It Down Rather Than Shipping It Compromised

I want to be honest about this last part, because I think it matters.

There was a version of Sigil I could have shipped. iOS first, Apple Wallet API, slick onboarding, growth chart. There would have been users. There would have been writeups. The math really is sound, the demo really does work, and nobody pulling out their phone to mint a soulbound token would have been thinking about credential root architecture while they did it.

I don’t want to be the person who ships well-encrypted compliance and calls it sovereignty. Cypherpunk is not an aesthetic. Build tools, not empires is not a brand tagline. If the credential root for the entire identity layer is being annexed by the two largest empires the consumer internet has ever produced, then the right answer is not to build a beautiful ZK frontend for that annexation. It is to refuse, and to build elsewhere.

Sigil is private now. The code still exists. The circuits still verify. If the credential root ever gets free of OS vendor capture (and this is a real if), I will pick it back up. Until then, it sits.

In the meantime, the work continues. Just not from the captured end of the pipeline.

If you want to see the bottom-up version of this, Signet is where you start. Generate a PGP key, link it to your wallet, publish the attestation. Or look around in Scry to see what an identity graph that doesn’t pass through Apple looks like. Questions, pushback, corrections: bendoubleu.eth, or via my Scry profile.

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.

What WKD Actually Is

The spec is simple. When someone wants your key for you@yourdomain.com, their client:

1. Hashes your local part (you) using a specific Z-Base-32 encoding
2. Makes an HTTPS request to one of two places:
   • Advanced method: https://openpgpkey.yourdomain.com/.well-known/openpgpkey/yourdomain.com/hu/{hash}
   • Direct method: 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.

Step 1: Generate Your Hash

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.

Step 2: Export Your Key

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.

Step 3: Set Up the Directory Structure

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.

Step 4: DNS

For the advanced method, you need an A record pointing openpgpkey.yourdomain.com at your server. Add that wherever you manage DNS.

Step 5: NGINX Config

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;
    }
}

Step 6: TLS for the Subdomain

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

Step 7: Verify

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.

Why This Matters

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.

The Pipeline

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.

Making It Fast

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.

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.

What is ENS, Really?

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.

Why This Matters More Than You Think

True Ownership

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.

Universal Identity

Your ENS name works everywhere in web3. One identity across:

• Cryptocurrency wallets and transactions
• Decentralized websites (try visiting vitalik.eth in a web3 browser)
• Social platforms built on blockchain
• Decentralized finance (DeFi) protocols
• NFT galleries and digital art platforms

Your Decentralized Website

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:

• Web3 browsers: Direct access via benwoodall.eth
• Traditional browsers: Gateway access via benwoodall.eth.link
• IPFS networks: Distributed across thousands of nodes worldwide

This 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.

Privacy by Design

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.

The Perfect Web3 Gateway

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:

• Wallet management
• Blockchain transactions
• Gas fees
• Smart contracts
• IPFS (for decentralized websites)

Future-Proof: As web3 grows, your ENS name becomes more valuable as digital real estate, not just as a speculative asset.

Beyond Money: Identity and Privacy

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:

• Identity is portable: Your reputation and connections aren’t trapped in corporate silos
• Privacy is programmable: You control exactly what information to share and with whom
• Censorship is nearly impossible: Your identity lives on a decentralized network, not corporate servers

In an age where tech giants control our digital identities, ENS offers something revolutionary: digital sovereignty.

Getting Started: Your First Step Into Web3

Ready to claim your digital identity? Here’s how:

1. Choose your name: Check availability at ens.domains
2. Set up a wallet: MetaMask is beginner-friendly
3. Register your name: Annual fees are surprisingly affordable (usually $5-20/year depending on name length)
4. Configure your profile: Add your social links, avatar, and website
5. Share your identity: Start using yourname.eth instead of your wallet address

Why Now?

We’re at an inflection point. The next wave of internet users will expect:

• True ownership of their digital identity
• Control over their personal data
• Interoperability between platforms
• Censorship resistance

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.

The Bigger Picture

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:

• Amateur Radio: My adventures with W0ODL, including SOTA activations, QRP operations, and learning CW
• Coding: Projects in Ruby, Rust, Solidity, and other languages I’m working with
• Privacy & Cryptography: Thoughts on digital privacy, cryptocurrency, and security
• General Musings: Whatever else catches my interest

Technical Details

This site is built with Jekyll and designed to be:

• Static and IPFS-friendly
• Responsive and minimal
• Domain-aware (different branding for different access points)
• Easy to maintain

The same codebase serves content for benwoodall.com, bendoubleu.llyxx.me, and bendoubleu.eth with appropriate branding adjustments.

Get in Touch

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