This BIP describes a way to support custom services.
It is only at the draft stage and hasn't been updated in nearly a year.
A potential problem with the system is finding nodes that support a given custom service.
The addr message only gives information about the standard services field.
The BIP could be improved by changing the addr message to include custom services.
The core of the addr message is the Network Address field.
int: last_seen (timestamp)
long: services
byte[16]: ip address (ip4 uses only 4 of these)
short: port
Extra info could be added to the end.
var_int: count
char[count][11]: custom services
int[count]: custom service version
Also, the new custom service field in the version message should have a "discovery" flag. This indicates that the service requires discovery.
Each service uses at most 11 characters, so they could be fixed 11 character fields.
If there are no extra services, this adds 1 byte to the network address type.
A maximum number of services would have to be set to prevent spam. However, if an address is received with to many services, the list could simply be truncated.
If a maximum of 10 custom services were supported, then that adds 111 bytes extra to the address (up from 30).
The rule for truncating the list would be that early services are more important than later ones.
Nodes would sort their custom services. Only services that actually need discovery would be included in that list included in the addr message and the most important ones would occur earlier.