One problem self-hosted blogs face is that the size of their content should be kept under control, in order to remain within the limits of the virtual server. This means video content or large attachments (>10GB per post) are out of reach for self-hosted blogs. For publishing video content, the mainstream option is a specialized, ad-supported platform, even if the quality of its service is constantly degrading.

This post tries to show an alternative path, a blueprint for delivering blog content, using low-cost infrastructure and interoperable tools.

The protocol aspect (Initial file release)

By releasing files via BitTorrent (possibly with a pre-populated cluster of low-cost seedboxes), this project is creating a ghetto-style CDN. The useful thing is that if the readers themselves contribute with bandwidth and storage, sharing large files becomes practical. The protocol itself has been in use for more than a decade, so it’s well understood.

The main drawback is that, due to the P2P nature of the BitTorrent protocol, it’s not privacy-protecting (every participant in the BitTorrent swarm can see the IP address of every other participant).

To keep things organized, this website has its own BitTorrent tracker: https://tracker.personalcompute.net/.

The legal aspect (Licensing & copyright)

Since the files are supposed to be propagated across the web, their licensing must be compatible with redistribution. This means that the content must fall into the open-source software, creative-commons or public-domain categories of license.

As a general guideline, new content will be covered under CC BY-NC-SA (🅭 🅯🄏🄎) license, but other permissive licenses such as CC BY-SA (🅭 🅯🄎) or CC BY-ND (🅭 🅯⊜) can appear.

The cryptographic aspect (Copy authentication)

For everyone who objects to using BitTorrent due to privacy issues, there is a path forward included, right from the design-stage. By hashing the files inside the bundle and cryptographically signing the result, it’s possible to check if it originated from the blog. The OpenBSD community already has a tool for this purpose: signify (which they’ve been using for a decade).

As of 2025, the cryptographic algorithms are SHA256 for hashing and Ed25519 for signatures (but as the field of cryptography evolves, vulnerabilities start to appear, cracking hardware becomes more accessible, and new algorithms can be added). Example of a signed-bundle file: https://cdn.openbsd.org/pub/OpenBSD/7.8/SHA256.sig.

The key management reflects the best-practices used by the OpenBSD maintainers:

  • The signing key is kept on an offline machine (no internet connection, only powered on when necessary).
  • Periodic key rotation: every year a new signing key is generated, and for every year, the public key for the following year is being disseminated (ex: during the year 2025, the public keys for the 2025 and 2026 years are being published).
  • The public keys are made available in an easy-to-check way (both as downloadable files and DNS TXT records) - https://personalcompute.net/keys.

There are drawbacks of using the “signify” tool on mirrored file-bundles, but these are more user-interface problems rather than algorithm problems, and could be fixed by replacing a few snippets of code.

  • If the mirror adds new files to the bundle, the “signify” tool will not raise a warning that the downloaded content contains unaccounted files (but has enough information to make this determination).
  • If the mirror changes the content of a single file, the validation of the entire file-bundle fails (but the “signify” tool can be tweaked to indicate which files can or cannot be authenticated).

Some final points

By combining the three aspects, we obtain the following additional benefits:

  • Privacy & Interoperability: Since the files can be downloaded and redistributed without restrictions, one could mirror the files using any other tools (with better privacy characteristics): private trackers, trusted DC++ hubs, messenger file-transfers or university servers - anything works. And since all file-releases are cryptographically signed, the end-user can (and should) check if any of the files were altered.

  • Availability: even if the main server is offline, readers don’t depend on it to access the content - they just need a reference to the BitTorrent files and the public key for signature-validation. One problem with older blogs (from 10-15 years ago) is that once the server is shut down, their content is practically lost-media, since the author retains the exclusive right to host that content - with a bit of luck you might find some posts on the Wayback Machine, but that’s not a certainty. But by having the content usable offline (and shared on a distributed infrastructure), the content can still be accessed.