@ d61f3bc5:0da6ef4a

I remember the first gathering of Nostr devs two years ago in Costa Rica. We were all psyched because Nostr appeared to solve the problem of self-sovereign online identity and decentralized publishing. The protocol seemed well-suited for textual content, but it wasn't really designed to handle binary files, like images or video.

The Problem

When I publish a note that contains an image link, the note itself is resilient thanks to Nostr, but if the hosting service disappears or takes my image down, my note will be broken forever. We need a way to publish binary data without relying on a single hosting provider.

We were discussing how there really was no reliable solution to this problem even outside of Nostr. Peer-to-peer attempts like IPFS simply didn't work; they were hopelessly slow and unreliable in practice. Torrents worked for popular files like movies, but couldn't be relied on for general file hosting.

Awesome Blossom

A year later, I attended the Sovereign Engineering demo day in Madeira, organized by Pablo and Gigi. Many projects were presented over a three hour demo session that day, but one really stood out for me.

Introduced by hzrd149 and Stu Bowman, Blossom blew my mind because it showed how we can solve complex problems easily by simply relying on the fact that Nostr exists. Having an open user directory, with the corresponding social graph and web of trust is an incredible building block.

Since we can easily look up any user on Nostr and read their profile metadata, we can just get them to simply tell us where their files are stored. This, combined with hash-based addressing (borrowed from IPFS), is all we need to solve our problem.

How Blossom Works

The Blossom protocol (Blobs Stored Simply on Mediaservers) is formally defined in a series of BUDs (Blossom Upgrade Documents). Yes, Blossom is the most well-branded protocol in the history of protocols. Feel free to refer to the spec for details, but I will provide a high level explanation here.

The main idea behind Blossom can be summarized in three points:

1. Users specify which media server(s) they use via their public Blossom settings published on Nostr;
2. All files are uniquely addressable via hashes;
3. If an app fails to load a file from the original URL, it simply goes to get it from the server(s) specified in the user's Blossom settings.

Just like Nostr itself, the Blossom protocol is dead-simple and it works!

Let's use this image as an example:

If you look at the URL for this image, you will notice that it looks like this:

blossom.primal.net/c1aa63f983a44185d039092912bfb7f33adcf63ed3cae371ebe6905da5f688d0.jpg

All Blossom URLs follow this format:

[server]/[file-hash].[extension]

The file hash is important because it uniquely identifies the file in question. Apps can use it to verify that the file they received is exactly the file they requested. It also gives us the ability to reliably get the same file from a different server.

Nostr users declare which media server(s) they use by publishing their Blossom settings. If I store my files on Server A, and they get removed, I can simply upload them to Server B, update my public Blossom settings, and all Blossom-capable apps will be able to find them at the new location. All my existing notes will continue to display media content without any issues.

Blossom Mirroring

Let's face it, re-uploading files to another server after they got removed from the original server is not the best user experience. Most people wouldn't have the backups of all the files, and/or the desire to do this work.

This is where Blossom's mirroring feature comes handy. In addition to the primary media server, a Blossom user can set one one or more mirror servers. Under this setup, every time a file is uploaded to the primary server the Nostr app issues a mirror request to the primary server, directing it to copy the file to all the specified mirrors. This way there is always a copy of all content on multiple servers and in case the primary becomes unavailable, Blossom-capable apps will automatically start loading from the mirror.

Mirrors are really easy to setup (you can do it in two clicks in Primal) and this arrangement ensures robust media handling without any central points of failure. Note that you can use professional media hosting services side by side with self-hosted backup servers that anyone can run at home.

Using Blossom Within Primal

Blossom is natively integrated into the entire Primal stack and enabled by default. If you are using Primal 2.2 or later, you don't need to do anything to enable Blossom, all your media uploads are blossoming already.

To enhance user privacy, all Primal apps use the "/media" endpoint per BUD-05, which strips all metadata from uploaded files before they are saved and optionally mirrored to other Blossom servers, per user settings. You can use any Blossom server as your primary media server in Primal, as well as setup any number of mirrors:

## Conclusion

For such a simple protocol, Blossom gives us three major benefits:

1. Verifiable authenticity. All Nostr notes are always signed by the note author. With Blossom, the signed note includes a unique hash for each referenced media file, making it impossible to falsify.
2. File hosting redundancy. Having multiple live copies of referenced media files (via Blossom mirroring) greatly increases the resiliency of media content published on Nostr.
3. Censorship resistance. Blossom enables us to seamlessly switch media hosting providers in case of censorship.

Thanks for reading; and enjoy! 🌸

@ 4961e68d:a2212e1c

热死人了

@ 4961e68d:a2212e1c

热死人了！

@ 2183e947:f497b975

Most darknet markets (DNMs) are designed poorly in the following ways:

1. Hosting

Most DNMs use a model whereby merchants fill out a form to create their listings, and the data they submit then gets hosted on the DNM's servers. In scenarios where a "legal" website would be forced to censor that content (e.g. a DMCA takedown order), DNMs, of course, do not obey. This can lead to authorities trying to find the DNM's servers to take enforcement actions against them. This design creates a single point of failure.

A better design is to outsource hosting to third parties. Let merchants host their listings on nostr relays, not on the DNM's server. The DNM should only be designed as an open source interface for exploring listings hosted elsewhere, that way takedown orders end up with the people who actually host the listings, i.e. with nostr relays, and not with the DNM itself. And if a nostr relay DOES go down due to enforcement action, it does not significantly affect the DNM -- they'll just stop querying for listings from that relay in their next software update, because that relay doesn't work anymore, and only query for listings from relays that still work.

2. Moderation

Most DNMs have employees who curate the listings on the DNM. For example, they approve/deny listings depending on whether they fit the content policies of the website. Some DNMs are only for drugs, others are only for firearms. The problem is, to approve a criminal listing is, in the eyes of law enforcement, an act of conspiracy. Consequently, they don't just go after the merchant who made the listing but the moderators who approved it, and since the moderators typically act under the direction of the DNM, this means the police go after the DNM itself.

A better design is to outsource moderation to third parties. Let anyone call themselves a moderator and create lists of approved goods and services. Merchants can pay the most popular third party moderators to add their products to their lists. The DNM itself just lets its users pick which moderators to use, such that the user's choice -- and not a choice by the DNM -- determines what goods and services the user sees in the interface.

That way, the police go after the moderators and merchants rather than the DNM itself, which is basically just a web browser: it doesn't host anything or approve of any content, it just shows what its users tell it to show. And if a popular moderator gets arrested, his list will still work for a while, but will gradually get more and more outdated, leading someone else to eventually become the new most popular moderator, and a natural transition can occur.

3. Escrow

Most DNMs offer an escrow solution whereby users do not pay merchants directly. Rather, during the Checkout process, they put their money in escrow, and request the DNM to release it to the merchant when the product arrives, otherwise they initiate a dispute. Most DNMs consider escrow necessary because DNM users and merchants do not trust one another; users don't want to pay for a product first and then discover that the merchant never ships it, and merchants don't want to ship a product first and then discover that the user never pays for it.

The problem is, running an escrow solution for criminals is almost certain to get you accused of conspiracy, money laundering, and unlicensed money transmission, so the police are likely to shut down any DNM that does this. A better design is to oursource escrow to third parties. Let anyone call themselves an escrow, and let moderators approve escrows just like they approve listings. A merchant or user who doesn't trust the escrows chosen by a given moderator can just pick a different moderator. That way, the police go after the third party escrows rather than the DNM itself, which never touches user funds.

4. Consequences

Designing a DNM along these principles has an interesting consequence: the DNM is no longer anything but an interface, a glorified web browser. It doesn't host any content, approve any listings, or touch any money. It doesn't even really need a server -- it can just be an HTML file that users open up on their computer or smart phone. For two reasons, such a program is hard to take down:

First, it is hard for the police to justify going after the DNM, since there are no charges to bring. Its maintainers aren't doing anything illegal, no more than Firefox does anything illegal by maintaining a web browser that some people use to browse illegal content. What the user displays in the app is up to them, not to the code maintainers. Second, if the police decided to go after the DNM anyway, they still couldn't take it down because it's just an HTML file -- the maintainers do not even need to run a server to host the file, because users can share it with one another, eliminating all single points of failure.

Another consequence of this design is this: most of the listings will probably be legal, because there is more demand for legal goods and services than illegal ones. Users who want to find illegal goods would pick moderators who only approve those listings, but everyone else would use "legal" moderators, and the app would not, at first glance, look much like a DNM, just a marketplace for legal goods and services. To find the illegal stuff that lurks among the abundant legal stuff, you'd probably have to filter for it via your selection of moderators, making it seem like the "default" mode is legal.

5. Conclusion

I think this DNM model is far better than the designs that prevail today. It is easier to maintain, harder to take down, and pushes the "hard parts" to the edges, so that the DNM is not significantly affected even if a major merchant, moderator, or escrow gets arrested. I hope it comes to fruition.