I2P Address: [http://git.idk.i2p]

Skip to content

add user-configurable expire-time to blocklists.

idk requested to merge idk/i2p.i2p:i2p.i2p.2.2.1-blocklist-expiration into master

This adds a new config setting, router.blocklist.expireInterval, which causes the blocklist entries to expire at a fixed interval. It is off by default. It may have a value of time in milliseconds, or time with a unit, e.g. 1d, 2m, 6h, etc, or 0. 0 means off. If configured, it runs a job when the interval is reached, which completely clears out the blocklist. The blocklist can still be used for new entries.

The precise behavior is as follows:

  • When a router is added to the transient blocklist, it is given an IP block which expires either at the next router.blocklist.expireInterval or when the router is restarted.
  • When a router is added to the banlist, it is given an expiration of either 'forever'(0) or a delay in milliseconds, equal to router.blocklist.expireInterval

So transient blocklist entries will all expire at the same time, an event which is scheduled after the router is started and run at regular intervals. Peers which are banned because their IP is in the blocklist, on the other hand, are scheduled to be un-banned relative to the time which they were banned at.

Use cases:

  • Prevent the blocklist signer(currently me) from having too much and/or permanent power by limiting the time that blocklist entries are applied user-side
  • Cause the blocklist to be emptied regularly in order to remove entries which were generated as part of an automatic process(i.e. the sybil tool) that may have become irrelevant

This is just adding a knob to the blocklist behavior, and it's just one knob. It could be that we need more way to configure this, for instance:

  • Cull only a fraction of the blocklist(And how? Randomly? From the bottom? From the top? Do we order them by date) at the fixed interval
  • Trigger a cleaning on specific thresholds being met
  • etc.

Merge request reports

Loading