Making progress http://nsite.nostrudel.ninja
This is a version of noStrudel that is hosted on blossom servers ( deployed with nsite-cli ) and hosted from http://nsite.lol ( running nsite-ts )
Thanks to nostr:npub1klr0dy2ul2dx9llk58czvpx73rprcmrvd5dc7ck8esg8f8es06qs427gxc for building the cli tool
Oh cool; didn’t know about the CLI tool!
What's Nsite?
hopefully a new NIP. but its static web sites stored on blossom servers and nostr. then serve ( and cached ) from a central server
nostr:npub1elta7cneng3w8p9y4dw633qzdjr4kyvaparuyuttyrx6e8xp7xnq32cume built an MPV of it in SEC-02 https://github.com/lez/nsite
Oooooh 👀👀👀👀
I have a use case for this 👌
Really enjoy the concept that each npub can have its own website no matter the domain name.
This also means going beyond just sha256 and now refer to filenames under a tree structure on that npub (virtual) folder. So we'd look up the most recent sha256 on that path with the same name.
There is the problem of the server side tampering the output, so I guess there would be note from the npub working like a recipe and detail all sha256 that belong to the most current snapshot so we can verify.
If clients or users want to verify that the file has not been tampered with then they could easily fetch the events themselves and check that the hash matches what was sent from the server
It's a way to put a website on NOSTR. The nsite web server takes an npub and pulls all the web content from relays and blossom servers.
1. Is this in any way related to what nostr:npub1xdtducdnjerex88gkg2qk2atsdlqsyxqaag4h05jmcpyspqt30wscmntxy is doing with npub.pro?
2. Awesome! This is laying the groundwork for Hypernotes (widgets, stories, ...), if I get right. Which is more or less this but with limits on it (no non-Nostr communication, standard pixel sizes, etc...) nostr:npub1p4kg8zxukpym3h20erfa3samj00rm2gt4q5wfuyu3tg0x3jg3gesvncxf8
nostr:naddr1qvzqqqrcvgpzp22rfmsktmgpk2rtan7zwu00zuzax5maq5dnsu5g3xxvqr2u3pd7qyt8wumn8ghj7mnfv4kzumn0wd68yvfwvdhk6tcpz9mhxue69uhkummnw3ezumrpdejz7qqddpuhqetjdehhgefdde5hqyzzlyx
I might be very wrong on this. Only just learned what a static site is exactly #noob
cool mad science, you may be interested in :
Hello, was reading the specs at https://github.com/hzrd149/blossom
I'm now implementing the protocol, in fact was already using it in similar fashion anyways since it is practical to serve files so thank you for defining this neatly.
Have a few questions if you see possible to answer.
1) why use the hexadecimal for npubs instead of the traditional npub1...? I ask because it is easy/fast for me to find the user account but like this seems I'd have to extra CPU to get the value
2) I understand we identify the sha256 file hash with the user npub so that he can request to delete the file and we can identify how many files a user is uploading among other similar operations. Is that correct?
3) how can we advertise the files in our server to other servers? Right it will use the user-appointed servers but I'm imagining the scenario of searching across the +400 nostr servers today for a specific file hash. I know we can ping them all individually (and we will) but bandwidth and CPU are expensive, if servers can advertise their files then it is easier to balance the load across different servers or automatically go to the ones that report having that file.
Thanks!
1. Because the npub1 and other bech32 encoded strings are only intended to be used for displaying in the UI. also I was following the requirement in NIP-01 where all keys are required to be hex https://github.com/nostr-protocol/nips/blob/master/01.md?plain=1#L138
2. Yes, The file is addressed by its sha256 so users can delete it later or request the same file from multiple servers ( if they uploaded it to multiple )
3. This is where nostr comes in. If users want to advertise their file or find it later they can publish 1063 events or search for the sha256 in kind 1's
I modeled the servers after nostr relays. so by default they don't advertise what files they have. Initially this looks like an oversight but it allows servers to be much more flexible
For example, servers could advertise on the bittorrent dht. or by publishing nostr events. or publishing a massive JSON file. or they could listen for nostr request events ( like DVMs do )
Thank you. That made it more clear, will follow the protocol on our server soon to be published.
