3 ms·

I work on a BitTorrent tracker on the side[0] that's used for deploying software at a few companies, but has the unique feature of a middleware layer. Right now

I work on a BitTorrent tracker on the side[0] that's used for deploying software at a few companies, but has the unique feature of a middleware layer. Right now, there are two different middleware that require a signature of the infohash (files being shared) before allowing content to be shared. One is for JWTs[1] and upstreamed in the project and the other is for a blockchain and hasn't been upstreamed yet. Using features like this, they can run their tracker on the public internet and not worry about people sharing illegal content. I had never considered it, but this sounds like a great use case for academia, too. [0]: https://chihaya.io https://chihaya.io [1]: https://jwt.io https://jwt.io

tmalsburg2 10y ago
Very interesting. Does that mean that there would have to be a central authority that has to sign new torrents? For the present purpose that may not be ideal because this system wouldn't be decentralized, and one institution (or a small set of institutions) would have all control. Ideally, there would be some consensus mechanism that determines which torrents are bad and shouldn't be distributed. Also, what happens when the key for singing torrents is stolen? In the case of a company using such a system, that situation can be handled but in a more decentralized system with an emphasis on long-term storage the loss of a key may be a bigger problem.
- jzelinskie 10y ago
  >Does that mean that there would have to be a central authority that has to sign new torrents? In this scenario, the source of truth is the location where your users are acquiring their .torrent files. >For the present purpose that may not be ideal because this system wouldn't be decentralized, and one institution (or a small set of institutions) would have all control. Ideally, there would be some consensus mechanism that determines which torrents are bad and shouldn't be distributed. Trackers are the centralized alternative to using the Mainline BitTorrent DHT. The performance advantage significant enough they're still in common use after the ubiquity of DHT support in client software. You could build a tracker that serves peer data that it has cached from crawling the DHT, which is an idea I don't think has been done yet. As for a consensus mechanism, that should probably be done out of band and client software could be configured to query it and react appropriately. >Also, what happens when the key for singing torrents is stolen? In the case of a company using such a system, that situation can be handled but in a more decentralized system with an emphasis on long-term storage the loss of a key may be a bigger problem. With the JWT system, you can rotate keys, but it will break clients announcing with the old key. Users would have to manually update all their torrents to participate in the swarm again. This is a shame, but there is no official signing scheme in BitTorrent. If the JWT system as chihaya has implemented gathered traction, it could be updated such that clients could actually fetch JWTs regularly from an auth endpoint and then it'd be possible to handle rotation the same way as most OIDC implementations.
  - tmalsburg2 10y ago
    I like the idea of a tracker crawling the DHT. Research institutions could sign their torrents with their private keys and the tracker only indexes those signed with approved keys. Institutions register their public keys with the tracker and when an institution loses their keys, only their torrents are affected. Anyone can run such a tracker and there is no central authority. Nice. Is it possible to store signatures in torrent metadata?

tmalsburg2 10y ago

Very interesting. Does that mean that there would have to be a central authority that has to sign new torrents? For the present purpose that may not be ideal because this system wouldn't be decentralized, and one institution (or a small set of institutions) would have all control. Ideally, there would be some consensus mechanism that determines which torrents are bad and shouldn't be distributed. Also, what happens when the key for singing torrents is stolen? In the case of a company using such a system, that situation can be handled but in a more decentralized system with an emphasis on long-term storage the loss of a key may be a bigger problem.

jzelinskie 10y ago
>Does that mean that there would have to be a central authority that has to sign new torrents? In this scenario, the source of truth is the location where your users are acquiring their .torrent files. >For the present purpose that may not be ideal because this system wouldn't be decentralized, and one institution (or a small set of institutions) would have all control. Ideally, there would be some consensus mechanism that determines which torrents are bad and shouldn't be distributed. Trackers are the centralized alternative to using the Mainline BitTorrent DHT. The performance advantage significant enough they're still in common use after the ubiquity of DHT support in client software. You could build a tracker that serves peer data that it has cached from crawling the DHT, which is an idea I don't think has been done yet. As for a consensus mechanism, that should probably be done out of band and client software could be configured to query it and react appropriately. >Also, what happens when the key for singing torrents is stolen? In the case of a company using such a system, that situation can be handled but in a more decentralized system with an emphasis on long-term storage the loss of a key may be a bigger problem. With the JWT system, you can rotate keys, but it will break clients announcing with the old key. Users would have to manually update all their torrents to participate in the swarm again. This is a shame, but there is no official signing scheme in BitTorrent. If the JWT system as chihaya has implemented gathered traction, it could be updated such that clients could actually fetch JWTs regularly from an auth endpoint and then it'd be possible to handle rotation the same way as most OIDC implementations.
- tmalsburg2 10y ago
  I like the idea of a tracker crawling the DHT. Research institutions could sign their torrents with their private keys and the tracker only indexes those signed with approved keys. Institutions register their public keys with the tracker and when an institution loses their keys, only their torrents are affected. Anyone can run such a tracker and there is no central authority. Nice. Is it possible to store signatures in torrent metadata?