Oddbean new post about login | logout 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 @florian for building the cli tool
Oh cool; didn’t know about the CLI tool!
we have been conspiring in a telegram group :)
Is the group public or should I ask the French intelligence for access?
I thought you where already part of the French intelligence... if not you can use this link https://t.me/+Ho8zFD8QId01MmMx
Putain de merde!
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 @Lez 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.
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 @brugeman 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...) @Paul nostr:naddr1qvzqqqrcvgpzp22rfmsktmgpk2rtan7zwu00zuzax5maq5dnsu5g3xxvqr2u3pd7qyt8wumn8ghj7mnfv4kzumn0wd68yvfwvdhk6tcpz9mhxue69uhkummnw3ezumrpdejz7qqddpuhqetjdehhgefdde5hqyzzlyx
I might be very wrong on this. Only just learned what a static site is exactly #noob
👀👀 nostr:nevent1qqspswxa9m3l29ywq66kg58w7et6sw02gjw3qv4xklxpcycqlw0ajeqprfmhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5hsygpxdq27pjfppharynrvhg6h8v2taeya5ssf49zkl9yyu5gxe4qg55psgqqqqqqslj9zft
cool mad science, you may be interested in : https://dnstr.org/
cool, but now sure why this is necessary. couldn't we just use the "name" field in the kind 0 as the pubkeys domain?
you could, but then you are overloading one field to do two things, which is a trade-off, some systems may get confused
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 )