hzrd149 on Nostr: 1. Because the npub1 and other bech32 encoded strings are only intended to be used ...
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 )
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 )