Do you mean git blob hash?
That was nostr:nprofile1qqs8qy3p9qnnhhq847d7wujl5hztcr7pg6rxhmpc63pkphztcmxp3wgpz9mhxue69uhkummnw3ezuamfdejj7qgmwaehxw309a6xsetxdaex2um59ehx7um5wgcjucm0d5hsz9nhwden5te0dehhxarjv4kxjar9wvhx7un89uqaujaz original NIP-62 idea, but it got slapped down because everyone wanted the commit content in events. And now they're creating Blossom blobs that are copies of the git blobs, or something.
yeah, i think the commit hash in the events and that refers to a blob hash that is stored in blossom is the way to go
the thing is that i don't think Git uses sha256, so you'd have to have a variant of blossom that uses whatever hash it is... md5? idk 😕
git seriously needs to be upgraded as a protocol, to be honest... it was SHA1, i remember now...
SHA256 is already supported
ok so that means that you can store the nodes in events and refer to blobs to fetch them
blossom imo as a protocol is garbage, as it tries to consolidate management (upload/delete/list) with retrieval of blobs
it is a big pain in the ass for scaling, look at any service and you will see cdn domains are separate from upload
blossom also makes no attempt to allow media optimization, and I believe it is an acceptable tradeoff to sacrifice integrity for reduced data usage if you can turn it off as needed
blobs should be identified by nostr event IDs, meaning you get metadata for free, and if a user wants their blob gone, they can issue a delete event and send it to all hosts
rehosting content becomes an explicit action
Yeah because it doesn't make sense to rebuild git servers from scratch out of Nostr events when we already have git servers.
I like nostr:nprofile1qqsyeqqz27jc32pgf8gynqtu90d2mxztykj94k0kmttxu37nk3lrktcpz9mhxue69uhkummnw3ezuamfdejj7qg3waehxw309ahx7um5wghxcctwvshsz9nhwden5te0d4kx26m49eex2ctv0yhxcmmv9ume3twc idea of using ephemeral events, but I'd maybe do it a bit differently.
Yeah ephemeral events for synchronizing state is a good use of Nostr's event-driven nature.
