nostr-protocol
Add Nostr Web NIPs — Decentralized Web Publishing via Nostr
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/
Why not use Static Websites? https://github.com/nostr-protocol/nips/pull/1538
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.
ok, so in some ways it's more similar to brostr https://asaitoshiya.github.io/brostr/src/
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
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"
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.
