[Feature] allow multiple --reseed-from entries

[wqking]

Currently the .su3 seed file name "i2pseeds.su3" and the predefined download hosts are hard coded in client/reseed.h.

That has two potential issues,
1, We can't modify the file name and the hosts without upgrade the tool.
2, More serious, in some countries such as China which I2P websites are banned, it's impossible (or very hard without VPN) to download from the predefined hosts. To make Monero/Kovri popular in such countries, we may expect that there are many "private seed servers". Then it's hard to use the "private seed servers" by default if we can't put all of them in config file.

I saw there is "reseed-from" entry in the config, but the issue is that it only supports one server. It's better to support multiple servers and the tool chooses the working server and abandons the banned server.

My suggestions,
1, Make "reseed-from" entry in the config be able to be multiple, such as "reseed-from-0", "reseed-from-1", etc.
2, If there is no any "reseed-from", or all "reseed-from"s don't work, the hard coded servers are used.

I'm happy to do it if we confirm it.

---

By submitting this issue, I confirm the following:

• I have read and understood the contributor guide in kovri-docs.
• I have checked that the issue I am reporting can be replicated or that the feature I am suggesting is not present.
• I have checked opened or recently closed pull requests for existing solutions/implementations to my issue/suggestion.

---

[anonimal]

Currently the .su3 seed file name "i2pseeds.su3"

Yes, this is spec defined and there is no reason to change it.

1, We can't modify the file name and the hosts without upgrade the tool.

Yes, this is an intentional security measure.

2, More serious, in some countries such as China which I2P websites are banned, it's impossible (or very hard without VPN) to download from the predefined hosts. To make Monero/Kovri popular in such countries, we may expect that there are many "private seed servers". Then it's hard to use the "private seed servers" by default if we can't put all of them in config file.

Yes, this is one of the reasons I implemented the feature in the first place. You can reseed from any server which hosts an su3 file. This su3 file can have any name, and can have any address so long as it's resolvable. You can even reseed local files without the need for resolution. This is all done with --reseed-from and --disable-su3-verification. See the config file for details.

1, Make "reseed-from" entry in the config be able to be multiple, such as "reseed-from-0", "reseed-from-1", etc.

Bad idea, too cumbersome. We can simply do CSV, e.g., --reseed-from host1.tld,host2.tld,host3.tld. This should be trivial to implement.

[wqking]

We can simply do CSV, e.g., --reseed-from host1.tld,host2.tld,host3.tld. This should be trivial to implement.

Let's think about a very realism use case. In a country where all public known I2P seeds sites are banned, the users just spread a lot of private servers on the forums. The other users copy the server lists and paste into their config file. The list may become longer and longer, then the CSV format is not manageable any more.
Of course reseed-from-0 is not the best solution, but may be more user friendly, and we can always treat reseed-from (without the number) as a special option.
We may start with the CSV solution, then in the future we may add multiple --reseed-from according to the feedback from the users.

[anonimal]

The list may become longer and longer, then the CSV format is not manageable any more.

At that point, the solution is not to use reseed in this manner. We can also simply reseed from a database file, whether CSV or other.

Of course reseed-from-0 is not the best solution, but may be more user friendly

I have no idea how this would be user-friendly. No one uses cli options like this.

--reseed-from according to the feedback from the users.

Multiple --reseed-from sounds fine but it's also an unnecessary hassle to deal with (see boost.program_options).

[anonimal]

NOTICE: THIS ISSUE HAS BEEN MOVED TO GitLab. Please continue the discussion there. See #1013 for details.