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 isn't that true of I2P as well?
@ireneista @hipsterelectron i2p may or may not do onion routing, i dunno, but i2p is just a vpn-like infra, afaik. it doesnt have a bunch of the other important stuff required to make a file sharing system work. plus iinm i2p is also asymmetric in that the client is tunneled but the server is visible. so its like only the onion routing portion of TOR, absent the hidden sites, which veilid has built in
@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

@lispi314 @ireneista @hipsterelectron @beka_valentine yeah, once you get to each top-level item on a node gets its own overlay network identifier that certainly prevents correlating content. i’m hesitant that giving each node that many identifiers wouldn’t lead to being able to correlate address on the same node though. (and any answer to means digging deep into the protocol and its assumptions :/)

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.

so this broadly falls under “how much you trust your friends”, but i’m not clear that your friend being compromised is much worse in a friend net situation than a not friend net situation (assuming communication over an overlay network and not directly like freenet/hyphanet). the most informative data flows from friend to friend anyway. the link to decrypt and verify data is far more sensitive than the ciphertext.

unfortunately (for anyone hoping for this to have a reasonable UI) i think we probably need both for different circumstances :/

@tryst @beka_valentine @hipsterelectron @ireneista
> (and any answer to means digging deep into the protocol and its assumptions :/)

Yeah, project for a later time.

> so this broadly falls under “how much you trust your friends”, but i’m not clear that your friend being compromised is much worse in a friend net situation than a not friend net situation (assuming communication over an overlay network and not directly like freenet/hyphanet). the most informative data flows from friend to friend anyway. the link to decrypt and verify data is far more sensitive than the ciphertext.

I mostly expect my friends not to be able to outgun or meaningfully resist their government's enforcers.

I didn't mean to imply voluntary compromise.

Building a pseudonymous friend-to-friend network atop an overlay network that takes the basic stance "every node and observer can be adversarial" does help. Though f2f interactions may also lead to the incidental accumulation of other deanonymizing information.