nips
nips copied to clipboard
nostr-protocol
Static Websites
This nip defines a spec for hosting static websites under a pubkey using kind 34128 events, Blossom servers, and specialized host servers
Readable version here
Implementations:
I would just remove the word nsite from the title because it feels like you are defining a new NIP-19 bech address.
The rest is good.
I feel like this is better specified as a BUD since it depends on Blossom and Blossom is not even a NIP.
I feel like this is better specified as a BUD since it depends on Blossom and Blossom is not even a NIP.
I could go either way on this, but I think its closer to nostr since the majority of this NIP is the static file event for mapping path -> hash
The same can be said about Blossom.
And I do feel like Blossom should be published as a NIP somehow.
How is this done in comparison to the way npub.pro works for hosting nostr sites?
How is this done in comparison to the way npub.pro works for hosting nostr sites?
npub.pro from my understanding is mostly a client-side app. it it has website templates and make relay connections to fetch data
This on the other hand is more generic and lets users define a folder structure of files that they want to serve as their "website"
I like the idea, but don't like the fact that I'd have to create a new key for each website - or maybe the NIP should be renamed to Static Websites for Pubkeys.
I also think prescribing npub-subdomain resolution is unnecessary - I imagine any domain name could be used with target npub pre-configured on the server, the prescription looks like an unnecessary constraint.
Scoping the website to a single pubkey keeps it much simpler for other devs to implement servers and clients. I'm fine with renaming it if you think it makes sense though
I also think prescribing npub-subdomain resolution is unnecessary - I imagine any domain name could be used with target npub pre-configured on the server, the prescription looks like an unnecessary constraint.
My initial idea was to try and ensure most off the nsite servers where implemented in a similar way, but the more I've used it I don't think it matters much and ill update it to just be a recommendation of how a server could be implemented
I'm fine with renaming it if you think it makes sense though
It's a pretty important limitation (which makes things very simple, I agree), so putting it in the name would make it obvious from the start.
@nostrband @fiatjaf I have updated the NIP to remove the requirements in the "resolving pubkeys" section and replaced it with a recommendation for using npub subdomains
This should allow for multiple types of host servers that serve static sites based on NIP-05, hard-coded pubkeys or anything else
Chiming in to add our implementation: https://gitlab.com/soapbox-pub/nous-cli (cc @alexgleason)
Awesome work @hzrd149 👏
These are also my implementations: https://github.com/sepehr-safari/nostr-deploy-server https://github.com/sepehr-safari/nostr-deploy-cli
Folks can deploy their static apps on nostrdeploy.com with a single command:
npx -y nostr-deploy-cli deploy --skip-setup
Can a NIP-05 provider support name.example.com address so people can host nsites on them?
For example: kehiy.nostr.eco can be my nsite.
@kehiy — so, iiuc, the spec doesn't actually specify how the gateway should resolve identifiers. It simply specifies how files for a given pubkey should be resolved. If a gateway (which you'd probably run on nostr.eco) chose to resolve nip-05s subdomains then it could query the 34128 events and display the site. (@hzrd149 pls correct me if I'm wrong.)
@kehiy — so, iiuc, the spec doesn't actually specify how the gateway should resolve identifiers. It simply specifies how files for a given pubkey should be resolved. If a gateway (which you'd probably run on nostr.eco) chose to resolve nip-05s subdomains then it could query the 34128 events and display the site. (@hzrd149 pls correct me if I'm wrong.)
Yes, the spec intentionally does not proscribe a specific way to resolve pubkeys. there maybe some merit in having a standard (npub subdomains) but its not important for this NIP since it only covers how files should be mapped under a pubkey
As an example my nsite-gateway server can resolve pubkeys via, npub subdomain, whitelisted NIP-05 providers, CNAME dns records and TXT dns records
How should we deal with relay rate limits? I'm running into this problem with NostrDeploy.com—imagine thousands of page views across different npub*.nostrdeploy.com subdomains in a short period, each one making multiple requests to relays! It ends up behaving like a DDoS attack!
How should we deal with relay rate limits? I'm running into this problem with NostrDeploy.com—imagine thousands of page views across different npub*.nostrdeploy.com subdomains in a short period, each one making multiple requests to relays! It ends up behaving like a DDoS attack!
The relays themselves don't need to be used as index servers. the host server should probably keep a cache of pubkey + path -> sha256 so it can quickly resolve requests without needing to query 3-4 relays every time
I love the idea of local gateways. Like a Nostr client that resolves the static website locally and render it on a local browser. But I don't like to always specify I'm looking for the static website behind this npub, So I think a nsite NIP-19 entity with some relays and blossom servers encoded into it will be great!
Much more important than npub-addressable websites (which are just a poor man's DNS) are nevent-addressable websites, which are static and not under the control of that pubkey owner, thus can be more useful in many ways.
Can we add that to this spec? How hard would it be to change the existing tooling to support such things? Or are these things better in a different spec?
nevent-addressable websites
Sounds like a good idea, would it be also a good idea instead of having an event per-path could we just have 1 event per directory/site and have tags for all the paths?
Each build of the static site should be linked to the same index root, i dont think there is any reason to have each path replaceable since we use the hash of the files anyway, the same info could just be saved in the site index event
It would also be much better if the tooling could just rewrite the links during bundling to use the full sha-256 hash of the files so it could be served directly off blossom servers, the only thing needing gateways are the html pages, or at least the gateway could serve a redirect instead of the file itself.
Sounds like a good idea, would it be also a good idea instead of having an event per-path could we just have 1 event per directory/site and have tags for all the paths?
Each build of the static site should be linked to the same index root, i dont think there is any reason to have each path replaceable since we use the hash of the files anyway, the same info could just be saved in the site index event
Yes, please, definitely. I didn't know the standard above (sorry, I didn't read very carefully) required a different replaceable for each file, that sounds crazy to me. Is there a reason for that?
It would also be much better if the tooling could just rewrite the links during bundling to use the full sha-256 hash of the files so it could be served directly off blossom servers, the only thing needing gateways are the html pages, or at least the gateway could serve a redirect instead of the file itself.
Yes, I agree. I think I suggested this to @hzrd149 but I don't remember his reasons for not doing it.
Well, this would mean that we wouldn't even need any Nostr tooling to serve a website, as long as you knew the hash of the index and you used a blossom server for that the browser would automatically use that same blossom server to fetch all the other assets. So this could just be a BUD instead of a NIP.
After that if you want you can just have a thin NIP on top of it that allows an npub to declare its websites like
{
"pubkey": "<...>",
"kind": 10079, // main/root npub website
"tags": [["x", "<hash>"]]
}
or
{
"pubkey": "<...>",
"kind": 30079, // named website
"tags": [["d", "<name>"], ["x", "<hash>"]]
}
It would also be much better if the tooling could just rewrite the links during bundling to use the full sha-256 hash of the files so it could be served directly off blossom servers, the only thing needing gateways are the html pages, or at least the gateway could serve a redirect instead of the file itself.
It would be a huge lift to update tooling to start rewriting or outputting paths using the hash of the file instead of a filename. also there is an issue of circular references that cant be fixed without introducing a map
It would also be much better if the tooling could just rewrite the links during bundling to use the full sha-256 hash of the files so it could be served directly off blossom servers, the only thing needing gateways are the html pages, or at least the gateway could serve a redirect instead of the file itself.
It would be a huge lift to update tooling to start rewriting or outputting paths using the hash of the file instead of a filename. also there is an issue of circular references that cant be fixed without introducing a map
I dont think so, most bundlers support changing the chunk names, although it would be kinda awkward to have a different build config for nsite, or you just use the same config for both.
Rollup: https://rollupjs.org/configuration-options/#output-chunkfilenames
It would also be much better if the tooling could just rewrite the links during bundling to use the full sha-256 hash of the files so it could be served directly off blossom servers, the only thing needing gateways are the html pages, or at least the gateway could serve a redirect instead of the file itself.
@v0l I would not call that "better." Right now, as is, to deploy an nsite requires no modification to your bundles. It can deploy any SPA as-is. This suggested change adds unnecessary complexity. This suggestion is a fundamental change that goes against not only well-established tooling for this nip, but is an anti-pattern to SPAs. IMO "better" would mean "simpler," and path-based resolution is significantly "simpler" and "better" than post-processing a bundle with hashes and many orders of magnitude "better" than replacing the paths with statically defined blossom server + hash paths; not to mention much less of a headache, easier to write gateways and easier to produce nsites.
A single event for all files fixes the relay rate-limiting issue on publish, but presents new issues for tag lengths with large sites. They both have issues. I personally prefer one large event.
I don't know why you needed to "write" so much, it clearly would be "better" if you could just serve your site directly form blossom, since that is the "simplest" solution.
Its only a "simple" solution if it can be "implemented" trivially via build tooling.
@v0l sorry to have offended you with what I thought was a complete expression of my opinion as someone who has contributed to nsite for longer than 2 weeks.
The blossom-only website idea is interesting, and it's so simple it doesn't even need a BUD. However, as a web user I like to see in the location bar which site, and which part of it I'm looking at, so in my view it has limited usability.
On the classic mapped nsites, the tooling is quite vested in the one event per path model, but you're right, the one event per site idea makes sense. For nevent-, and also for npub-addressed sites. It limits the number of files to ~2000 at a 128k event size, which is enough for most sites. Serving the site for the first time would be snappier because of less round-trips, and atomic updates would be possible for whole sites.
