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.
reply
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.
reply