Why isn't Blossom more torrent-compatible? For censorship, of course.
Maybe not only for censorship. Blossom's design actually seems to play both sides, supporting censorship and resisting it. That might sound impossible.
The root of the issue is pretty straightforward:
# Why didn't the devs use a more BitTorrent-compatible address format?
It's odd, considering BitTorrent and Blossom both use hash addresses to keep track of each file.
(For those unaware, file hashes are a cryptographic function, a math trick that calculates a one-in-trillions sequence of random characters that will never be calculated the same from any other file. Since a small change in the file will change the hash, another common usage is verifying if copies are error-free, without transferring the entire copy to check.)
Important: unlike Blossom, the hash address for a torrent can optionally have multiple files, instead of just one. Each torrent is then broken down into small segments called a "piece" and smaller segments called a "block."

Each piece gets its own hash, but a block doesn't - so you need all the blocks in a piece to verify it matches, even if the piece includes files or parts of files you don't want.
This isn't much of a problem because pieces can be pretty small (and blocks are tiny, usually 16KB each).
## Blossom's current design
Blossom simplifies all this, by simply relying on single-file hash addresses.
All Blossom URLs follow this format:
> [server]/[file-hash].[extension]
For example:
> π‘πππ©π¬://ππ₯π¨π¬π¬π¨π¦.πππ§π/ππππππππππππππππππππππππππππππππππππππππππππππππππππππππππππππππ.π¦π©π
Using a hash-based address makes them fairly long, but not egregious. These URLs are simple enough for users to parse by hand.
These hash addresses enable you to search for any missing files across other servers. Nostr clients can also be programmed to do this automatically.
### The advantage
This creates a sort of underground tunneling route between places like Tor and the walled DNS garden. For example, if the authorities blocked Tor users from making DNS requests to blossom.band, it wouldn't force users to separate from each other.
Users on the DNS part of nostr could post their images the same as ever, and users on Tor would just need someone to copy posts over to Tor-based servers. Clients would be programmed to automatically find images by their hash, instead of going through DNS.
## What if they did make it BitTorrent compatible?
### Single-file method
Everything could work the exact same using BitTorrent-compatible hash addresses, with a rule that the hash has to be a single-file torrent.
The URL format could be like this:
> [server]/[file's-torrent-hash].[extension]
When a user requests a file over DNS with this URL, it uses Blossom.
But they can also just take the torrent hash part and use it as a torrent.
This seems perfect, except that single-file torrents are inherently unwieldy for the BitTorrent network at the scale we're talking about.
It's likely that many files wouldn't actually end up being backed up on the BitTorrent network. Despite being "BitTorrent compatible," these hash addresses might still usually not work outside Blossom, due to just not having enough seeders.
Blossom hosts could offer seedbox services, but it would be a challenge to reliably maintain good service for their paid users in that case - let alone the whole network.
### Batch method
Packing multiple files in a torrent would make it much easier to find seeders. The system could also naturally match users to each other to help seed each other's files in each batch. That's where BitTorrent integration would get a lot more complicated.
First, if you're not limiting each torrent to a single file, you need a more complicated address, to specify what torrent you're looking for and what file you want from that torrent. There would have to be a replaced or added URL format, something like:
> [server]/[file's-torrent-hash]/[file-path-in-torrent-file-tree]
Those URLs might get even longer, but still easy enough to parse by hand. Not too bad.
Blossom servers for web-based embedding would still work as usual, while BitTorrent-based clients could be programmed to use the corresponding torrent's metadata to match the file path to the right "blocks" and "pieces."
The real challenge is balancing user impatience against trying to collect files together into fewer torrents.
When I upload an image, as a user, I want it to be available almost instantly. And if we're trying to batch multiple images into single torrents, posts might need to be queued as drafts, waiting for media uploads to get their own hash addresses.
If we pick 1 torrent hash per hour as an example speed, I'd have to wait a long time, before an address actually exists. Even if it was 1 per minute, it would still feel like a long time in some cases.
I'm a communist, but I have to admit, this might be one of those things best solved by capitalism. You could have some set speed like 1 torrent per hour for free users, but let users tip 1 sat or more to post in a separate bucket, where a torrent is generated when enough tips accumulate.
A user in a hurry would just have to tip enough to hit the threshold immediately, helping their fellow users.

Every torrent could even be a contest, by making the file paths a ranking of the highest tippers, so the #1 highest tip gets a URL like:
> [server]/[file's-torrent-hash]/1.png
Blossom devs are capitalists, so what's wrong with this idea? Isn't it still better than the current design?
## Existing vulnerability
The current design still has some degree of control tied to centralized servers. It uses hash addresses like BitTorrent, but it's not P2P like BitTorrent.
Tor and non-Tor image hosting services combined are probably operated by far fewer people than BitTorrent seeds. By not being P2P, this design limits the number of people the authorities have to go after to ensure a file is removed.
If all the Blossom devs and nostr media hosts were targeted, would backups reliably stay online thanks to hash-based addresses?
Honestly, Blossom kinda makes nostr look held together with duct tape. Even if someone built a BitTorrent bridge to patch the hole, it would still seem janky due to the mismatching hash addresses.
I understand that BitTorrent integration would be a lot of coding work. But we're only talking about compatible addresses here, not full integration.
## So again: why?
Why didn't they use BitTorrent addresses? Why not make it easy for everything to be backed up P2P, with every possible seeder?
I want to say it's because Blossom devs are a bunch of glowies that hate freedom and America and kittens; however, some of them host my content on nostr, without really trying to remove it so far; so I have to ponder if there's more to it.
Did they just not realize they had these options? Maybe at some stage of development - but by now, I assume at least one Blossom dev has considered ideas like these. Maybe they've even written about it, somewhere I haven't seen.
Or maybe I've uncovered their secret weapons.
Maybe the Blossom devs already have plans like these up their sleeves, as a nuclear option to defend nostr from legislative attacks.
### A delicate balance
I mentioned how, if the DNS network started trying to isolate Tor users, Blossom helps us strategically answer.
Maybe Blossom devs are ready to build up the exact tools needed for that, as soon as they become more needed.
Maybe they're ready to migrate to BitTorrent too.
Maybe they have some strategic skills.
It's true that a BitTorrent-based system would be more censorship resistant. It would be more impossible to fully remove any content people want to keep on the network - no matter how many others want it gone.
Many people aren't firmly against censorship. They would consider something like this too censorship resistant, because it promotes the use of BitTorrent for behaviors like spreading disinformation or child abuse material.
If the Blossom devs did this, they could be targeted by the general public very dangerously.
Blossom offers a release valve. If people overwhelmingly agree something should be removed, it potentially can be. Blossom devs can safely host content for users, and answer takedown requests for the authorities.
But if the authorities abuse those takedown requests, that release valve can be taken away; and it might be much harder to blame the devs for taking it away.
If nostr media hosts find themselves unhappy with how the authorities ask them to treat users, they could suddenly use that to promote a wave of users and other devs migrating with them to more decentralized backend networks, like Tor and BitTorrent.
Migrating old Blossom files to BitTorrent addresses wouldn't be too hard. Blossom's design allows for easy backwards compatibility.
Blossom hosts could transfer their existing libraries by simply keeping the old Blossom hashes as the new filenames in new batch torrents. Then, they could publish lists of these torrents, so that if the original DNS servers are taken away, nostr clients could then be programmed to search a given Blossom host's torrents for files matching the [file-hash].[extension] part of any legacy Blossom URL.
There is no one to answer takedown requests on a P2P network. No more of those rare chances to interrupt the spread of something truly harmful.
But there would also be no devs to blame for what users do peer-to-peer, with tools built to correct tyranny.
Sun Tzu suggested you should never corner an enemy completely.
By not integrating BitTorrent, the Blossom devs didn't checkmate the authorities. But they put them one move from checkmate. The authorities pushing for a totalitarian internet are faced with a choice: resign the match, or make one fatal move.
Despite some chat-bot-esque phrasing, this is all human writing, with chat bots relegated to tasks like generating the thumbnail. As the human that wrote this: personally, after seeing the instant checkmate available, I would have taken it.
Considering the bad sportsmanship of the losing team, that might have gotten me killed... good thing I can't code. Maybe Sun Tzu and the Blossom devs have some wisdom.
Now you see how they've allowed a delicate balance of censorship to survive here, as long as it can. Until someone, perhaps a bit too jumpy, ends that era.
I have got to remember how to write like this about topics other than nostr. My life has been consumed by the machine. Follow me for more