JSON-RPC endpoints

[ogenev]

Currently, on discv5 layer, we are supporting only discv5_NodeInfo and discv5_RoutingTableInfo json-rpc endpoints. Nick mentioned this API example in ddht.
Do we want to support most of the endpoints there if not all of them?

What about the dummy node in the testing framework, is there any json-rpc endpoint that we don't want to expose in the release candidate version, but we want to use it for dev work and testing purposes only?

[njgheorghita]

Just a thought, now that we have a single jsonrpc server, it seems useful (especially during testing / testnet setup) to support endpoints that are subnet specific. i.e...

• discv5_routingTableInfo for the base layer discv5 protocol
• history_routingTableInfo for the history subnet overlay network
• ... etc

[njgheorghita]

What about the dummy node in the testing framework, is there any json-rpc endpoint that we don't want to expose in the release candidate version, but we want to use it for dev work and testing purposes only?

I wouldn't think so. Potentially there are some security implications down the road by exposing this api on the trin node - but we can always remove them later. At least while we're still in the development / early testnet stage - I'd much rather have access to these endpoints on the main trin node - rather than having to handle the dummy node every time I want to use these.

checklist & priority (imo)

• discv5_routingTableInfo (already implemented on base - high priority for overlay)
• discv5_nodeInfo
• discv5_updateNodeInfo(low)
• discv5_setENR (med)
• discv5_getENR (low)
• discv5_deleteENR (low)
• discv5_lookupENR (low)
• discv5_sendPing (med)
• discv5_sendPong (low)
• discv5_sendFindNodes (med)
• discv5_sendFoundNodes(med)
• discv5_sendTalkRequest (med)
• discv5_sendTalkResponse(med)
• discv5_ping (high)
• discv5_findNodes (high)
• discv5_talk (high)
• discv5_recursiveFindNodes (med)
• discv5_bond (med)

Overlay network endpoints

Imo, these endpoints for subnetworks are even more valuable for testing/dev than for simply the base discovery layer. I'm particular partial to a jsonrpc api that mimics the above api except with different prefixes (eg. history_ping for a history network ping/pong round trip or state_ping for state network). It at least seems cleaner to me than adding a parameter for the subnetwork (eg. (discv5_ping, ['state', enr]) - but there might be some unintended consequences I'm missing.

So, imo I'd prioritize the round trip messages (discv5_ping, discv5_findNodes, discv5_talk) for the base layer discovery and each overlay network. As well as discv5_routingTableInfo for the overlay networks (it's already supported for base discovery)

[pipermerriam]

maybe worth full namespacing as portalHistory_xxxXXX and portalState_xxxXXX

[ogenev]

Looking into it now, do we have use cases where we would like to send base layer discv5 ping/pong messages?

[pipermerriam]

do we have use cases where we would like to send base layer discv5 ping/pong messages?

I don't have a good answer for you here. I don't think we have an immediate use case for these endpoints because we don't have a live network that we can play with yet. That suggests we could stub them out or just leave them not implemented for the time being if there is any other work that can be done that is higher priority. Until we are actually using them for something, YAGNI may be the right approach.

To answer the question that was asked... If any of the PING/PONG messages are useful for us in the sub-protocols, then we'll very likely want the ability to do the same in the base protocol. For example, sending a Ping in the base protocol will allow us to get our externally visable IP address back from the ping'd node. Sending a ping will let us trigger "bonding" with another node in the network. Ping lets us scan the network and see what nodes are reachable/alive.

[ogenev]

Not relevant anymore