Return network_id upon initial websocket connection and/or in server_info

[intelliot]

Summary

Aside from the live XRP Ledger network (known as Mainnet), there are also a few test networks that are used for testing and development purposes. Ripple operates two such networks, called Testnet and Devnet. When using a client library, users can make the mistake of connecting to a Mainnet server when they intended to use a server on a test network, or vice versa. Also, users on wallets or explorers may mix up which network they are on. Since there is only one XRP Ledger network that involves real money and transfers real value (Mainnet), it is the only one that is important to distinguish. It is useful to know, and confirm, whether you are currently using the Mainnet versus any other test network.

Building on the X-address format (which uses a different prefix depending on whether the address is intended for use on Mainnet versus a test network), and https://github.com/ripple/rippled/pull/3049 * (which adds a network_id configuration option), this feature request proposes that the rippled server return the network_id via websockets when a client first connects, and/or includes the field in server_info responses.

A network_id of 0 or main indicates Mainnet. Any other value indicates a test network.

* Released in 1.5.0-b1 and 1.5.0 (commit).

Motivation

There are a few places in ripple-lib where we encode an X-address. If we don't know whether we are on Mainnet, then there is no way to know which prefix to use. Currently, the library assumes Mainnet and uses the 'X' prefix when parsing transactions. This will be 'fixed' by allowing the user to pass a parameter (indicating whether they are using Mainnet) when initializing a client, similar to what the SDK already does. However, users could still set the parameter to indicate Mainnet and still connect to a test network, since there is no way to check that the server is on the expected network.

While a malicious rippled server could always lie, having this feature would help users by eliminating accidental mixups.

Some developers figure out if they're on the wrong network by just observing whether their transaction fails, and then switching over. This could be dangerous when dealing with real money. If clients knew when they were connected to Mainnet, then a transaction involving a 'T' address could be easily and quickly rejected client-side, since it is certainly intended for a test network.

(Mainnet and test networks use the same transaction ID format, and if the same keys are used, it is theoretically possible for test transactions to run on Mainnet and vice versa.)

Solution

Return the network_id to clients when they first connect via websockets.

Alternatively, or additionally, the network_id field can be included in server_info responses.

This tells the client which network the server is configured to follow.

Paths Not Taken

We could argue this isn't useful because servers can lie. But that clearly isn't the case, since the same applies to everything that rippled returns. If the server lies, it's of no more consequence than it misbehaving in other ways. The goal here is to improve the user / developer experience, and this feature would. Admittedly, it's not a big deal as it just helps to catch mistakes. So, I suggest that this is a low-priority request.

With this feature, clients could theoretically "auto-detect" which network they are on. I do not recommend this. Rather, this feature should be used as an additional check; it allows clients to detect a mismatch, and report an error to the user.

[ckeshava]

Hello, Can you please further explain the first proposed solution? What do you mean by clients connecting to websockets -- Are you referring to the RPC calls that can executed like ./rippled server_info ?

Regarding the second proposed solution, we would like to see network_id in the output of ./rippled server_info command right?

[drlongle]

We can close this issue.

./rippled --conf ~/config/rippled-example.cfg server_info
2023-Mar-03 15:22:57.395057070 UTC HTTPClient:NFO Connecting to 127.0.0.1:5005

{
   "result" : {
      "info" : {
         "build_version" : "1.10.0-rc3",
         ...,
         "network_id" : 2,
         ...,
      },
   "status" : "success"
}

[intelliot]

Resolved by e46d2bcf276368e5751003351d4e9ccddd232eaa and released in version 1.9.2.