Static Websites #1538
Static Websites #1538
Conversation
|
I would just remove the word 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 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? |
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
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 |
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 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: Folks can deploy their static apps on nostrdeploy.com with a single command: |
|
Can a NIP-05 provider support For example: |
|
@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, |
|
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 |
|
Built a gateway in rust https://nwb.tf/ |
|
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? |
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. |
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? |
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 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 |
@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. 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. |
@lez @dskvr I have a new version of this NIP locally that is built around the single event. its so much simpler and fixes many issues I've been having with nsite-gateway with resolving paths. are you guys fine with me pushing the updated version here? MIO The single event approach is the way to go though. it enable URLs like |
|
I guess it's nice to have reference to the obsoleted version.
Do you mean named nsites? That would be awesome. |
12 participants
This nip defines a spec for hosting static websites using site manifest events
15128and is a replaceable event per pubkey and serves as the root site for the pubkey.35128and have a d tag containing the site identifier. These are smaller websites under a pubkey and can be thought of as sub-domains.Readable version here
Implementations:
Legacy readable version
Legacy Implementations: