20
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 24 May 2026
20 points (85.7% liked)
Programming
27052 readers
138 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 3 years ago
MODERATORS

That doesn't sound right. Maybe design/implementation details would make it less nonsensical.
Now this just sounds like a bad joke. Especially with the tor project itself spending all this effort to give us arti as a readily usable embeddable rust crate.
The proposal used Tor's onion addresses as an answer to Radicle (unlike BitTorrent) requiring seeders to have fixed IP addresses or domain names (edit - or preconfigured onion proxies or something making onion addresses complex to use). Another reply suggests this problem with Radicle has been fixed or they've started fixing it while this project was in development. I haven't really kept up with the news on Radicle in that timeframe.
I don't see why. If radicle is a serious decentralized project at the scale of potentially replacing github, it should of course end up with multiple implementations in multiple programming languages. Can you clarify your view more?
There's almost zero reason to choose C for any greenfield project. C / C++ have been plagued with extremely serious problems throughout history because they are not memory safe. The world needs to move on from memory unsafe languages whenever it can.
Choosing C for something like this would be idiotic.
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.
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.
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?
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.
There's many ways to track somebody down via IP address, but yes ISPs can corroborate. You ever heard of people getting letters from the ISP for torrenting? You think the ISPs actually care about piracy? They are forced by legal pressure.
The threat model is massive fines and potential prison, depending on how the court case goes. Look up the Yuzu nintendo switch emulator and how that legal battle went. And I'm not arguing that those developers were the brightest of the bunch. I'm saying that those developers could use the privacy that Tor offers.
Bittorrent works well enough. Bittorrent works fine over I2P and is used plenty. Better to get something up and running before starting to design bespoke protocols.
🤣
I deliberately mentioned this because that "program", as you would expect, ended up as a failed meme, which is why it's sadly no longer with us.
And it wasn't about people seeding their own code, or code otherwise allowed to be redistributed, anyway.
I actually know somebody that was fined quite a bit for torrenting, so idk what you mean by failed meme. The ISP absolutely does collaborate with copyright lawyers. So if copyright lawyers with enough money want to take down a nintendo switch emulator, and they got the IP of the dev, they cound find the real person behind it easily.
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.~~