mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-12-23 00:45:53 -05:00
copy edits
This commit is contained in:
parent
9376effa56
commit
903026664d
22
106.md
22
106.md
|
@ -2,16 +2,16 @@
|
||||||
|
|
||||||
`draft` `optional` `author:studiokaiji`
|
`draft` `optional` `author:studiokaiji`
|
||||||
|
|
||||||
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.
|
Storing HTML, CSS, and JS on Nostr relays makes it possible to create a decentralized web hosting solution that eliminates the need for centralized servers. Nostr clients, including web servers, can retrieve stored data and transform it into the appropriate form for the application.
|
||||||
|
|
||||||
## Reasons for Hosting on Nostr
|
## Reasons for hosting on Nostr
|
||||||
|
|
||||||
- Tamper-resistant through public key-based integrity
|
- Tamper-resistance due to public key-based signatures
|
||||||
- Fault tolerance through deployment on multiple relays
|
- Fault tolerance through deployment across multiple relays
|
||||||
- Resistance to blocking due to the distribution of web servers or clients
|
- Resistance to blocking due to the distribution of web servers and clients
|
||||||
- Faster retrieval speed compared to IPFS's DHT
|
- Faster retrieval speed when compared to IPFS's DHT
|
||||||
|
|
||||||
## Proposed Approach
|
## Kinds and References
|
||||||
|
|
||||||
Each HTML, CSS, and JS file is assigned a `kind` for identification.
|
Each HTML, CSS, and JS file is assigned a `kind` for identification.
|
||||||
|
|
||||||
|
@ -19,13 +19,13 @@ Each HTML, CSS, and JS file is assigned a `kind` for identification.
|
||||||
- CSS: `kind: 5393`
|
- CSS: `kind: 5393`
|
||||||
- JS: `kind: 5394`
|
- JS: `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.
|
The "content" field contains the content of the file. However, internal links (`href`, `src`, etc.) referenced are replaced with event IDs of the `nevent` form.
|
||||||
|
|
||||||
Example: `<link rel="stylesheet" href="nevent1qqspvj8cqt3fhlqwgg26nmhvpppauu3yduj4qtm4vh2lumm9q8cflnspzdmhxw309ucnydewxqhrqt338gmnqvp3qyg8wumn8ghj7u3wdphhxarj9e3kxq3q5kjyu2jnrm7vsey3cju687n8mthg7cxf6f6h5yhwm9we33wkl3pq3jl24r">`
|
Example: `<link rel="stylesheet" href="nevent1qqspvj8cqt3fhlqwgg26nmhvpppauu3yduj4qtm4vh2lumm9q8cflnspzdmhxw309ucnydewxqhrqt338gmnqvp3qyg8wumn8ghj7u3wdphhxarj9e3kxq3q5kjyu2jnrm7vsey3cju687n8mthg7cxf6f6h5yhwm9we33wkl3pq3jl24r">`
|
||||||
|
|
||||||
### Implementation on Web Server or Client
|
### Implementation on Web Server or Client
|
||||||
|
|
||||||
Access events using `/e/{nevent}`. Since event `nevent` are specified for each internal link, opening an HTML file enables automatic retrieval of data from this endpoint.
|
Events are accessed using `/e/{nevent}`. Since an event is specified for each internal link, opening an HTML file enables automatic retrieval of data from the appropriate endpoint.
|
||||||
|
|
||||||
By using `nevent`, you can expedite the retrieval of relay information by including it internally, which offers the advantage of speed. However, it is also acceptable to implement the retrieval in the usual hex format as an option.
|
By using `nevent`, you can expedite the retrieval of relay information by including it internally, which offers the advantage of speed. However, it is also acceptable to implement the retrieval in the usual hex format as an option.
|
||||||
|
|
||||||
|
@ -83,7 +83,7 @@ r.GET("/e/:nevent", func(ctx *gin.Context) {
|
||||||
|
|
||||||
### Replaceable Decentralized Web Hosting
|
### 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.
|
Additionally, this proposal can be extended to incorporate decentralized web hosting according to the NIP-33 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.
|
Following the NIP-33 specification, the `kind` would be as follows.
|
||||||
|
|
||||||
|
@ -163,7 +163,7 @@ r.GET("/p/:author_hex/d/*dTag", func(ctx *gin.Context) {
|
||||||
|
|
||||||
## Web Server Implementation Vulnerabilities
|
## 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.
|
The current web server implementation allows access to websites within a single domain. While this reduces server-side implementation complexity 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
|
## Implementation
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue
Block a user