More than 500,000 books have been removed from the Internet Archive's lending library due to the Hachette v. Internet Archive lawsuit, including more than 1,300 banned and challenged titles. 📚 Our patrons have shared powerful stories about how this loss has impacted them, and we need your help to make a change.

Sign our open letter to the publishers urging them to restore access to these books. 📖✍️ #LetReadersRead

👉 https://blog.archive.org/2024/06/17/let-readers-read/

Let Readers Read | Internet Archive Blogs

@internetarchive Torrenting is the only way.
@ml @internetarchive bittorrent (and all other current alternatives afaik) don't have any sort of anonymization, so ISPs can surveil torrent peers and cut off your access. it's not clear to me yet how to apply the consistent hashing used in most DHTs to tor's model yet, but tor may expose a sort of internal node ID that could be similarly used to achieve consistent hashing? @torproject has there been work to anonymize DHTs via tor or other alternatives?

@hipsterelectron Tor actually has a FAQ asking people to not use Tor for bittorrent because it stresses the network

IPFS has done some work in this space, we're not sure how far along that aspect is

@ireneista their website says ipfs is not private and to use something else if you want privacy i was checking it out yesterday

@hipsterelectron oh. drat.

I2p is an overlay network that does support bittorrent, although that falls significantly short of true anonymization, for reasons you can probably already see

@ireneista tor's anonymity via noise addition is less interesting to me anyway; VPNs can be used to interface but i recall hearing that some VPNs don't like being used for seedboxes. the level of privacy sufficient to mask participation in a particular swarm to an ISP seems less stringent than tor's guarantees and the consistent hashing needed for a DHT seems like something that could be achieved with any other identifier, but masking identity to all other participants in the swarm seems necessary as well and may be more difficult than i'm hoping :(
@ireneista looking at i2p now, thanks for mentioning
@hipsterelectron @ireneista veilid's probably a better option for the backbone of a private file sharing system tbh
@beka_valentine @hipsterelectron can you say more about why?

@ireneista @hipsterelectron designed to support onion routing internally for all messages, and in testing it seems to be quite fast in doing so

biggest problem right now is lack of deployment

@beka_valentine @hipsterelectron @ireneista The developer documentation for Veilid also seems fairly poor.

I'm not sure it supports a given program using multiple IDs at once (while I2P does), which is important to mitigate fingerprinting of shared collections of data.

@lispi314 @ireneista @hipsterelectron @beka_valentine you could write a veilid node that uses multiple ids at once (or at least i didn’t find anything that prevented that when i was looking into it).

but veilid’s layering makes it significantly harder to disassociate sequential identities of the same node by what data they host - they have a DHT built in right along with the routing protocol.

i’m doubtful that multiple ids will actually save you though. i haven’t examined it in detail yet, but my intuition is that even if each person uses 100 ids you’ll be able to track people sharing say 1000 pieces of data randomly divided amongst the ids. (much less any sort of division optimized to improve queries like the fraction nearest by edit distance).

i’m vaguely hopeful about a friend network over an privately routed network. if you all rotate node identifiers such that you only send messages to an identifier of generation n from an identifier of generation n, there may be a chance of cleanly separating identifiers from each other (from anyone who’s not your friend that is). then you just have the problem of how much you trust your friends and finding content in a friend network…

@tryst @beka_valentine @hipsterelectron @ireneista I was thinking more a different ID per piece of data.

For the I2P case more on the level of "every torrent has its own ephemeral ID".

I'm not quite sure if Veilid's block-based structuring of data sharing should be the level of granularity for ID separation, because after a few thousand blocks, the overhead probably becomes considerable. So maybe ID separation at a higher level similarly to torrents (they do have reference blocks) would work.

> i’m vaguely hopeful about a friend network over an privately routed network. if you all rotate node identifiers such that you only send messages to an identifier of generation n from an identifier of generation n, there may be a chance of cleanly separating identifiers from each other (from anyone who’s not your friend that is). then you just have the problem of how much you trust your friends and finding content in a friend network…

My concern with friend-to-friend networks is that their security tends to fail catastrophically the second someone gets compromised and an infiltrator is substituted onto the network.

It's somewhat similar to the failure mode of Hyphanet/Freenet's with the trackability of particular file transfers with known/leaked/guessed metadata.
@lispi314 @hipsterelectron @tryst @beka_valentine these are all good thoughts, fwiw. we agree about that risk being significant, but really any of these schemes needs to be sketched out in more detail to figure out what it actually accomplishes. we definitely encourage playing around with all this