I proposed this project to improve on Radicle’s p2p model by using Tor for universal, straightforward seeding of git repos.
Original discussion thread - https://bounties.monero.social/posts/207/
One of the project’s git repos linked in that thread - https://radicle.network/nodes/iris.radicle.network/rad:z2ydYmUCJvDfNFTVTpEbQmm55EPt1/history
Project website - https://cradicle.xyz/
The dev who took the project also expanded it into a project to reimplement Radicle in C.
Since I’m not a coder and I don’t have any git repos of my own, I can only test from the viewpoint of an average layman using the GUI app to seed repos.
It’s impossible for me to properly gauge how the project is progressing without engagement from coders who try using it for their git repos.
If the project doesn’t currently interest you, your suggestions on how to start getting users on board would also be welcome.
Edit - bear in mind that because decentralized discussion platforms like this are currently quite broken, there are comments showing up in the thread when I’m not signed in that don’t show up for me when I’m signed in. Here’s a screenshot of all the comments showing up for me right now where I’m signed in and able to reply, as of UNIX time 1779670288
I’d encourage discussion of this project moreso on nostr (equally broken but my preferred platform) or the discussion thread linked above (seemingly more functional)
That’s an even worse use-case mismatch than anything I had in mind, forcing anonymous transport via a traffic-pressured network primarily used for outproxying, just to get fixed network addressing.
I don’t get what you mean by “traffic-pressured.” If you’re referring to the Tor devs recommending against the use of torrents, that’s because torrents typically involve out-of-Tor traffic which burdens exit nodes. Cradicle isn’t torrents, the Tor devs don’t recommend against using onion addresses for their intended purpose of traffic within the Tor network, that wouldn’t make much sense.
Regardless, if you have a better way to implement one-click seeding like bittorrent clients have, feel free to suggest it or build it.
The bottlenecks don’t only exist at the exit nodes. You didn’t actually think you will be getting Gigabit speeds using hidden-services, did you?
You seem to be suggesting 3 things:
Are we on the same page with these 3 bullet points, or am I still not understanding you?
Tor is slow. People use it when they need the anonymity. Using it when it’s not strictly needed doesn’t help you (or the network, but that’s besides the point).
The problem you presented, as I understand it at least, doesn’t require Tor at all, and can be solved with much lighterweight solutions. For example, did you know that PKARR exits?
If Tor gets more users, they can run Tor nodes. The network scales to the traffic because it’s decentralized. You’re making up a problem that isn’t there. The Tor project does not recommend against creating traffic using onion services, again it wouldn’t make sense, there would be nothing to do with onion services then.
I’m really not understanding your point about anonymity. Why would we want every user in a P2P network to expose their clearnet IP address to every other user? It seems like if you flipped the release dates of Tor and BitTorrent, then Bram Cohen probably would have designed BitTorrent with Tor in mind from the start and it wouldn’t burden exit nodes so much. People would only use it without Tor when speed is more of a priority than security. But instead BitTorrent came first and already relied on an out-of-Tor network.
Most tor peers are not relays. So no, tor’s network capacity doesn’t auto-scale with more users, even when you’re sticking to hidden services.
And you didn’t argue for anonymity from the start. And anonymity is a BIG argument, with bigger design implications than you think.
Original Freenet (now called Hyphanet) predates both bittorrent and tor. And it’s one early example (and not the only one btw) of how you properly combine anonymous storage with anonymous transport (content addressing too, but that’s more of a jibe against the IPFS meme). It’s also (relatively) slow, and that’s actually intentional, at least in part, because speed can hurt your anonymity (the details are too technical, and that’s not the place to delve into them).
Bittorrent didn’t lack (native) anonymity because the idea/tech was impossible to imagine. Anonymity didn’t come into the picture because availability and speed were the priorities. The protocol didn’t have encryption from the start either (or sub-piece downloading, or DHT, or PEX, or udp trackers, or uTP transport, but I digress).
Edit - I’ll leave my original reply crossed out, but it doesn’t feel like a good reply to me and I think sometimes I don’t know how to properly respond to people these days.
Stop with the gish gallops.I should not need to address this many points because you keep pulling random nonsense out of nowhere. Look how fucking long this list of bullet points is just for one reply. Do some amount of double-checking your own thoughts before making me think through every single thought that pops into your head.You’re incorrect on your first point. Non-relay “peers” don’t stop Tor from scaling.When you say “from the start” it seems to imply I started “arguing for anonymity” at some point. I didn’t. This is an electronic network.Instead of explaining how hyphanet is supposed to be better than Tor for p2p git repos, you kept dwelling on conflating “privacy” with something users can get from a widespread software network on today’s hardware.Tor being “slow” is “intentional” for the same reason, I don’t get what makes you think that’s groundbreaking.What’s not the place to delve into what?This pattern keeps showing up: the part about BitTorrent seems like you’re conflating “anonymity” with something users can get out of a network like this, and not actually getting to whatever your point is about BitTorrent.Anonymity makes sense in this case. Radicle is often proposed as a solution to the censorship of projects in other repos, things like Nintendo Switch emulators, Hayase streaming client, etc. These projects want to remain anonymous to avoid legal threats on their actual identity
P2P already gives you anti-censorship. Publisher anonymity shouldn’t be hard for developers to achieve either.
If full network anonymity is desirable, then you would need a full top-down design to do it properly, and this becomes a whole different conversation (and the choice of using bittorrent itself will have to be revisited). But really, I don’t think that’s needed here.
Pluggable transports can still be useful for varying reasons of course. I don’t think anyone would argue against them.
But I would still opine that forcing a slow network on any forge alternative is the fastest way to keep 99% of potential users away.
until a lawyer joins the swarm and has the IP of every node. See which node pushes commits to the swarm first, and you found the dev. Send a couple of threats to the dev and watch the project grind to a halt.
Plugging into Tor or I2P is a easy way to give network anonymity, no need to re-invent the wheel. Though it seems like Radicle already supports Tor and I2P so not entirely sure what OP aims to do
How do you send a threat to an IP address? 😏 about supposed push of code encrypted no less. Unless, you’re thinking ISP involvement, that would be a hilarious (single) e-mail to read (from the “lawyer” to the ISP, because there will be no other correspondence).
If the threat model is “lawyer”, developers will be fine. If it’s a “state actor” and/or all users need protection, then again, this is a whole other conversation. If it’s something in between, then yes, maybe developers/publishers should specifically be careful, and/or maybe the design of the software should help them, but without compromising the performance of the whole network. But again, bittorrent will not be the right protocol for this anyway.
In the past I’ve recommended onions for port forwarding. It’s more simple than alternatives and using the network is free.
The authors or Tor really don’t want their network used for torrenting though. They do support JS, and by extension I would argue the authors intended for their users to be able to use YouTube. In comparison to video, git traffic is insignificant. I don’t see anything wrong with it, but then again, users of torrents don’t usually have issues downloading without port forwarding.
That was kind of my point. Why would you bring TOR into this?
If you effectively want a DNS alternative for users, you can use GNS or Handshake or whatever.
If you need port forwarding too, or sockets or whatever, then you can use something like iroh for that.
Cloning git repos from fast hosts is slow(ish) enough already. Forcing a supposed alternative to push traffic over TOR for not even a compelling reason like anonymity is very weird.