Add Nostr Web NIPs — Decentralized Web Publishing via Nostr

[KarimHassan]

Nostr Web proposes a protocol-level approach for web decentralization by leveraging Nostr primitives By publishing HTML/CSS/JS as signed Nostr events and enable DNS discovery for these events

Implementation References
Publisher Tool: https://github.com/Shugur-Network/nw-publisher | npm

Browser Extension: https://github.com/Shugur-Network/nw-extention | Chrome | Firefox

Relay : https://github.com/Shugur-Network/relay (v1.3.5 introduces Nostr Web event compatibility)

Demo: https://nweb.shugur.com/

[luigi1256]

Why not use Static Websites? #1538

[KarimHassan]

Why not use Static Websites? #1538

Static Websites, is a well defined NIP provide a great and simple way to host static content through Nostr. However, Nostr Web focusing on developer experience, and user experience

Key characteristics of Nostr Web:

1- It built on bare nostr events.
2- End users access the websites browser extension to ensure decentralization.
3- Websites are integrated with DNS for discovery giving a familiar and native web experience.
4- Also nostr web provides version controlling, developers can publish, rollback , and manage multiple version of a single website.

[luigi1256]

ok, so in some ways it's more similar to brostr https://asaitoshiya.github.io/brostr/src/

[KarimHassan]

ok, so in some ways it's more similar to brostr https://asaitoshiya.github.io/brostr/src/

I have reviewed brostr, I belive it is general purpose event viewer capable of rendering "HTML, Long form content, Image", the browser extension "https://github.com/Shugur-Network/nw-extention" can be something like brostr but for websites only

brostr is more of an application, while nostr web is designed as a protocol standard, defining how publishing, versioning, discovering can work over nostr

the goal is to have a standard for web publishing and retrieval on nostr that lowers the barrier for both non-technical and web developers, making decentralized websites as intuitive as traditional ones.

• Each key pair represents a website and a replicable event represent the website entry point
• Each addressable event represents a version of the implementation
• Each mainfeast represent single page assets
• Each asset stored as a single event

[AsaiToshiya]

brostr implements NIP-106 similar to this PR. PR for NIP-106 is here.

[vitorpamplona]

Does DNS like stringified Json inside of it? I have always been told to avoid JSON inside DNS records at all costs. DNS Parsers and caching systems are just not made for heavy parsers like JSONs.

[KarimHassan]

Does DNS like stringified Json inside of it? I have always been told to avoid JSON inside DNS records at all costs. DNS Parsers and caching systems are just not made for heavy parsers like JSONs.

Hi vitorpamplona, your concern is valid but "Never put JSON in DNS” is too strong, for small, infrequently changing data, JSON in a TXT is fine, but we can modify it to be flat tokenized

ex. "v=1 pk=npub1... relays=wss://example.com,wss://example.com"

[vitorpamplona]

ex. "v=1 pk=npub1... relays=wss://example.com,wss://example.com"

That seems more aligned with DNS record standards. I suppose people already have good parsers for these things.