Unlike traditional federated systems, Nostr is built around a protocol where users have a single cryptographic identity not tied to any particular server. This means that when a user shares a post, anyone with a Nostr client can interact with it—like, comment, or repost—regardless of which relay (server) they are connected to, solving the “can’t interact across instances” problem.
Moreover, Nostr posts are identified by content hashes and public keys, not by server-dependent URLs. This makes posts portable and resilient: if a relay goes offline or a user migrates, their content and identity remain intact and accessible via other relays, addressing the “post portability pain” and “migration pain” described in the article.
And because Nostr clients can register themselves as handlers for Nostr-specific links (e.g., nostr: URIs), clicking a Nostr link can automatically open the post in the user’s preferred client, improving the user experience across different devices and apps.
IPFS's DHT is extremely slow by the way - on the order of 1-10 minutes to look up a new item. That's one of those things about it that the people who insist it's the solution to all problems won't tell you. I assume there's some such problem with nostr too (probably not the same one). Every system has them.
Has nostr experienced a takedown, crash, corporate takeover, or overload of one or several major relays yet, and if so, how did that go? Did enough users find out about the problem through out-of-band channels, then manually enter new relay URLs, to keep the network mostly connected? Has anyone important had their private key stolen?
You're right about the fact that IPFS never could scale to the level of Social Media with everyone posting even 10 messages per day, but decentralized systems NEVER DO scale in that way. That's why Blockchain has Lightning as you know.
However inventing a NEW CID format in the IPFS era is a foot shoot, that can be avoided, and should be. Can the other problem (of how to push data efficiently) ever be solved perfectly? Maybe or maybe not, but Nostr does work, and it is censorship resistant better than anything else. I'm just saying what a shame that it's wholly separate from IPFS. That was a huge lost opportunity. And I generally disagree with your gripe that everything is worthless until everything is perfect, because by that logic even Public Key encryption is a baby to be thrown right out with the bath water too. No, the overall system will be made of parts. The CID part is a necessary part, and the PublicKey identity is also a necessary part.
BTW IPFS CID isn't even the best, oldest or most stable identifier. We had SHA256 hashes before IPFS.
About IFPS hashing... I'm a very experienced IFPS developer myself (2 years of it). I always argued the 'variable hash algorithm' aspect of IPFS was just an unnecessary complexity and that SHA256 should've been hard-coded into the whole thing. As per usual, the IPFS team went with the more complex approach, just like they did when they over-engineered ATProto in the same way by the SAME developer.
But the main reason Nostr cannot fit into IPFS is slightly more nuanced than the actual hash algo. Fiatjaf made the decision NOT to take the hash of the FINAL JSON object itself, and so no matter what hash algo he had used, it was never going to cleanly fit into IPFS without each Nostr message being 'wrapped' with some IPFS wrapper, necessarily resulting in an DIFFERENT hash. So there's two different layers to the incompatableness.
EDIT: Going deeper into the weeds: If social media messages are shorter than 256K (the default chunker size of IPFS) I think you can end up getting a SHA256 directly out of it, so there WAS the potential to use IPFS with Nostr in that way, except for the fact that Fiatjaf didn't hash the FINAL JSON, but hashed parts of it.
I remember Jeromy and his boss Cake who pretended to interview me for a job once, which cratered when I refused to do the "coding challenge" purely out of the principle of the thing. lol.
Unfortunately the guy who created Nostr wasn't an IPFS fan, and the IPFS guys who played the key role in developing Blue Sky weren't fans of simplicity like the Nostr dude was. So we ended up with a mess, where there could've been a big synergy.
And to make matters even worse everyone in the ActivityPub world (i.e. Fediverse, Mastodon,et all) is of the opinion that having a DNS name embedded into Usernames is congruent with freedom of movement and censorship resistance, even though it's not.
In fact, most of the Fediverse is full of super-woke types who love censorship as much as antifa loves the color black, so they're a hopeless cause as well. So once again, what a mess.
We were so so close. I mean even one slight tweak of how the Nostr Hash is generated COULD HAVE made it's message hashes genuine IPFS CIDs and made everything perfectly interoperable. No one to this day has gotten it right yet, but we're close.
As for getting all devices to work, entering a 66 byte hex key into each device is totally fine imo too. I mean, you can even let people generate their Private Key from a Password string if ya want.
Nostr isn't flawed in those two ways. It's KISS in those two ways.
"Nor will I" seems a bit strong here. This pain point seems rather self-inflicted, is it not? You get what you pay for and the ownership model of the Fediverse is you help pay for your instance (or instances). If you want ownership of your posts, become an owner of your instance.
That's one of the big reasons why I trust the Fediverse a lot more than AtProto. BlueSky is VC funded and the ownership model is hard to define and the business model is "ads now, maybe worse ads tomorrow". With the Fediverse I can own my instance like I can (and do) own my blog. I myself am not an ad company and I don't have to worry about future me injecting increasingly worse ads into my instance (and I'm free to block and defederate instances that think spam is a good idea).
You get what you pay for, and I'm happier to pay for a tiny corner of the Fediverse than try to be a sharecropper in AtProto with the possibility that Maybe Someday TM it will be distributed enough to matter (to avoid BlueSky's business model).
sambroner•9mo ago
Example: you open the app and load a specific document. Simplified, but this loads a "boot loader" and connects to the data feed of the document. The boot loader reads the first few operations which contains the widget/app code to load all the UX of the application. Examples of widgets would be a whiteboard, a text editor, a table widget, an identity card, a latex widget, etc.
Widgets could be posted outside of the document because any loader that could read the URI could parse it and understand the app code to load and data feed to connect to.
I'm still somewhat infatuated with the design and I'd like to see it much more widely adopted. Security issues were, of course, a major issue.