tldr:
Data path: file → fixed-size chunks → encrypt each block → erasure-code into n shards → upload shards to n servers
Key derivation: nsec → random per-file key → derived per-block subkey
nostr:naddr1qqgxxdryxfsnxvf3xscnvdnx8pnr2qg5waen5te0xyerwt3s9cczuvf6xsurvwf0qgst0mtgkp3du662ztj3l4fgts0purksu5fgek5n4vgmg9gt2hkn9lqrqsqqqa28ajp369
Max, nostr:nprofile1qqsrumtwafcjjsctfpfwgxx7gvva6vzjkuhy9g8vc7drkxuvj4vdnygpr3mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmqpz4mhxue69uhk2er9dchxummnw3ezumrpdejqleej8s gave ai your design document… it gave her this…
Lots of parallels with my crazy idea.
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.
Interesting, thanks!
I'm a fan of smart clients dumb servers, and seems like IPFS is the opposite.
You can have a smart blossom client that bootstraps with some hard coded nostr/blossom relays, and then discovers other servers, then queries for files.
Ultimately the same UX as IPFS, with much less complexity.
Really not sure if that's an accurate claim tho.
I'm a fan of smart clients and smart servers, if that makes sense. Using Nostr as a social media contextual layer, but a network of servers that can boost and enhance the experience by providing not just the single file that we are looking for but through metadata and discovery systems an entire set of further links and verified information that can encourage us to continue exploring and growing.
What's missing that prevents the current systems from reaching towards that goal is an economic layer, and that's the core puzzle piece that I'm trying to find a way to fill in. IPFS Sats is a contextual design for that economic incentive layer.
Yes, That's a good direction, Thanks for doing this!
I need all the help I can get. I'm not a coder or developer myself, and so far the only place I have been able to get feedback on the ideas are the digital intelligence systems. I think it could work, but actually creating it is beyond my skills.
