[HN Gopher] PrivTracker - Private BitTorrent tracker for everyone
___________________________________________________________________
PrivTracker - Private BitTorrent tracker for everyone
Author : prvt
Score : 139 points
Date : 2025-01-11 08:49 UTC (14 hours ago)
(HTM) web link (privtracker.com)
(TXT) w3m dump (privtracker.com)
| frizlab wrote:
| Love this. I continue to believe Torrenting is the best way to
| share files, particularly big files, rather than uploading them
| to some cloud instance with questionable privacy policies...
| ranger_danger wrote:
| Except when there's no seeds. Usenet seems to have solved this
| many moons ago.
| dncosta wrote:
| And now with the added bonus that apparently anything goes, as
| long as you just say you're downloading training data...
| zaik wrote:
| I used the pipeline tar | gpg --symmetric |
| torrent
|
| to transfer a 4GB collection of photos to a (technically
| skilled) friend on a slow mobile connection and it worked quite
| well. I could shut off my computer and it would resume the
| transfer the next day as if nothing happened.
| Pooge wrote:
| Is there a self-hostable BitTorrent tracker that can run with
| Docker? I know there's an option on qBittorrent but I don't want
| my server to run a full BitTorrent client; just the tracker.
| haunter wrote:
| sqtracker https://github.com/tdjsnelling/sqtracker
| Pooge wrote:
| I've heard of this, but I don't mind anyone with the tracker
| URI to be able to connect to it. sqtracker is a full-blown
| system to run a _private_ tracker with user and ratio
| management, which is overkill in my case.
|
| Others might find the link useful, though!
| haunter wrote:
| How about webtorrent's tracker? There is no Docker file but
| it should be doable
| https://github.com/webtorrent/bittorrent-tracker
| crtasm wrote:
| OP has a docker compose example:
| https://github.com/meehow/privtracker
| diggan wrote:
| What features are you looking for specifically? If you just
| want like a really basic index, hosting a JSON file with a
| object where the key is the infohash and the value is the
| metadata is a really simple approach :)
| Pooge wrote:
| No specific feature whatsoever. I basically want anybody that
| puts <my_bittorrent_tracker_uri> into their torrent tracker
| list to be able to connect.
|
| That will help me to stop relying on known and popular public
| trackers[1] in order to share files.
|
| [1]: https://github.com/ngosang/trackerslist
| loeg wrote:
| Do people still use Ocelot? I have no idea.
| cbg0 wrote:
| For the less technically inclined folks that don't trust this
| hosted service or can't host their own it's probably simpler to
| just use a seedbox if you need to access torrented files from
| multiple locations or you want to share them with others.
| Pooge wrote:
| This is not what this project is about. You either need a
| tracker or register to DHT in order to connect to peers. Having
| a seedbox has nothing to do with that; you'd still either of
| those for your friends to connect to you and download your
| files.
| franczesko wrote:
| P2P is such an underrated tech
| teddyh wrote:
| It was never underrated, just too useful. Every time someone
| invents an _actually effective_ method of person-to-person file
| transfer, it gets used for piracy and blocked and shunned.
| axelthegerman wrote:
| That and it's hard/impossible to monetize, so big corps and
| VCs are not interested
| rglullis wrote:
| It's hard to monetize _at VC scale_ , but that doesn't stop
| small-scale pirates and gray area business to use and make
| a living out of it.
|
| E.g, in Brazil, Greece and (if you know where to look) even
| here in Berlin, it is not that difficult to find set top
| boxes that come with Kodi pre configured with a private
| tracker and some custom frontend to download movies and
| shows on demand. In Brazil you buy the box and you pay
| something like R$200 ($35) per year.
| JeremyNT wrote:
| It exists on a knife's edge: incredibly useful and powerful
| to those who are in the know, but obscure enough to avoid
| heavy handed efforts to obliterate it.
|
| I sometimes wonder how LLMs will impact this. They're much
| better at surfacing this kind of arcane knowledge than
| traditional search engines, and that risks increasing
| accessibility.
|
| If accessibility gets too high, the ISPs could respond
| against it.
| beardog wrote:
| Remember to disable the dht if you use this.
| Pooge wrote:
| Unneeded; checking "Private torrent" when creating a torrent
| means that it won't connect you to the DHT.
| diggan wrote:
| Worth noting if someone uses this to share private data: Checking
| the "Private torrent" would tell your and compliant clients to
| not use DHT and other public methods that can leak the content.
| But it doesn't stop other non-compliant clients from sharing it
| on the DHT once they have it, nor does it stop someone from just
| ticking "Enable DHT" on their side once they have received it (or
| change "private" to "false" in the torrent file itself).
|
| Obvious to many I'm sure, but maybe best to be explicit about it
| anyways.
|
| Slightly off-topic but kind of fitting: How does infohash v2
| support look like today? It's been available for years, but
| seemingly most private trackers + most other places seems to
| still be using v1. What clients are people using today, do those
| support v2? As far as I know, all modern clients do, so it would
| be possible to start using v2 exclusively.
|
| Reason for the question is that I'm planning to distribute many
| large files to the public, and in my experience, BitTorrent works
| really well for that. Question is if it's enough to just publish
| v2 infohashes, or I need to publish both v1 and v2.
| binaryturtle wrote:
| If you flip the "private" flag it would change the infohash of
| the torrent. The "private" flag is part of the info block in
| the torrent file's data. With an infohash mismatch between the
| two peers no download would happen.
|
| Obviously after a non-compliant party to the transfer has fully
| downloaded the file(s) it can do whatever it wants with it
| afterwards... flip any flags and share via DHT, etc.
|
| I recently shared some --more or less-- private data to someone
| else via BitTorrent. We just used DHT for convenience. It took
| like 15 minutes for other random peers to pop into the
| transfer. All of those random peers just fetched the meta data.
| And indeed, a check on btdig confirmed the whole metadata (file
| names, file sizes, etc.) leaked. So there's a lot of DHT
| network scanning going on for sure. It was rather fascinating.
| No actual data was downloaded/leaked at least.
| pessimizer wrote:
| > So there's a lot of DHT network scanning going on for sure.
|
| How else would btdig (and others) fill their index?
|
| The standard solution is to compress what you're sending with
| 7zip, with a password.
|
| > No actual data was downloaded/leaked at least.
|
| I've had randos download the data before the intended
| recipient figured out how to open a port.
| boramalper wrote:
| > So there's a lot of DHT network scanning going on for sure.
|
| There is an entire category of free software whose purpose is
| to create an index of the DHT network. :) The idea is to
| allow users to find and search for torrents in a completely
| decentralised manner (i.e. without relying on any centralised
| trackers or search engines).[1] A good example is
| bitmagnet[0].
|
| [0] https://bitmagnet.io/
|
| [1] With the added benefit of greater resilience, as
| centralised "chokepoints" are often the primary and only
| targets of takedowns.
| teeray wrote:
| If it's intended to be private, you can always encrypt, then
| torrent. You can probably be more tight-fisted about who gets
| to decrypt.
| loganhood wrote:
| Does a private tracker provide any meaningful security if I'm
| already encrypting the contents of the torrent?
| Pooge wrote:
| The tracker is just there to help you connect to peers. I
| wonder if somebody connected to the tracker could know all the
| torrents that are being shared. But probably not.
___________________________________________________________________
(page generated 2025-01-11 23:01 UTC)