Nostr

Nostr and IPFS get compared constantly, usually as rivals. They are not. They answer two different questions, and an application that needs both answers needs both protocols — or something that plays each part. Nostr answers “who said what, and when.” Its unit is a signed event. IPFS answers “what are these bytes.” Its unit is content-addressed data. That difference is worth getting straight, but it is not the interesting part. The interesting part is that both protocols are decentralized by design and neither is automatically decentralized by deployment, and the ways each one collapses back toward a single point of failure are mirror images of each other. IPFS falls over on the gateway and the pin; Nostr falls over on the relay. Both are deployment choices that inherit the protocol’s good name without inheriting the property that earned it. ...

Three systems name data three different ways, and the names get compared far more often than they get computed. This article builds a small Python tool that emits all three identifiers for one twelve-byte input, so you can see exactly where they agree and where they do not: a Nostr event id — the SHA-256 of a canonical serialization of a signed event an IPFS CIDv1 — a SHA-256 digest wrapped in a version, a codec, and base32 a Blossom hash — the same SHA-256, bare Two of those three turn out to be the same 32 bytes wearing different amounts of clothing, which is hard to believe from a table and obvious from a terminal. ...