nostr.build on Nostr: Good question. They both use npub authentication, and have become a standard for ...

Good question. They both use npub authentication, and have become a standard for nostr media hosting. A big difference is that Blossom is a standard that allows a blossom comparable server to instantly integrate with the client making it easier for clients to interoperable with media servers, and users to create Blossom servers that instantly can integrate with clients. While nip96 focuses on one aspect of authentication, Blossom is more holistic encompassing more than just npub authentication. fishcake (npub137c…k37w) wrote a great blog going into more detail about our Blossom implementation.

quoting note12r9…ynmp

As many of you know, https://nostr.build has recently launched a new compatibility layer for the Blossom protocol [blossom.band](https://blossom.band). You can find all the details about what it supports and its limitations by visiting the URL.

I wanted to cover some of the technical details about how it works here. One key difference you may notice is that the service acts as a linker, redirecting requests for the media hash to the actual source of the media—specifically, the nostr.build URL. This allows us to maintain a unified CDN cache and ensure that your media is served as quickly as possible.

Another difference is that each uploaded media/blob is served under its own subdomain (e.g., `npub1[...].blossom.band`), ensuring that your association with the blob is controlled by you. If you decide to delete the media for any reason, we ensure that the link is broken, even if someone else has duplicated it using the same hash.

To comply with the Blossom protocol, we also link the same hash under the main (apex) domain (blossom.band) and collect all associations under it. This ensures that Blossom clients can fetch media based on users’ Blossom server settings. If you are the sole owner of the hash and there are no duplicates, deleting the media removes the link from the main domain as well.

Lastly, in line with our mission to protect users’ privacy, we reject any media that contains private metadata (such as GPS coordinates, user comments, or camera serial numbers) or strip it if you use the `/media/` endpoint for upload.

As always, your feedback is welcome and appreciated. Thank you!