-
Notifications
You must be signed in to change notification settings - Fork 505
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NIP-XX Decentralized Web Hosting on Nostr #742
Comments
Event id is obtained by following structure. So if you change the content, IDs must be changed.
If you provide an original ID system (hostr-id) for hostr different from the ID on nostr, and put the hostr-id in note1, you may be able to access /e/hostr-id. If you rewrite content, you will want to rewrite note1 content (hostr-id should be written), so I think you should provide a kind in the range 10000 <= n < 20000. |
A note with |
My implementation (AsaiToshiya/brostr) uses NIP-21
NIP-19 is also fine, I think this is more unified and has more informative. |
Super nice!
The replaceable events idea only work for things the pubkey controls. It doesn't make sense for pubkey A's website to reference a pubkey B that has a jQuery in a replaceable event because that event can be independently changed to a scam script and it will be immediately live on pubkey A's website. Replaceable events should be used only to link files within the pubkey and, in that use case, the d-tag can then be a stringified file directory+name (
should be something like
I couldn't find where this proposal is changing the hash of
It doesn't make much sense because these types of events only offer 1 event per event type. There is no d-tag to differentiate them.
This makes more sense than hexes because it includes information that helps the webserver find the event in multiple relays. |
I think using NIP-21 is a great idea and should definitely be adopted.
Implementing replaceable events without affecting other sites is required. How about assigning public keys or similar to subdomains? While this will increase the implementation cost for web server administrators, who would need to specify subdomains using a wildcard, it can minimize the impact on other sites.
I don't think NIP-19 is a must, but from a usability perspective, it's worth considering thoroughly on the web server side. Therefore, I think it's okay to include it in the specifications. What do you think? |
The root problem is how to replace HTML content posted at a specific URL with different content that keep the same URL. Thus, you can't use note1 for the URL at least, I think. Right? |
Here's a cool thing. Deno is similar to Node, except you can import modules by URL. With this, it's possible to import JavaScript files hosted on Nostr directly into Deno code. So, you could use this not just for hosting websites, but for hosting libraries. Now, is it a good idea? Probably not, at least not yet. If web browsers (and Deno) added native support for Nostr URIs it would be more appealing. Even then I'm still not sure. It's experimental, and we're waiting for the gem to be uncovered. |
You can use a |
make sense. |
|
I didn't read it very carefully, so there may have been something I missed. |
Mostly because tags are case sensitive and we have had issues in other events (hashtags are a classic problem) when filtering for events of a certain type in all possible character cases. :( |
I agree that inserting the Content-Type into tags can make filtering more difficult, but such cases may be rare. Because most of the time, data is retrieved using the event id or d tag. I apologize if I've overlooked anything🙇♀. |
Something like a search engine using NIP-50 would be one use case. |
I'm with @frbitten on using tags to indicate file types instead of assigning kinds for each possible file type, especially if you have a vision for extending this proposal to allow hosting of arbitrary file types. The inconvenience of filtering is not a strong reason to use separate kinds for different file types, since there is no need for the ability to filter files by content type for web hosting, I think. We may make use of the |
I agree with the use of tags.
Search engine and other may want to search for only hosted HTML.
I am concerned that MIME types are case sensitive. |
For a web browser application, sure. But this isn't just for web browsers. I can do a js minifier Data Vending Machine and for that, I need to filter only JS and process them. Or maybe I do a JS to web assembly compiler. In both cases, one can injest the event type and create a new event (on a new type) with the resulting compilation. Different kinds also help storage systems easily pick what they want to store, which kinds they allow on their relays. An important distinction is between media and text Mine types. If we merge them as one type, relays will need to say things like "we support nip-xx/kind-Y, but only text ones in the x, y, z mime types". It becomes messy. Also, there is no shortage of event kinds. We can create as many as we want. |
I see. Being able to specify a 'kind' to differentiate the files that the relay accepts seems good, considering the versatility of this system. |
How about adding rule to The allow-list is essentially the same between kind and |
Ok. It's a valid reason. I don't know if it's enough, but I understand the option. So I suggest that NIP defines a range of allowed kinds and a list of each type and its respective kind. As we have NIPs that define kinds 10000, 20000, 30000, etc. So to avoid that in the future we have numbers of random kinds and having to make chains of IFs to support. It's a simple way to bypass relays that aren't interested in this feature. It might be interesting to use the NIP-94 in this idea. So I can make a "site" that uses part hosted on the relay and part hosted in other ways via NIP-94 that contains the external URL. |
@vitorpamplona What do you think about this?
We can keep unchanged |
That said, I think it is somewhat clear what MIME types this NIP supports. |
As in this example, if there is a relay that only hosts JavaScript, and if filtering is possible with the "kind" parameter, there is no need for additional feature implementation in the relay. However, defining "kind" for each Content-Type is not practical, so some level of selection or an alternative solution is necessary, I believe. |
We might not need a new kind for every mime/type. We just new kinds when there is a chance relays and clients can use that information to simplify their work. We can have these 3 types + the NIP-94/95/96/97 types (with the mime tag) for now. Maybe there are other mime types worth considering for their own kind, but we can leave that decision for later when the need arises. |
text files would not need to use NIP-95 or some variation. I think there could be a NIP to define a kind or tag to inform the format of what is in "content", it would be a generic solution for several uses. |
The problem with using I prefer |
Sorry, the link above to this is wrong. |
If we have one or two serious implementers of this idea, we should move it to a Draft PR. |
Based on the discussions we've had here, I'd like to propose the following changes and simultaneously work on their implementation:
Regarding the ongoing discussion about how to identify the MIME type of files, whether to use the Do you think it's okay to proceed with the above changes? If there are any further points to discuss or any aspects that we might have missed, I'd appreciate your input. |
What's this URL format switch? I am not sure what it is about. |
Based on your suggestion not to include OR in the specification, I'm considering changing it from |
Nice! Keep in mind that for |
Various implementations are possible, but must we follow the format of those URL?
We can also use
OK, but what do you think about the second sentence in #742 (comment)? |
There's no need for that. This is done to remove unnecessary complexity. In fact, my implementation also allows routing on npub.
Agree.
My understanding is insufficient, so is it possible for you to provide additional explanation? I'm sorry. My opinion is that it's better to use kind, which allows filtering by file type without making any changes to the relay. |
If we use kind, kind may inevitably change according to the result of the DVM, then we can't use I agree to use kind. |
Hi, I'd like to add one thing. To be able to create complete installable PWA we also need to support JSON files for the web manifest alongside the other formats (HTML, CSS and JS). From the NIP it seems to not be included, is it support somehow? Do we need to add it as a kind to the list? |
PR: #811 |
I posted my thoughts about Deno + this NIP here: denoland/deno#22779 It's been burning in my brain. Do you think kind Even among what the browser will accept, there are various formats, and it's still changing. Browsers now accept ESM when they didn't before, and they may accept TypeScript tomorrow. So I am tempted to have them all use the same kind, since runtimes that support them will treat them the same. |
Our consensus for now is separate event kinds for each MIME type. So, I think at least TypeScript needs to be use another kind. |
Decentralized Web Hosting on Nostr
By recording HTML, CSS, and JS on the Nostr relay, it becomes possible to create a decentralized web hosting solution that eliminates the need for centralized servers. Web servers or Nostr clients retrieve these recorded data, transform them into appropriate forms, and deliver them.
Reasons for Hosting on Nostr
Proposed Approach
Each HTML, CSS, and JS file is assigned a
kind
for identification.kind: 5392
kind: 5393
kind: 5394
The "content" field contains the content of the file. However, internal links (
href
,src
, etc.) referenced within should be replaced with event IDs.Example:
<link rel="stylesheet" href="066b7ca0b167f0adad5c6d619ab1177050423e3979e83b8dfa069992533bdcf5">
Implementation on Web Server or Client
Access events using
/e/{event_id}
. Since event IDs are specified for each internal link, opening an HTML file enables automatic retrieval of data from this endpoint.Implementation Example (Golang)
Replaceable Decentralized Web Hosting
Additionally, this proposal can be extended to incorporate the NIP-33 based decentralized web hosting specification. This allows tracking of website data with a single identifier, keeping URL paths immutable.
Following the NIP-33 specification, the "kind" would be as follows.
kind: 35392
kind: 35393
kind: 35394
Identifiers must be included within the "d" tag.
Example
Moreover, internal links within the "content" should be assigned NIP-33 identifiers instead of event IDs.
Identifier Example:
[html_identifier]-[filepath(replace '/' with a character that can be included in the URL path e.g. '_')]
Link Example:
<link rel="stylesheet" href="hostr-lp-_assets_index-ab834f60.css">
Implementation on Web Server or Client
Events can be accessed through
/p/{npub_or_hex}/d/{d_tag}
.Implementation Example (Golang)
Web Server Implementation Vulnerabilities
The current web server implementation allows access to websites within a single domain. While this reduces the implementation complexity on the server side and provides resilience against blocking, it is not suitable for use with domain-based authorization systems (such as NIP-07). For instance, if signing is permitted for Nostr clients on the web hosting relay, it would grant permission for all web pages hosted on that relay, making it vulnerable to spam postings.
Implementation
Repository: https://github.com/studiokaiji/nostr-webhost
Example Implementation: https://h.hostr.cc/p/a5a44e2a531efcc86491c4b9a3fa67daee8f60c9d2757a12eed95d98c5d6fc42/d/hostr-lp
The text was updated successfully, but these errors were encountered: