-
Notifications
You must be signed in to change notification settings - Fork 25
Home
After the metadata manifest is implemented, add functionality to timestamp the manifest using opentimestamps or similar, and include the receipt file in the release alongside the manifest.
This might be useful for the following reasons:
-
It can prove that the contents existed as of a certain point in the past. I.e. that they were not created at a later date and then backdated.
-
If a release is signed with keys that are later revoked or compromised at a known date, but the release is timestamped before that date, it indicates that the signature is trustworthy, even though the keys have been revoked.
I'd like to add the ability to optionally sign releases, both so releases can be authenticated as having come from a particular person, and to allow releases to be updated in the future. Such updates would be opt-in on the part of recipients. The purpose of signatures would be to verify that the update was coming from the original creator of the release, or some other trusted party, not to implement a forced "auto-update" mechanism.
Bitcoin hardware wallets make managing public keys trivial, so it seems ideal to have a dedicated trezor/ledger app that would allow a user to sign releases with their key.
Many torrent indices implement a ratio tracking system, to encourage seeding. It would be nice to implement this with a Chaumian bank style setup, such that the index hands out upload credits, but cannot link upload credits to particular users. This idea is very half-baked. Danake looks like it might be a good fit for the credit system.
It would be nice to allow users to run a torrent index that is completely private to them, allowing them to share their own content between devices. This could be done by allowing them to self-host the index, but the public instance could also allow users to register private or encrypted torrents for personal use only.
When users create an intermodal torrent and add an intermodal tracker announce URL, the tracker should report an interested peer when they first announce the torrent. This peer would be the the tracker itself, which should connect to the user's peer, download the intermodal manifest, and parse it and add it to the torrent index. This would allow users to add torrents to the index without doing anything more than adding it to their client. This would be especially useful if you wanted to add a torrent to a large number of indices a the same time.
Chat bots which watch for new torrents and announce new releases in Discord/IRC/etc.
I'd like to make imdl.io a great place for a wide variety of free content. Some ideas for sources of free content:
- Project Gutenberg
- WASM Apps
- Flash Games
- sfv file creation and verification
- usenet downloading
- usenet uploading
- nzb file creation/verification/display
- rar compression/decompression
- ReScene file creation and use
- implementation of BEPs
- a bittorrent tracker (i.e. respond to client requests for IP addresses)
- a bittorrent client (this is a huge piece of work!)
- hammering out details of release schemas. (For example, for flash content, do we need metadata saying what version of flash the game is compatible with?, For plain text releases, do we need metadata saying whether the client should wrap the content, or if it is formatted to a particular line width?)
- Pay for web downloads of HTTP or BitTorrent content