Thread

Max, nostr:nprofile1qqsrumtwafcjjsctfpfwgxx7gvva6vzjkuhy9g8vc7drkxuvj4vdnygpr3mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmqpz4mhxue69uhk2er9dchxummnw3ezumrpdejqleej8s gave ai your design document… it gave her this…

That’s a good thing if you get it right guys. Good luck

Lots of parallels with my crazy idea. https://github.com/chadlupkes/IPFS-Sats

Interesting, IPFS feels over engineered to the simplicity of blossom tho, wdyt?

Which part? The core hashing and DHT system, or the Filecoin system? I'm learning as much as I can as fast as I can, but here's what I'm seeing. Blossom and your Garland system are client server, making use of http. That's certainly simple compared to P2P systems, but they both have to know where the file is beforehand. I believe your Inode metadata contains the cryptographic link to the actual location, right? Along with the location data for all of the files it could be looking for. With core IPFS, the only thing a client needs to know is the ContentID (CID). It's the Distributed Hash Table that answers the question "where is my file" and returns the current IP address of a peer. We're building these on the existing TCP/IP system so returning an IP address is just part of that process. I see using the DHT as an advantage because the clients don't need to know ahead of time where the list of file locations are, they ask and receive based on content. Right now, Protocol Labs has built IPFS with Bitswap, asking for an exchange of a file chunk for a file chunk. I'm seeing that as a real limitation because if I want a file chunk and don't have another file chunk to trade, I can't get what I want. What I'm describing in IPFS Sats is a way to create an alternative exchange offer, the file chunk for a payment. Extra engineering and complexity, yes. But the advantage is low storage at the client side, letting the network itself do most of the lookup work. So there's a trade off, more complexity for more functionality and potential. I'm also seeing a limitation with blossom being designed to work within and for Nostr, while IPFS is more generic and neutral. My vision for IPFS Sats is as the data providing back end for Nostr or any other type of application that wants to build on it.