nostr:npub108pv4cg5ag52nq082kd5leu9ffrn2gdg6g4xdwatn73y36uzplmq9uyev6 nostr:npub1u83gudwdfwjngz5eqxkrnpvsuydvqwjxwz0majvehqrh62804hfq8yr2s5 nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z >Nostr works a lot better for sharing content, as long as the events are small enough and can be represented as text. It will get replicated and served relatively quickly.

nostr has implicit time expiration. if I were running a relay I'd purge 3m old or greater posts. if it were under load I'd clear every week, day, or even hours if it were bad. that's *terrible* for a file transfer protocol. it's good for social media where there's no concern about whether content actually reaches their destination.

nostr:npub108pv4cg5ag52nq082kd5leu9ffrn2gdg6g4xdwatn73y36uzplmq9uyev6 nostr:npub1j3vtkuurx77yzs33ufzzc08syhrqca8aawa5p4afnfqxrnzvugmqrmqxec nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z so my point here is that for nostr to gain the abilities of ipfs would be quite a leap. whereas for ipfs to gain an additional low latency ability for content selected by the node operator seems quite trivial. you literally just give a hint to the client about where to look first (list of nodes that you paid)

if you pay a node to host content for you then queries to it don't need to do a bunch of hops, indirections, block lookups, etc. you just ask the specified address (ie centralized server) for the object and it sends it back to you immediately because it has the entire thing sitting there because that's what you paid them for

you could literally reuse existing ipfs http relays for this. set one up that only fulfills queries for stuff it has pinned locally and then charge to pin stuff on it. I'm not saying that's a particularly elegant solution but it would work at which point I'm really wondering what the point of nostr is in this scenario