nips/106.md

171 lines
5.5 KiB
Markdown
Raw Normal View History

2023-10-10 04:59:20 -04:00
# NIP-106 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
- Tamper-resistant through public key-based integrity
- Fault tolerance through deployment on multiple relays
- Resistance to blocking due to the distribution of web servers or clients
- Faster retrieval speed compared to IPFS's DHT
## Proposed Approach
Each HTML, CSS, and JS file is assigned a `kind` for identification.
- HTML: `kind: 5392`
- CSS: `kind: 5393`
- 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.
Example: `<link rel="stylesheet" href="066b7ca0b167f0adad5c6d619ab1177050423e3979e83b8dfa069992533bdcf5">`
### 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.
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.
**Implementation Example (Golang)**
```go
r.GET("/e/:nevent", func(ctx *gin.Context) {
nevent := ctx.Param("nevent")
// parse nevent
_, res, err := nip19.Decode(hexOrNevent)
if err != nil {
ctx.String(http.StatusBadRequest, "Invalid nevent")
return
}
data, ok := res.(nostr.EventPointer)
if !ok {
ctx.String(http.StatusBadRequest, "Failed to decode nevent")
return
}
id := data.ID
allRelays = append(allRelays, data.Relays...)
// Fetch data from nostr pool
ev := pool.QuerySingle(ctx, allRelays, nostr.Filter{
Kinds: []int{
consts.KindWebhostHTML, // 5392
consts.KindWebhostCSS, // 5393
consts.KindWebhostJS // 5394
},
IDs: []string{id},
})
if ev != nil {
// Return data with content-type adapted to kind
switch ev.Kind {
case consts.KindWebhostHTML:
ctx.Data(http.StatusOK, "text/html; charset=utf-8", []byte(ev.Content))
case consts.KindWebhostCSS:
ctx.Data(http.StatusOK, "text/css; charset=utf-8", []byte(ev.Content))
case consts.KindWebhostJS:
ctx.Data(http.StatusOK, "text/javascript; charset=utf-8", []byte(ev.Content))
default:
ctx.String(http.StatusNotFound, http.StatusText(http.StatusNotFound))
}
} else {
ctx.String(http.StatusNotFound, http.StatusText(http.StatusNotFound))
}
return
})
```
### 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.
- HTML: `kind: 35392`
- CSS: `kind: 35393`
- JS: `kind: 35394`
Identifiers must be included within the `d` tag.
**Example**
```json
{
...,
"kind": 35392,
"tags": [["d", "hostr-lp"]]
}
```
Moreover, internal links within the `content` should be assigned NIP-33 identifiers instead of event IDs.
#### Identifier Format
2023-10-10 05:04:21 -04:00
`[html_identifier][filepath]`
2023-10-10 04:59:20 -04:00
2023-10-10 05:04:21 -04:00
**Example:**
index.html: `hostr-lp`
assets/index-ab834f60.css: `hostr-lp/assets/index-ab834f60.css`
2023-10-10 04:59:20 -04:00
### Implementation on Web Server or Client
Events can be accessed through `/p/{author_hex}/d/{d_tag}`.
**Implementation Example (Golang)**
```go
r.GET("/p/:author_hex/d/*dTag", func(ctx *gin.Context) {
authorHex := ctx.Param("author_hex")
// Add authors filter
authors := []string{authorHex}
// Add #d tag to filter
dTag := ctx.Param("dTag")[1:]
tags := nostr.TagMap{}
tags["d"] = []string{dTag}
// Fetch data from pool
ev := pool.QuerySingle(ctx, allRelays, nostr.Filter{
Kinds: []int{
consts.KindWebhostReplaceableHTML, // 35392
consts.KindWebhostReplaceableCSS, // 35393
consts.KindWebhostReplaceableJS, // 35394
},
Authors: authors,
Tags: tags,
})
if ev != nil {
// Return data with content-type adapted to kind
switch ev.Kind {
case consts.KindWebhostReplaceableHTML:
ctx.Data(http.StatusOK, "text/html; charset=utf-8", []byte(ev.Content))
case consts.KindWebhostReplaceableCSS:
ctx.Data(http.StatusOK, "text/css; charset=utf-8", []byte(ev.Content))
case consts.KindWebhostReplaceableJS:
ctx.Data(http.StatusOK, "text/javascript; charset=utf-8", []byte(ev.Content))
default:
ctx.String(http.StatusNotFound, http.StatusText(http.StatusNotFound))
}
} else {
ctx.String(http.StatusNotFound, http.StatusText(http.StatusNotFound))
}
return
})
```
## 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>