3 ms·
The version of Nostr that I happened to invent about a year before Fiatjaf invented his was about the same as Nostr, except for the fact that I chose a true IPF
by quantadev 1y ago
The version of Nostr that I happened to invent about a year before Fiatjaf invented his was about the same as Nostr, except for the fact that I chose a true IPFS CID as the identifier, which Nostr cannot do, making it completely incompatible with IPFS, unless you have TWO hashes (both a CID and a Nostr ID), which I found silly.
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.
- immibis 1y agoFrom the fact that you completely ignored the question on whether Nostr has suffered a reality-injecting major problem yet, I assume that it hasn't yet. BTW IPFS CID isn't even the best, oldest or most stable identifier. We had SHA256 hashes before IPFS.
- quantadev 1y agoI answer about things I'm interested in and know about. I don't know about any breaches of Nostr protocol, because I quit all Nostr work 2 years ago. 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.
- pfraze 1y agoHolmgren and I overengineered atproto without jeromy's help
- quantadev 1y agoHey Fraze! I'm a big fan of yours! I bet you know who I am, but don't dox me plz. :) I hope things are going well for you at Blue Sky actually, if you're still there. I think all your contributions to ATProto were probably all the good ones! 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.