Read through it. I don't think it covers the same use-case that #Blossom dose
This looks like a good way for clients to load blobs and verity the contents. although it dose not cover re-uploading blobs or censorship resistance
Discussion
how does it not cover censorship resistance? You can specify multiple gateways. I haven’t looked at blossom yet, is there a spec somewhere?
Cc nostr:npub13v47pg9dxjq96an8jfev9znhm0k7ntwtlh9y335paj9kyjsjpznqzzl3l8
for blossom, users could publish a k:10063 event that defines the current list of media servers they are using.
https://github.com/hzrd149/blossom/blob/master/Nostr.md#user-server-discovery
This NIP could probably use the same event for getting a users gateways instead of hard coding them into the nblob string
Needing a note is the biggest downside here though, since now you require two lookups. I like nostr:npub13v47pg9dxjq96an8jfev9znhm0k7ntwtlh9y335paj9kyjsjpznqzzl3l8's since the nblob is self contained and has all the info you need.
It’s so simple that it technically could be a spec outside nostr itself. blobs and stuff transmitted over relays? #blobstr?
I do like the nblob encoding. but for the k:10063 events, I imagine clients would only use it if the URI or URL failed to load. so the censorship resistant part would only come into play if its been taken down