What I made
I made an Android app called Bouquet. In short, it is a viewer that shows you a website, even though no server is serving that website.
When you open a normal website, your browser talks to some company's server, and downloads HTML and images from it. The server for example.com is example.com's server. One site has one host. Bouquet does not have this kind of dedicated host for the site.
It does not mean there is no server at all. The parts of the site are stored on general servers (relays and Blossom, I will explain them later). But these are just shared storage that many people use for many kinds of data. They do not exist to serve one specific site. The work to collect the parts and build them back into one site is done by your phone, not by a server.
There is no dedicated host in the middle. This is the main point of this project.
First let me explain how a normal website works, then why we can remove the host.
How a normal website works
When you open https://example.com, this is roughly what happens:
You --"give me example.com"----> example.com's server
You <---- HTML / CSS / images -- example.com's server
One server holds everything. This has some effects:
- If the server goes down, you cannot see the site.
- The owner of the server can see who watched what, and when.
- If the domain is taken down, the site disappears.
It is convenient in daily life, but you are trusting everything to one host. Bouquet tries to remove this single point.
The key idea: find files by content, not by location
A normal website finds a file by its location: /index.html on example.com. Because you use the location, you need a host that owns the location.
Bouquet finds a file by its content instead.
If you put a file into a hash function, you get a short string, like a fingerprint. The same content always makes the same fingerprint. If even one byte changes, the fingerprint becomes completely different. So if you know the fingerprint, you can check by yourself if the file is the one you wanted, no matter who gave it to you.
This is the important point. If you can find a file by content, the file does not need to be on one specific trusted server. You can get it from anywhere, and if the fingerprint matches, it is the real one.
The parts are in two places
The data of a site is stored in two kinds of place. These are the only two players.
Relays have the "file to fingerprint" table
A relay is just a server that keeps short messages and sends them again. Bouquet stores the table of contents of the site on relays. The table is simple:
/index.html -> hash abc123...
/style.css -> hash def456...
/logo.png -> hash 789xyz...
It is just a "file path to fingerprint" table. The file contents are not here. It is only a map that says "this site is made of these files, and each fingerprint is this."
Blossom has the file contents
Blossom is a storage that you read and write by fingerprint. If you say "give me the file with hash abc123...", it returns the bytes.
Because Blossom manages contents by fingerprint, it does not care who owns the site, or which server it is. You can have many Blossom servers, and from any of them, you can still check the bytes with the fingerprint in the table.
The phone resolves everything
Now let me put them together. This is what Bouquet does:
- Get the table of contents (path to fingerprint) from a relay.
- Use the fingerprints to get the file contents from Blossom.
- Hash each file by yourself, and check it with the table.
- When everything is ready, build and show the site, all on the phone.
The phone does all steps by itself. No host that "serves the site" appears anywhere. The relay only gives the table, and Blossom only gives the bytes. They do not show the site. The site is built on the device at the end.
On a normal website, the server does this work for you: read the manifest, collect the files, and build the page. Bouquet just moves this work to the phone.
Actually, all of this is Nostr
I have used the word "relay" without explaining it. Relays come from Nostr.
If you do not know it: Nostr is a decentralized protocol for social apps. Instead of a domain or a company account, your identity is a key that you own. Your public key is your name. What example.com is for a normal website, a public key is for Nostr. The messages you sign with your key are stored and re-sent by relays, and anyone can run a relay.
Blossom is the file (media) storage that is often used with Nostr. It is the content-addressed storage I explained above: you give a hash, and you get the bytes.
In Bouquet:
- The owner of the site is one public key (the
npub1…string). - The table of contents is a message signed by that key, stored on relays.
Because of the signature, you can check that the table really comes from the owner, and was not swapped on the way. The contents are checked with the fingerprints in the table. So from the start to the end, you can verify everything by yourself, without trusting any host in the middle.
About NIP-5A
The data format (how a static site is placed on relays and Blossom) is defined by a spec called NIP-5A: the path-to-hash table, how the file contents are stored, and so on. Bouquet uses this format as it is, and does not add any custom event kinds or tags. The data it publishes is normal NIP-5A.
But here is one important thing. NIP-5A only describes one way to turn the data back into a site: run a host server and resolve it there. The rendering model that the spec assumes is the traditional one, with a smart host in the middle.
The main idea of this article (no host in the middle, and getting the table, getting the bytes, checking hashes, and building the site, all on the phone) is not written in the NIP-5A text. Bouquet moves this resolution step to the client itself, using only the data that the spec already defines.
So to be exact, Bouquet is not really "a NIP-5A viewer." It uses NIP-5A data as it is, but it replaces the host-based resolution (which the spec treats as standard) with host-less, client-side resolution. (I also proposed to add this as a section to the spec.)
How it actually renders
If there is no host in the path, what is the WebView loading? It is a small local server that the app runs inside the phone, only during the session.
After the files are collected and verified, Bouquet runs a small server on http://127.0.0.1 (the device talking to itself), and points the WebView to it. 127.0.0.1 never leaves the device, so there is no external host here either. When you close the site, the server also goes away.
What you get from this
When you remove the dedicated serving host, you get two concrete things. Both come from the same fact: relays and Blossom servers can be many, the table is verified by signature, and the contents are verified by hash.
It is hard to take down
On a normal website, if example.com's server goes down, you cannot see the site. That one server is a single point of failure.
A site through Bouquet does not have that one server. The table can be on several relays, and the contents on several Blossom servers. If one relay goes down, you can get the same table from another. If one Blossom goes down, bytes from another Blossom are fine, as long as the hash matches. There is no single box that ends the site when it dies. The site stays visible as long as one relay still has the table, and one Blossom still has each file.
It is strong against censorship and tampering
When there is a dedicated host, that host is the weak point. Push the operator, take the domain, or drop the subdomain. Any one of these can take the whole site offline. A host in the middle is a point that someone can control.
Bouquet does not have such a point. Everything is spread over many relays and Blossom servers, and anyone can start a new one. If you block one, people just get it from another route.
And because nothing is in the middle:
- Nobody can swap the content. The table is signed by the owner, and every file is checked by hash. So if someone tampers with the data on the way, the phone notices it and rejects it.
- It is harder to watch you. No single party sees your whole session. A relay you ask can know which site's table you wanted, and a Blossom you ask can know which file you got. But no single party sees the full picture.
Try it
The source and a demo are on GitHub:
