I can’t help but think about this while reading this post. However, this is probably indicative of my lack of understanding of computer networks, despite dealing with it from time to time.
post
What is your view on veilid as compared to this?
First time I hear of it. They say this is for private networking only. Also it's only a network stack for now (the "BlockStore" storage component is not yet defined). So apparently it's not for public filesharing. They compare it to Tor but it looks more like an overlay mesh network at first sight.
I really like two of their points:
- anonymous by design
- distributed as a library
I really hate because such projects as IPFS required me to install some extention and a niche component that is hard to understand. While it is easy for me to do it I have abandoned all hope that project like this would gain some broader popularity.
For example qbittorrent is already hard to use for most people and it does not require to install extention and background service. You just install an app.
For Iroh-blobs, Dropwire would be the easy-to use all-in-one app (not appropriate for mass sharing just yet). Then there is the iroh-http library, allowing to use Iroh-blobs on a web browser (without installing anything; a website similar to instant.io / webtorrent.io).
Also note that most of the big Bittorrent peers have a pretty sophisticated setup anyway (allways-on machine with raid array; bittorrent daemons; remote client; VPN; download automation indexers; media library etc).
FWIW, you can access IPFS content with an in-browser IPFS gateway now, so no need to install anything: https://inbrowser.link/
You'll still need to install something if you want to add/pin content, etc., but the in-browser gateway is convenient for sharing links to IPFS stuff with someone who doesn't know what IPFS is.
Yes. But relying whole infrastructure on some central gateways goes in the opposite direction of the project goals.
Any mutability or just immutable?
I noticed the example they provide contain a list of file (CID points to a folder): https://y7rmokt6h5mryuauw83em4u1br6tqrukaw3ngtde7zp8p3bg6hto.blake3.net/ or https://5ti57aszf7kaicsncb4wgigkf9bju39kofiz8dthwdujkmz85u8y.pkarr.net/; the latter identifies the same content by a public key. I guess the public key identifier allows mutable linking.
iroh-share is not decentralized filesharing.
iroh seems like a stack. like https://libp2p.io/docs/
eventually they may have a tool that does decentralized filesharing.
and if i was going to dev my own solution from scratch, iroh would be my pick.
but i'm lazy so i use ipfs(kubo) . it works
update:
i now see that iroh has https://github.com/n0-computer/iroh-share
however it does not share partial pieces like bittorent and ipfs .
in many cases, that might actually be more efficient (like an ordinary download).
and from my understanding: it supports multiple providers as the source. ( so it is decentralized ).
i think there are advantages and drawbacks.
From my understanding, peers stream merkle-tree leaves to the requester, allowing to verify data while downloading: https://docs.rs/iroh-blobs/latest/iroh_blobs/protocol/index.html#responses
So it does have piece chunking for large files, which correspond to the native Blake3 chunks.
The same goes for shared directories (sharing each file root blake3), I think this is called a "Collection".
i think https://github.com/mrsarthi/Chorrent is a better bittorrent/ipfs replacement.
from my understanding, iroh-share is like ipfs-style global uploads, and then can be fetched from any peer with continuation ( like wget -c ) .
no comments (yet)