discv5: consider that clients may want to advertise servers

[FrankSzendzielarz]

Until there is a reward system for nodes like LES servers, it is not really in the interests of servers to participate in 'proof of time' or 'proof of work' to place ads. Someone running a node may be deterred from enabling these discovery or LES server features.

However, a business developing a consumer application that needs to find servers, for example a mobile phone app running a light client, there is strong incentive for those clients to support each other in whatever ways possible to find the servers.

The onus is essentially on clients to advertise discovered servers (again, as long as there is no reward system in place).

One way of doing this could be for the clients to form their own overlay network and share information privately. Other ways could involve a common, shared scheme. One such common scheme could be the Topic Discovery subsystem: We can consider modifying the protocol so that clients can register servers (or in general, allow ads to be placed about someone else.)

[FrankSzendzielarz]

Notes:

• Clients can place ads on themselves without any need for ReqTicket or RegTopic, thus bypassing any proof-of-X systems, and this mechanism is available even in the currently proposed system
• Clients will be far more numerous than mainnet nodes. While there may be 10000 mainnet nodes, if light servers and layer-2 scaling solutions become stable and popular, there could be many millions of client nodes.
• In this context node advert location will be fairly transient
• Clients can take advantage of the communal topic system while maintaining private exclusivity by simply advertising proprietary topic names. Eg: a client implementation, of which there are 500,000 instances on Android, could identify LES servers using the code 'XYZ123' , and attempt to prevent other apps from benefiting from that knowledge
• Spam adverts in this context would be a relatively minor problem for applications that are well adopted with many thousands of active installations.

[FrankSzendzielarz]

To clarify the above comment:

1. In a situation with many more clients than servers, and where clients are fairly transient, the close radius around a topic hash may likely contain many transient nodes
2. Applications (eg: mobile apps) may have their own implementations that simply take all LES servers they discover and advertise on their own local 'queue' (which might not even be a queue, just a dummy version of the API returning ENRs) so that other app installations can, when they discover and verify the LES server by any means, advertise it further in the same way, thus causing a viral spread of what the [popular] app requires. I am not suggesting this is necessarily an issue.