Handshake After ICANN Reveal: Shakescape, Pinner and User Choice

Our October 2026 Handshake Mastermind covered ICANN name collisions, Shakescape mobile browsing and Pinner’s static hosting. The October 10 discussion focused on making naming roots visible, giving users a choice when answers overlap, and helping TLD owners publish useful sites.

At our October 10, 2026 Handshake Mastermind, that question led to a wider discussion about what people can actually do with their names. The practical response was to explain which root a name uses, let people choose when answers overlap, and make it easier to publish something worth visiting. Shakescape, Pinner and HNSDNS were among the projects discussed.

The session ran for almost 90 minutes. People disagreed about Handshake’s response to ICANN, then got into mobile browsing, hosting and how to help the next person use a name.

The reveal gives us applications, not live extensions

ICANN’s Reveal Day was October 7. It made the applied-for strings and public application information available. Its published Reveal Day contention list contains 13 applications for .agent.

That is an application count, not 13 operating registries. The applications still have a process to go through, including a replacement-string period before String Confirmation Day on November 17.

For Handshake owners, the concern is that some applied-for strings already exist in the Handshake root. If the same string later operates in the conventional DNS root, its spelling alone will not tell a user which naming system they are reaching.

SkyInclude operates the .agent registry on Handshake, so this distinction affects our own work too. A Handshake name continues to belong to the Handshake namespace. An ICANN application does not turn it into an ICANN registration. Anyone offering names needs to explain that distinction in ordinary language.

A collision needs a visible choice

Handshake reserved existing ICANN TLDs at launch, including familiar extensions such as .com. That compatibility choice is part of the project’s history. The Handshake FAQ explains the original reservations.

The Mastermind revisited whether those reserved names should be opened. Some participants wanted to stop giving the conventional root that special treatment. Others wanted to preserve interoperability and avoid making Handshake harder for ordinary users to understand.

Mike Michelini favored preserving the original compatibility approach. The opposing argument also has a published home: Scott Florcsk’s “It’s Your Move, Handshake” asks the community to consider releasing previously reserved names. These are positions in a debate, not a protocol change announced by the Space.

The browser discussion made the problem concrete. If two roots give different answers for a name, a silent default can send someone to a site they never intended to visit. A visible namespace indicator and a way to choose the other root make that decision easier to understand.

Our view: people should be able to see which root answered. Choosing a default is a product decision with consequences, especially when users already know a site under the same spelling.

Our alternative DNS roots article explains the history behind this debate. The October discussion brought it down to the moment someone types a name: show them the root and make the choice clear.

Shakescape brings the discussion onto a phone

Shakescape brought a mobile browser into the conversation. It is built for Handshake on Android and Apple platforms. Its public repository documents local validation of Handshake headers and name proofs, followed by DNSSEC and DANE checks for browsing. The project checks evidence about the name and connection (rather than simply trusting a remote lookup result).

During the Space, its builder described checking the conventional and Handshake roots, initially favoring the conventional site when both returned a site, and offering a switch. The group debated whether a Handshake browser should prefer Handshake instead. The current repository describes explicit namespace selection and rejection of ambiguous, conflicting answers.

Try that as a browser test. Can you tell which namespace you are in? What happens when the answers disagree?

Shakescape’s mobile work is separate from our SkyInclude Browser launch. More ways to reach Handshake names give users more choice, but the choice needs to be understandable.

Pinner tackles the publishing side

A name also needs somewhere to point. Pinner, a Lume Web service, was presented as a way to publish static websites on IPFS. A portfolio, a simple blog or a project page is a good starting example. A static host does not, by itself, supply an ecommerce backend.

The discussion included agent-assisted deployment through Pinner’s MCP interface. MCP gives compatible AI tools a way to call a service’s tools. The builder described Handshake support and invited testing, while acknowledging that not every path was mature. Bring a small site and a real name, then report exactly where you get stuck.

Pinner’s hosting documentation also provides CLI and SDK routes for mapping a domain to an IPFS content identifier. A successful upload and a working domain are separate things to check. After the files are stored, can someone reach the intended content through the intended name?

The session also highlighted HNSDNS, which publishes a Handshake DNS-over-HTTPS resolver. It offers a hosted lookup route for compatible software. You are still choosing a resolver operator. Encrypting the lookup protects the connection to that service; it does not turn a hosted service into local validation.

Our earlier FirePortal discussion shows how DNS records can connect a Handshake name with IPFS content. Pinner adds a hosting service with documented CLI and SDK routes, plus the agent interface discussed in the Space.

The Headless Domains roadmap update

The conversation also turned to Headless Domains and whether its names could support other on-chain models. During our Space, Mike said Headless Domains did not yet support HIP-5. He described minting and blockchain support as possible roadmap work, and mentioned that the team was considering lifetime options.

HIP-5 describes how a compatible Handshake resolver can use special name records to resolve through an external namespace or system. Minting a name is a separate operation; HIP-5 is part of the resolution design.

For us at SkyInclude, this was a useful exchange between a registrar operator and builders working on hosting and resolution. Mike agreed to continue the discussion with the Pinner builder. He also raised moving his ShakeDex IPFS pins from Pinata to Pinner. These were follow-up discussions, with no launch date or completed migration announced.

Those plans describe the Headless Domains discussion on October 10. We will cover further developments on SkyInclude.com as they become available.

Five things for TLD owners to think through

One participant organized the owner discussion around five words: collisions, concerns, complexity, context and content. It gave owners a way to look at their own work while the wider root debate continues.

For an operator, that raises a few practical questions. What other naming systems use your string? Do users understand which root your names use? Can a newcomer find your instructions without searching several chat groups? And is there something at the name worth visiting?

The conversation also raised an onboarding idea: acquire names ahead of time, then transfer them to newcomers so they can begin building without first learning the full auction process. That is an idea for a program, not an announced giveaway or an instant-transfer promise.

AI tools add pressure to make this easier. Participants argued that if someone can create a site in a chat, connecting a name should not become the most confusing part of the job. Handshake-aware agents can work through configured CLI, API and resolver paths; they do not need to wait for a conventional browser to add native support.

Connecting a name to a site should feel manageable to the person building it. Expressive names, including emoji names, came up as possibilities. Their value will depend on what people build and how well the experience works.

Bring a working example to the next Mastermind

If you want to act on this session, start with one name and one small site. Try a Handshake-aware browsing or resolver path, check which root answered, and ask someone else to open the page. Keep a note of what worked and where they got stuck.

You can start with the SkyInclude Browser page, investigate Shakescape’s mobile project, or use Pinner’s documentation to explore static hosting. If you are still getting familiar with the naming system, our Handshake 101 guide gives you the background.

We intend to continue Handshake Mastermind as an open community conversation, with sessions at least monthly. Follow SkyInclude on X for the next announcement. Bring a site, a tool or a specific problem the community can work through. We would like to feature more of that work on SkyInclude.com.