I'm glad to see that people are looking into this use-case for Nostr.
I haven't read beyond the README, so maybe this is an already answered question. But, does this software post SPAs to multiple relays? If so, does it handle relays that go down? I ask, because I have a draft NIP for that (and more), and I'm interested in any other ideas out there.
If you're going to run this, why not just run a webserver to deliver your SPA?
If you're not into running any of it and just want to use other peoples servers, how is deploying over nostr an improvement vs any other web publishing method?
You're still beholden to their namespace if the goal is visibility, and even if not you can use redundant hosts just as you would use redundant relays.
I think this would be more useful for widgets in other nostr apps, but then I think that might be an XSS nightmare.
I understand your reasoning and I agree with you on all your concerns.
The main focus of this project is to show a proof of concept for a proposed NIP for hosting content within nostr.
For that reason it inherit all the pros and cons of nostr itself like discoverability, ownership, etc., but if you think of this as a simple client for a specific type of events it should make more sense in it's purpose.
I too see this more as a way of sharing standalone content closer to something like neocities rather than a proper web hosting service, especially since it only works with static files.
In the future nostr clients could consume those type of content directly to serve some kind of customized project or user pages, maybe with some built-in code editor too.
There's also a run to build a "GitHub replacement" implement using the nostr protocol, a similar "GitHub Pages" within nostr doesn't sound too bad either.
Pages are an interesting concept I've toyed with before and plan to again. I think a much more useful thing than fake twitters. The running of arbitrary scripts though seems hectic...
A nostr page builder that just uses it for data makes sense, but the rendering server has to provide the templates. Perhaps the template preference can be verifiably attested.
As I said, it's a proof of concept, but to me it's pretty much there already.
What I think could make it work much better is to have a layer that treat those event/files as pure text content like how it handled the rest since now and inject them in a iframe or similar (like with BlobURLs), then you won't even need a server for serving them, a simple JS script would let you build all the widget, clients or whatever you need anywhere you want.
From what I've seen you can use only html, you can probably put css and js in it but it's not the best way to make a website or web app.
It from the source code of nostrsite It also seem to manipulate the html to inject code from CDN, and they are behind a pro plan, not a bad thing per se, but you're limited with what you're allowed to use.
What is bad though is that it uses kind: 1 for the code. It'll spam the feed on normal clients with HTML note on the relay.
With a terminal client you can take a folder of a static website or app (made only with HTML, CSS and JavaScript) and store those files as notes on some relays, the webserver then fetch those notes and show them as files the browser show as a website using said nostr relays as storage.
You can also host a webserver yourself using the source code.
It's written in Go and it's pretty simple to read, it also include an example config file for the nostr relay (nostr-rs-relay) so you can host it yourself.
I'm not, but I'm really interested in this project.
If you search for "hostr.cc" in the global feed in nostr you can see other examples.
I'm planning on using it pretty soon myself.
What I'm looking for is a way to deploy progressive web apps (PWA) that also need images and JSON files under the same domain to register a service worker to work properly enabling offline apps too.
I plan on contributing in the code if it doesn't support it out of the box.
Sure, I'm following the project and it's still defining a proper reference for the notes, for a PWA the only missing bit is the JSON type. I've discussed with the developer about the kind logic and its logic is to have specific format you can share separately, except for that it should already work.
The only limitation for now should be the installable part for the manifest, I need to check this myself.
fetch()your content from elsewhere via JavaScript using an JSON API.