What Is PostSnail Alpha 1?

PostSnail Alpha 1 is a small publishing stack for creators who want to write locally, keep their editable source private, publish a static website they own, and give readers a way to verify what was published.

The short version:

• The shell is your private encrypted .postsnail workspace.
• The trail is your public signed static website.
• The forest is discovery.
• The creator remains the owner.

That is the heart of PostSnail.

It is not trying to be another platform that owns your identity, your dashboard, your archive, and your relationship with readers. It is closer to a portable writing desk, a static website generator, a proof system, and a discovery layer that can work together without becoming one giant landlord.

The problem PostSnail is trying to solve

Publishing on the web often comes with a tradeoff.

You can use a platform and get convenience, but the platform usually owns the account layer, discovery layer, dashboard, and sometimes the relationship with your audience.

Or you can publish your own static site and keep more control, but you may lose easy workflows, proof, portability, and discovery.

PostSnail Alpha 1 explores another path:

• write in a local-first admin,
• keep your private source encrypted,
• export a public static site,
• sign the public output,
• host it anywhere static files work,
• and register public summaries in Forest when you are ready.

The goal is not to make publishing huge.

The goal is to make publishing yours.

The shell: your private workspace

In PostSnail, the private editable source is the .postsnail workspace.

This is the shell.

It is where your editable posts, settings, local workspace data, and private state belong. According to the PostSnail docs, .postsnail files and browser-local Shell caches are encrypted with AES-256-GCM, using a key derived from your Shell passphrase with PBKDF2-SHA-256, random salt, and random IV.

That matters because the shell is not the thing you upload to a public host.

The shell is for the creator.

It should stay private.

If you lose the passphrase, PostSnail cannot recover it for you. That is part of the trust boundary: creator-owned also means creator-held.

The trail: your public static website

The public output is different.

When you publish, PostSnail exports a public Website ZIP. That ZIP contains the static website files: pages, assets, feeds, sitemap, proof records, commit history, and public manifest data.

This is the trail.

The trail is meant to be public. It can be hosted anywhere static files work. The PostSnail concept docs say generated blogs are plain files and do not display PostSnail or Hilazon6 branding.

This separation is important:

• The private .postsnail workspace is not for hosting.
• The public Website ZIP is not the full private project source.
• Drafts and private workspace state should not be in the public ZIP.

That makes PostSnail feel less like a platform account and more like a careful publishing ritual:

Write in the shell. Export the trail. Verify what changed. Then publish.

The proof: signatures and digests

PostSnail is proof-aware.

The public Website ZIP uses SHA3-512 digests and ML-DSA-65 signatures so verifiers can check published content against the creator’s public key.

This is powerful, but it should be explained honestly.

A signature can help prove that a piece of published content matches a public key and expected proof records.

A signature does not prove:

• that the writer is legally who they say they are,
• that every claim in a post is true,
• that the creator’s device was safe,
• or that readers should trust a site blindly.

Proof is not magic.

Proof is a way to make public publishing more accountable.

For creator-owned publishing, that is still a meaningful step. A public trail with verifiable fingerprints is easier to inspect than a feed that can silently change behind a platform wall.

The forest: discovery without ownership

Forest is PostSnail’s discovery surface.

The Forest homepage describes it as a searchable tracker for signed static microblogs. It searches verified public summaries only: site metadata, titles, tags, excerpts, dates, and digests.

This is one of the most important ideas in PostSnail:

The forest is not the home.

Your site can live on your own static host. Forest can help people find it, verify public proof metadata, and search summaries. But Forest does not need to become your identity landlord.

That separation keeps the ecosystem healthier:

• hosting is separate from discovery,
• proof is separate from popularity,
• and the creator’s site remains the source of truth for the reader.

ShellNames: readable paths, not accounts

PostSnail also has ShellNames.

A ShellName is a readable Forest alias for a signed Shell identity. The docs give the shape @[email protected].

But a ShellName should not be oversold.

The ShellNames docs are clear: ShellNames are not accounts, DNS, legal identity, or ownership claims. The public key remains the real identity. The alias is a readable discovery name.

That is a useful distinction.

Human-readable names help people navigate the forest, but the cryptographic identity still matters underneath.

What is available in Alpha 1?

Based on the public PostSnail docs, Alpha 1 includes the local admin, encrypted workspace flow, public Website ZIP export, verification concepts, Forest discovery, docs for ShellNames, and documentation for the current architecture and extension boundaries.

Some publishing helpers, such as SnailLift command assistants, should be described carefully. The publishing docs mention Alpha 1B command assistants for Cloudflare Pages and GitHub Pages. That means content should not pretend every planned helper is already universally available in every environment.

When writing about PostSnail, it is better to say exactly what is known:

• Available now: local-first PostSnail admin and documented Alpha 1 workflows.
• Public publishing model: public Website ZIP that can be hosted on static hosts.
• Discovery model: Forest registration after the site is live and verification passes.
• In development / version-specific: SnailLift command assistant details should be checked against current docs before use.

Honesty builds more trust than hype.

Who is PostSnail for?

PostSnail may be useful for:

• creators who want to own their site files,
• small-web writers who prefer portable tools,
• static site users who want signed public output,
• privacy-first users who care about local encrypted workspaces,
• IndieWeb and open-web people who like discovery without platform capture,
• builders who want forkable publishing infrastructure,
• and communities that care about verification without central ownership.

It is probably not for someone who wants a fully hosted social platform where everything is managed by someone else.

That is okay.

PostSnail is small on purpose.

Practical takeaway

If you are new to PostSnail, understand these three parts first:

1. Your .postsnail workspace is the private shell.
2. Your exported static website is the public trail.
3. Forest helps others discover verified public summaries, but it is not your home.

Once that clicks, the rest of the system becomes easier to understand.

You do not need to rent your identity from a platform to publish on the web.

You can carry your own shell.

You can leave a signed trail.

And when you are ready, you can choose which forest should help others find it.