Open josecelano opened 7 months ago
@da2ce7 should we include non-standard fields like this? or only fields included in official BEPs?
@josecelano I think that we should have a set of "community" info dictionary schemas; some sort of whitelist format. In general if we find the format unofficial format somehow useful and not abusive; then I think that we should be quick to accept a new schema into our whitelist.
This white-list could be controlled by the configuration of the index.
@josecelano I think that we should have a set of "community" info dictionary schemas; some sort of whitelist format. In general if we find the format unofficial format somehow useful and not abusive; then I think that we should be quick to accept a new schema into our whitelist.
This white-list could be controlled by the configuration of the index.
Hi @da2ce7 do you mean the white-list should be dynamically injected as configuration at run time? We have to change a lot of things to allow that:
For now, I would just add it, and add a schema with what we consider a "valid" torrent.
In the future, we could implement those changes. I think those changes could also be good for other reasons:
Hi, I've been testing using BiglyBT. I wanted to add some test torrents to the demo and seed them. BiglyBT includes a non-standard field in the torrent
info
dict. The field isname.utf-8
. For example:Since it's not a standard field, the Index removes it, which changes the torrent infohash (hash for the
info
dictionary). If you want to seed the torrent, the process would be:Check Files Exist
.I think that process is excruciating, but maybe it's just me. I recommend adding non-standard fields in the
info
dict to the Index to avoid changing the infohash.I have not checked all of them yet; it seems Transmission does not include any non-standard field.
cc @torrust/maintainers