Our ToS and Privacy Policy has up to this point been mostly boilerplate. As we onboard more customers, it made sense to me to make sure that our ToS and Privacy documents reflected our ethos more directly. Today I've added a "Your Content" section to each, which guarantee that when you put your site on Archival infra, you do not release any ownership of it, and we can't use it, sell it, or train AI with it.

In the future, we might reach out to some of you for permission to do things like this (mostly just using your sites in marketing campaigns and the possibility of fine-tuning our LLMs using your sites in addition to our own training sets) - but we'll never do this without asking.

Archival continues to be the easiest way to host your own website, and we think that if we can use your stuff without your permission, it's not really yours. We hope that this subtle but important differentiation will make it easier to build on our platform instead of the extractive ones.

As always, all our site edits are public, so you can see the full diff of what changed here: https://github.com/archival-dev/archival-docs/commit/be995cae2e046227e8406f29c8fc59af6c5cff8c

Archival recently introduced a 'secrets' type - the archival rust lib and CLI just treats these a little differently than other strings, in that it refuses to render them but otherwise they're the same as strings.

The reason for this introduction was to allow (via carriers) the use of privileged operations without exposing secrets on the client - for instance, I use this at my bar to read and write to a google sheet via a service account, which allows guests to book directly into our host sheet.

However it bothered me that the use of these secrets meant that you really needed to make sure your site repo was never public. I'd much prefer to share my site repos with the world, but as soon as a secret was introduced, I'd need to close the source since there would be plaintext secrets in git.

As of today, that tradeoff is no longer necessary. Archival automatically encrypts all secrets before writing to backing git repos, and decrypts values when editing - so you can interact with secrets just like before, but public repos will only have encrypted values for secrets, which can't be read without the editor.

This is another example of how separating content from presentation can be very powerful. Having strong types for these values means that we could make this change without introducing a new API or requiring configuration.

After I clean out my repo history or rotate my service account keys, I'll be able to make my restaurant site's repo public, so other folks can take a look at how to build a robust reservation system entirely on Archival and google sheets.

Archival recently got the ability to really easily add activitypub to a site. As you can see on this site's public github repo, you can simply map an object type (or ask task mode to do it for you) to the activitypub fields, and we'll automatically detect this and set up the webfinger endpoint and the other activitypub endpoints needed to federate your posts to various platforms.

For instance, with just this config, this post and the other updates can now be read via rss and on various federated social feeds. For instance:

• Threads: https://www.threads.com/fediverse_profile/@updates@archival.dev
• Bluesky (via Bridgy Fed): https://bsky.app/profile/updates.archival.dev.ap.brid.gy
• Flipboard (Surf): https://surf.social/feed/mastodon%2Fuser%2F%40updates%40archival.dev
• Mastodon: https://mastodon.social/@updates@archival.dev
• Misskey: https://misskey.io/@updates@archival.dev
• NodeBB forums: https://community.nodebb.org/user/updates@archival.dev/posts
• Pleroma: https://devs.live/users/BAuWz6JLzYsTWLiakS
• Akkoma: https://fe.disroot.org/@updates@archival.dev
• Sharkey: https://blahaj.zone/@updates@archival.dev
• Micro.blog: https://micro.blog/updates@archival.dev

These all will now sync up with the updates on this site, along with hundreds more.
Want to own your data and still have social links to follow and share? Now you can on Archival!

Archival 0.22.0 is released, with a few small quality of life fixes as we push towards 1.0

Comment clobbering

archival format no longer deletes comments in archival files (although writing to objects via the editor still will - keep comments in object definition files!)

Slug Addresses

It felt non-intuitive that we couldn't address objects by their slug, since we have root object access that way. This enables things like {{ posts.something.name }} where something is the object file at objects/post/something.toml - note that if the slug has dashes, you have to use bracket syntax ["my-post"], which shouldn't be a surprise but is worth noting. This is especially useful when looking up fields, since that used to be:

{{sample_menus | where: "slug", "lunch" | map: "url" | first }} to get the URL, which not only is hard to read but has to map the whole array. That now condenses to {{ sample_menus.lunch.url }}, which I'd hope would be the first thing you'd think of.

The homepage used to describe the templates. Now it shows them: two rows of real sites drifting in opposite directions, pulled live from the editor's own catalog, so the wall is never out of date with what you'd actually get.

Click any tile to open that template in the editor.

Archival now speaks MCP, so an assistant can author a site end to end without a checkout, a local toolchain, or a copy of the CLI. It writes the object files and templates, builds them against a pinned archival binary on our side, and hands back a preview URL you can look at and react to.

Build errors come back as tool output, which means the assistant can fix its own templates instead of handing you a broken site.

See Building with Claude for setup.

Add the schema comment to the top of your archival_objects.toml:

#:schema https://archival.dev/schemas/archival_objects.schema.json

Your editor will complete field types, flag a definition that can't build, and explain the reserved keys inline. The same schemas are in the SchemaStore catalog, so most editors pick them up with no comment at all.