RSS/Atom Bittorrent Feed On Releases and Tags (Repos will be Bittorrent Tracker Servers? Every release will generate a torrent file and magnet link)

[trymeouteh]

trafficstars

Feature Description

To have every release and tag generate a .torrent file and magnet link which others can download to download the release and other details of the project.

Each torrent release will include the following details...

1. Compiled Binaries of the release
2. Source code of the release
3. Checksums for the release
4. Build instructions for the release
5. Main Page/Readme.md
6. Wiki pages (as markdown files)
7. And to support Bittorrent RSS/Atom feeds, by allowing users to add a simple URL of the repository to their Bittorrent RSS feed which will allow them to automatically download and seed new releases when a new release is made.

And each Gitea instance can come with a Bittorrent tracker server which can be used in each of the torrent releases as a tracker of the torrent.

Would be great to see this in Forgejo as well if it gets added to Gitea. And hopefully someday such a feature will be added to Github and Gitlab.

Screenshots

No response

[techknowlogick]

I think adding a tracker to Gitea itself might be a bit too much overhead for the server itself. Still, it might be possible to do something similar to what the Internet Archive does, where the files are served as torrents using webseeds, and then the trackers can be configured (or disabled entirely to rely solely on DHT). Things we'd need to consider:

• generating a torrent requires access to the files to create chunked hashes, so if files (release artifacts, LFS, etc.) are stored in S3, then the server would need to fetch all of them (requiring enough temporary storage space to store the files).
• probably have it be disabled by default in case some misconfigured crawler sees torrents and wants to fetch them all
• caching of the torrent files, so they don't need to be regenerated

These are thoughts off the top of my head, and it would need more investigation to see how it could be implemented, what the implications are, and feedback from folks with more experience with related technologies.

I'd be interested in hearing more about your use case. It seems like you'd end up with a lot of duplicated data if you feed the RSS feeds into a torrent client, and then the source code and wiki may largely be similar between releases. The release artifacts might be compiled versions for each architecture/os, so there could be a lot of data that you wouldn't use either. Perhaps you could be doing it seed to others in a geo-region close to you who might not have the best access to the server itself, and they could specifically disable files they don't want (as, of course, it's not a requirement to down 100% of the torrent).

[trymeouteh]

These are the use case

• Censorship resistant
  • P2P distribution of source code, documentation and releases
  • Allow anyone to easily archive repositories
• Reduce bandwidth
  • Redude bandwidth on Gitea instance server when someone downloads source code, releases

Even if this means a repo owner needs to enable bittorrent downloads on their repo and generate a .torrent file and magnet link for each release manually, that is better than nothing.

And even if enabling a tracker server on the Gitea instance is optional and is disabled by default is better than nothing.