weev's avatar
weev 2 months ago
> but discoverability of “unpopular” content is slower Sure, but a social pinning model and IPFS peer graph makes this irrelevant. We’re not talking about an ancient file. We’re talking about a message that I *just posted* that is being ostensibly served by my followers. Your first IPFS node to check could be one I offer via the same tor onion as my relay. And I’m sure to have it, it’s my file. An easy place to query for a hash that is not me, in this instance, would be my followers, who are, in this hypothetical, pinning my content. You don’t need to search the entire IFPS network. Regardless, this is a side channel. It doesn’t have to be a silver bullet! It just has to make my content more available than it already is, and reduce immediate stress during peak hours upon public relays and media servers.
↑ Parent

Replies (1)

Technical Debt's avatar
Technical Debt technicaldebt@nostrcheck.me 2 months ago
I don’t know the specifics that make IPFS slow, but I’m skeptical it’s something that could be fixed easily without some sort of hairy drawback (otherwise it would’ve been fixed upstream already). Your proposed solution would help offload blossom servers but not propagating notes themselves. I don’t think it’s fair to say “this is just a side channel” to deflect issues because it opens a terrible precedent, why should a dev support the “bad” transport instead of just supporting the canonical one? Don’t get me wrong, if you look at my past notes you will know I’ve been tooting the P2P horn, the problems with tying features to specific relays etc. but I also appreciate the pragmatic approach nostr devs have taken to get something off the ground. My point is, I think we should learn from past experiences (also see Zeronet) so we don’t repeat the same mistakes.
↑