The FloodFill (sometimes referred to as "FF") flag, represented in Router Info interfaces by the letter "f," allows an I2P Router to store and serve the temporary LeaseSets that tell other routers how to reach particular Destinations on I2P, whether those destinations are websites, IRC servers, BitTorrent peers, or any other services or application clients on the network. Collectively, the FloodFill routers are a bit like a phonebook directory, but one whose entries are updated with a new number every ten minutes. Note that this is distinct from a router's Address Book, which performs a similar function, but with long-lived (usually permanent) b64 addresses and their corresponding Names. Each FloodFill router only stores a portion of the total LeaseSets and Destinations on the network, and only serves some of the requests it receives. Together, though, the full set of FloodFill routers can generally serve LeaseSets for any desired service, so long as that service is up and in contact with at least one FloodFill router. The group of FloodFill routers, which usually constitute between 1-5% of the network [can we get more accurate?], stay synchronized with one another and are able to relay requests from peers and responses from other FloodFill routers via a modified KademliaDistributed Hash Table (or "DHT").
Role in the network
FloodFill routers are incredibly important and useful to the I2P network and its users, and without them, I2P as we know it would not function. For that reason, all I2P users are encouraged to help their routers to become FloodFill - see "Selection and Requirements," below.
[...more specific information about what FloodFills do and how they work goes here...]
Selection and Requirements
Any I2P router can opt in or out of becoming FloodFill via I2P's Advanced Configuration, but opting in does not guarantee that the router will have or obtain this flag. Only routers that meet certain criteria, as profiled by their peers, are eligible to actually start serving in the FloodFill role. These criteria may include:
Good [uptime](http://wiki.i2p-projekt.i2p/wiki/index.php?title=Uptime&action=edit&redlink=1)
Sufficient [bandwidth](http://wiki.i2p-projekt.i2p/wiki/index.php?title=Bandwidth&action=edit&redlink=1) ([Class L](http://wiki.i2p-projekt.i2p/wiki/index.php?title=Bandwidth&action=edit&redlink=1) or greater)
Low [Job Lag](http://wiki.i2p-projekt.i2p/wiki/index.php?title=Job_Lag&action=edit&redlink=1) and [Message Delay](http://wiki.i2p-projekt.i2p/wiki/index.php?title=Message_Delay&action=edit&redlink=1)
A good record of successful [participating tunnels](http://wiki.i2p-projekt.i2p/wiki/index.php?title=Participating_tunnels&action=edit&redlink=1)
Not set to be using "[Laptop mode](http://wiki.i2p-projekt.i2p/wiki/index.php?title=Laptop_mode&action=edit&redlink=1)"
[others?]
Performance
Because a FloodFill router must take on increased traffic and tasks from both the rest of the FloodFill network and the individual I2P routers querying the FloodFill network for LeaseSets, they generally use more system resources (bandwidth and CPU time) than a comparable router that is not FloodFill. However, this added overhead is usually not very significant on modern systems using a good, high-speed connection, but may be a concern on less powerful or bandwidth-restricted systems.
History
Early in I2P's history, the role of FloodFills was performed entirely by three specific routers whose identities were hard-coded into the I2P application. This was always known to be little more than a stopgap measure. Over time [when and which versions?], the design and implementation of the modern FloodFill DHT system replaced this paradigm and allowed the network to scale much more readily, and avoid the consequences of FloodFills being overloaded or down [who helped with that wonderful development?].
...
With version 0.9.20, released in early June, 2015, Class "L" routers (shared bandwidth of 32-64kBps) became eligible to be FloodFill for the first time, increasing the number of available FloodFill routers on the network and improving FloodFill performance, which was a concern at the time due to the rapid expansion of the Vuze BitTorrent client's I2P plugin that had pushed the capacity of the existing FloodFill group towards its limits.
Introduction
The FloodFill (sometimes referred to as "FF") flag, represented in Router Info interfaces by the letter "f," allows an I2P Router to store and serve the temporary LeaseSets that tell other routers how to reach particular Destinations on I2P, whether those destinations are websites, IRC servers, BitTorrent peers, or any other services or application clients on the network. Collectively, the FloodFill routers are a bit like a phonebook directory, but one whose entries are updated with a new number every ten minutes. Note that this is distinct from a router's Address Book, which performs a similar function, but with long-lived (usually permanent) b64 addresses and their corresponding Names. Each FloodFill router only stores a portion of the total LeaseSets and Destinations on the network, and only serves some of the requests it receives. Together, though, the full set of FloodFill routers can generally serve LeaseSets for any desired service, so long as that service is up and in contact with at least one FloodFill router. The group of FloodFill routers, which usually constitute between 1-5% of the network [can we get more accurate?], stay synchronized with one another and are able to relay requests from peers and responses from other FloodFill routers via a modified Kademlia Distributed Hash Table (or "DHT"). Role in the network
FloodFill routers are incredibly important and useful to the I2P network and its users, and without them, I2P as we know it would not function. For that reason, all I2P users are encouraged to help their routers to become FloodFill - see "Selection and Requirements," below.
[...more specific information about what FloodFills do and how they work goes here...] Selection and Requirements
Any I2P router can opt in or out of becoming FloodFill via I2P's Advanced Configuration, but opting in does not guarantee that the router will have or obtain this flag. Only routers that meet certain criteria, as profiled by their peers, are eligible to actually start serving in the FloodFill role. These criteria may include:
[others?] Performance
Because a FloodFill router must take on increased traffic and tasks from both the rest of the FloodFill network and the individual I2P routers querying the FloodFill network for LeaseSets, they generally use more system resources (bandwidth and CPU time) than a comparable router that is not FloodFill. However, this added overhead is usually not very significant on modern systems using a good, high-speed connection, but may be a concern on less powerful or bandwidth-restricted systems. History
Early in I2P's history, the role of FloodFills was performed entirely by three specific routers whose identities were hard-coded into the I2P application. This was always known to be little more than a stopgap measure. Over time [when and which versions?], the design and implementation of the modern FloodFill DHT system replaced this paradigm and allowed the network to scale much more readily, and avoid the consequences of FloodFills being overloaded or down [who helped with that wonderful development?].
...
With version 0.9.20, released in early June, 2015, Class "L" routers (shared bandwidth of 32-64kBps) became eligible to be FloodFill for the first time, increasing the number of available FloodFill routers on the network and improving FloodFill performance, which was a concern at the time due to the rapid expansion of the Vuze BitTorrent client's I2P plugin that had pushed the capacity of the existing FloodFill group towards its limits.