Anyone know about IPFS, nostr:npub1h0rnetjp2qka44ayzyjcdh90gs3gzrtq4f94033heng6w34s0pzq2yfv0g, or any other censorship resistant file storage?
I’m looking for someone who can talk IPFS, or any other hash based or permissionless file storage solution that have been tried at nostr:npub1nstrcu63lzpjkz94djajuz2evrgu2psd66cwgc0gz0c0qazezx0q9urg5l , August 22-23 in 🇱🇻.
https://github.com/nostrworld/nostriga/issues/22
cc nostr:npub1ye5ptcxfyyxl5vjvdjar2ua3f0hynkjzpx552mu5snj3qmx5pzjscpknpr nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s nostr:note1yh7he40we340rsph7u2wudwyrllfpeec53mqyfq3sc2d9kmmzutsdrx2h7
Discussion
Blossom
Happy to chat! We’ve been at it for over a year now.
We evolved IPFS Merkle DAGs to avoid the bloated Merkle DAG branches. Chunked file storage is required to prevent delay attacks when transmitting large files over Nostr (or across any distributed network).
nostr:npub1elta7cneng3w8p9y4dw633qzdjr4kyvaparuyuttyrx6e8xp7xnq32cume is also exploring this space.
I've looked into the IPFS multi-hash docs before and it looks cool but I'm not sure what problem they solve. I don't know whats the use of using multiple hashing algorithms when all you want is a single universal ID for a file.
I still need to learn more though 😀
or file slice ! you can add many and get the file. I think http supports partial get and file can be split in many slices ( Web/HTTP/Range_requests ) with hash for each slice.
i think the thing is that whether the hash is segmented or not is irrelevant at the network layer
the individual hashes in a merkle tree can be numbered as they are sequential, so a query syntax can just add the segment number as an (optional) parameter, the top level hash, be it the actual hash of the file or the merkle tree of the segments the segments do not need to be separately addressed
just more complexity for no reason
the amount of times hash functions are called in these things is far less than requires serious optimization
just stick to one hash
and just stick to one network transport and encoding for as long as possible, and let someone else manage that shit
igaf about blake3 it's not that much better and not better in the regular implementation than sha256 in the SIMD implementation
blake3's main selling point is performance, its collision resistance and preimage resistance are considered to be about equal
when your codebase is already using SHA256 every further hash you want to add is interface complexity and execution complexity
without a compelling reason to do it, better to upgrade to SIMD than ADD blake3
pear uses their own merkle hash using blake 2b because it is faster than blake3 https://github.com/holepunchto/hypercore/blob/main/lib/merkle-tree.js
https://github.com/holepunchto/hypercore-crypto/blob/main/index.js
blake2b as crypto_generichash from libsodium https://libsodium.gitbook.io/doc/hashing/generic_hashing
can blossom work with webtorrent and peertube if the same file has multiple enddpoints?
blossom is mostly just a spec for serving files by their sha256 form a fixed endpoint, there isn't anything about how files could be shared between servers.
so in theory it could be compatible with those protocols. but the server would have to implement webtorrent itself
unfortunately webtorrent uses a different hash than blossom. so the identifier for the file wouldn't be the same across the protocols
blossom looks like a DHT node in this case. you only need
Kademlia . It will be nice to have flexible endpoint, like https://git/user/project/branch/sha256.ext
no merkle hash?
the creator of webtorrent is now behind pears.com