@garbados @SoniEx2 @h presumably they mean an OS where all software (and content if you're extreme) is published and accessed entirely via p2p networks.

@samis @garbados @h the OS's package manager (like apt or pacman) would be fully p2p. It wouldn't even talk to a central server to get the package list - rather, you'd have a list of maintainers (they put packages in an append-only stream), some packagers the maintainers grab packages from, and another stream for metadata, basically saying "these are the packages and versions I can currently recommend installing" (the "package db" as some distros call it).

@SoniEx2 @samis @h sounds pretty chill to me. i think the tech to do it is in development and testing -- i mean, gx et al.

@garbados @samis @h I was thinking of using dat's append-only streams because that's a lot easier to deal with for maintainers as they can just put as many packages in one stream as possible, increasing throughput down the road (I'd explain it but it's too long to fit on this thing, but basically downloading the next package doesn't require you to open a new connection). then the package manager can just do "fetch packages from these and these streams, fetch package DBs from these streams". you can also still have full mirrors.

@SoniEx2 @samis @h i’ve been thinking of something similar using ipfs. reducing content to blocks and peering those makes the swarm graph both bigger (more peers exchanging more things) and more obscure (each thing being exchanged may have a different origin, or the block may be a buffer of something bigger which can’t be reconstructed from the block)

i also think dat is really cool 👍