←back to thread

Show HN: I wrote a new BitTorrent tracker in Elixir

(github.com)
394 points dahrkael | 1 comments | 19 Jun 25 22:49 UTC | HN request time: 0.247s | source

Hello everyone!

I'm currently in a journey to learn and improve my Elixir and Go skills (my daily job uses C++) and looking through my backlog for projects to take on I decided Elixir is the perfect language to write a highly-parallel BitTorrent tracker. So I have spent my free time these last 3 months writing one! Now I think it has enough features to present it to the world (and a docker image to give it a quick try).

I know some people see trackers as relics of the past now that DHT and PEX are common but I think they still serve a purpose in today's Internet (purely talking about public trackers). That said there is not a lot going on in terms of new developments since everyone just throws opentracker in a vps a calls it a day (honorable exceptions: aquatic and torrust).

I plan to continue development for the foreseeable future and add some (optional) esoteric features along the way so if anyone currently operates a tracker please give a try and enjoy the lack of crashes.

note: only swarm_printout.ex has been vibe coded, the rest has all been written by hand.

Show context
TheJoeMan ◴[20 Jun 25 13:11 UTC] No.44327403[source]▶
Could you please clarify what DHT and PEX are? I'm having trouble searching "tracker PEX".
replies(2): >>44327470 #>>44328225 #
atmosx ◴[20 Jun 25 14:47 UTC] No.44328225[source]▶
DHT (Distributed Hash Table) and PEX (Peer Exchange) let torrent clients find peers without centralised trackers. Hence, you don't need a central place / public tracker anymore
replies(1): >>44328273 #
Thaxll ◴[20 Jun 25 14:52 UTC] No.44328273[source]▶
You still need a central server though...
replies(2): >>44328943 #>>44328959 #
LtdJorge ◴[20 Jun 25 15:56 UTC] No.44328959[source]▶
If you are connected to the DHT network, you don’t. Unless you mean for DNS and such.
replies(1): >>44328985 #
perching_aix ◴[20 Jun 25 15:58 UTC] No.44328985[source]▶
No, they mean specifically that in order to connect to such a network, you need to hit some specific central nodes first.
replies(1): >>44329166 #
LtdJorge ◴[20 Jun 25 16:12 UTC] No.44329166[source]▶
The bootstrap nodes. But those don't _need_ to be centralized, even if they have historically been to some degree. There coul be millions.
replies(2): >>44329242 #>>44334328 #
immibis ◴[20 Jun 25 16:18 UTC] No.44329242[source]▶
If there are millions of bootstrap nodes, how do you find them?
replies(2): >>44330143 #>>44331791 #
toast0 ◴[20 Jun 25 17:52 UTC] No.44330143[source]▶
If they listen on a well known port, and there are millions, send out a few thousand probes to 'random' IPv4 addresses and you'll most likely find one.

If you get and keep a list of bootstrap nodes when you find one, then you can random select from the bootstrap addresses rather than all routable IPv4 addresses.

replies(1): >>44331766 #
immibis ◴[20 Jun 25 20:28 UTC] No.44331766[source]▶
What's your IPv6 plan?
replies(1): >>44332037 #
1. toast0 ◴[20 Jun 25 20:59 UTC] No.44332037[source]▶
Probing IPv6 would be pretty difficult. You could make some assumptions that might hold, like assume only the lowest /64 out of a /48 is used and ::0 or ::1 for the end of the address. Likely you'll still need too many probes to be feasible.

You'd need to probe v4 space through NAT64 and exchange v6 addresses after that, or include a cache of viable v6 addresses with clients. That gets you close to centralized service again, because how do you get the viable addresses to distribute with the client? Probably by running a supernode and dumping the list of supernodes into the client source every so often; but starting off with just that node listed.