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.