Interledger Rust Alpha Release + Xpring Testnet Nodes

Today we announced the alpha release of the Interledger.rs node and testnet nodes hosted by Xpring: https://coil.com/p/xpring/Interledger-Rust-Alpha-Release/kqcXwUOHs

If you’re interested in trying it out, you can find the instructions for running a node and connecting to the testnet here.

You can download a docker image that contains the:

  • ilp-node
  • ilp-cli (for interacting with the node’s HTTP API)
  • XRP and ETH settlement engines
  • redis
  • localtunnel

And you can connect to the testnet with a single command.

Feedback is very welcome!

Also, get in touch if you’re interested in getting involved with the Interledger.rs project. We are happy to mentor new contributors through making their first submission – even if you haven’t worked in Rust before.

2 Likes

Hi, I start the bundle like:

docker run -itd --name ibanfi01 -e NAME=ibanfi01 -e CURRENCY=XRP -e ADMIN_AUTH_TOKEN=admin interledgerrs/testnet-bundle

The environment is a Linux VM (CentOS 7, vagrant). The container started successfully but the sync between the local and the testnet account has failed. The correponding log entries:

Configuring node to connect to testnet using XRP...
Creating account: ibanfi01
[DEBUG interledger_store_redis::store] Generated account id for ibanfi01: 108c150b-b730-449c-8082-54254cc453b8
[DEBUG interledger_store_redis::store] Inserted account 108c150b-b730-449c-8082-54254cc453b8 (ILP address: local.host.ibanfi01)
[INFO  warp::filters::log] 127.0.0.1:37994 "POST /accounts/ HTTP/1.1" 200 "-" "reqwest/0.9.22" 2.131432ms
[DEBUG interledger_store_redis::store] Setting settlement engines to [("ETH", "http://localhost:3002/"), ("XRP", "http://localhost:3001/")]
your url is: https://ibanfi01.localtunnel.me
[2019-10-22T13:23:05Z DEBUG interledger_settlement_engines::engines::ethereum_ledger::eth_engine] [Addresses { own_address: 0x3cdb3d9e1b74692bb1e3bb5fc81938151ca64b02, token_address: None }] settlement engine service for listening to incoming settlements. Interval: 15s
[2019-10-22T13:23:05Z INFO  interledger_settlement_engines::engines::ethereum_ledger::eth_engine] Ethereum Settlement Engine listening on: 127.0.0.1:3002
[DEBUG interledger_service_util::exchange_rates_service] Updated 266 exchange rates from CoinCap
  settlement-xrp Generated new XRP testnet account: address=rsjRe1HPNWB49eD3khBS7ECTvxnQ8C2rZQ secret=sh5kXw9mmkAuCzvTNtmyVHcdGSNtN +0ms
  settlement-core Started settlement engine server +0ms
[INFO  warp::filters::log] 127.0.0.1:37996 "PUT /settlement/engines HTTP/1.1" 200 "-" "reqwest/0.9.22" 9.062459799s
Connecting to the Xpring Testnet node...
[DEBUG interledger_store_redis::store] Generated account id for xpring_xrp: f44d1715-ef7e-444b-b029-3b6e525e0e37
[DEBUG interledger_store_redis::store] Inserted account f44d1715-ef7e-444b-b029-3b6e525e0e37 (ILP address: local.host.xpring_xrp)
[DEBUG interledger_btp::client] Connecting to wss://rs3.xpring.dev/ilp/btp
[DEBUG interledger_btp::client] Connected to account f44d1715-ef7e-444b-b029-3b6e525e0e37's server
[DEBUG interledger_api::routes::accounts] Getting ILP address from parent account: xpring_xrp (id: f44d1715-ef7e-444b-b029-3b6e525e0e37)
[DEBUG interledger_btp::service] Unable to parse ILP packet from BTP packet (if this is the first time this appears, the packet was probably the auth response)
[DEBUG interledger_api::routes::accounts] Got ILDCP response from parent: Ok(IldcpResponse { ilp_address: "Address("test.xpring-dev.rs3.user_aluuuhdl")", asset_code: "XRP", asset_scale: 9 })
[DEBUG interledger_api::routes::accounts] ILP address is now: test.xpring-dev.rs3.user_aluuuhdl
[DEBUG interledger_api::routes::accounts] Asking for routes from Account { id: AccountId(f44d1715-ef7e-444b-b029-3b6e525e0e37), username: Username("xpring_xrp"), ilp_address: Address("local.host.xpring_xrp"), asset_code: "XRP", asset_scale: 9, max_packet_amount: 18446744073709551615, min_balance: None, ilp_over_http_url: Some("https://rs3.xpring.dev/ilp"), ilp_over_http_incoming_token: None, ilp_over_http_outgoing_token: Some(SecretBytes(...)), ilp_over_btp_url: Some("btp+wss://rs3.xpring.dev/ilp/btp"), ilp_over_btp_incoming_token: None, ilp_over_btp_outgoing_token: Some(SecretBytes(...)), settle_threshold: Some(1000), settle_to: Some(0), routing_relation: Parent, round_trip_time: 500, packets_per_minute_limit: None, amount_per_minute_limit: None, settlement_engine_url: None }
[DEBUG interledger_store_redis::store] Setting ILP address to: test.xpring-dev.rs3.user_aluuuhdl
[DEBUG interledger_store_redis::store] Set default route to account id: f44d1715-ef7e-444b-b029-3b6e525e0e37
[DEBUG interledger_ccp::server] Got route update request from account f44d1715-ef7e-444b-b029-3b6e525e0e37: RouteUpdateRequest { routing_table_id: "7280c86eee6dd0e8b03fa6f60dc39aa7", current_epoch_index: 547, from_epoch_index: 0, to_epoch_index: 547, hold_down_time: 30000, speaker: Address("test.xpring-dev.rs3"), new_routes: [Route { prefix: "test.xpring-dev.rs3", path: [], auth: "0000000000000000000000000000000000000000000000000000000000000000", props: [] }], withdrawn_routes: [] }
[WARN  interledger_ccp::server] Got route for a different global prefix: Route { prefix: "test.xpring-dev.rs3", path: [], auth: "0000000000000000000000000000000000000000000000000000000000000000", props: [] }
[INFO  warp::filters::log] 127.0.0.1:38108 "POST /accounts/ HTTP/1.1" 200 "-" "reqwest/0.9.22" 2.458040922s
Setting up the nodes to use HTTP for bilateral communication...
[INFO  warp::filters::log] 127.0.0.1:38118 "PUT /accounts/xpring_xrp/settings HTTP/1.1" 200 "-" "reqwest/0.9.22" 779.548µs
ILP CLI error: Unexpected response from server: 401 Unauthorized:
Error: Command failed: ilp-cli --node=https://rs3.xpring.dev accounts update-settings user_aluuuhdl             --auth=user_aluuuhdl:2v2q6lpcgunu2             --ilp-over-http-incoming-token=750d48ed62db62f3732d0df37be8350ad85e78c9             --ilp-over-http-outgoing-token=xpring_xrp:750d48ed62db62f3732d0df37be8350ad85e78c9             --ilp-over-http-url=https://ibanfi01.localtunnel.me/ilp             --settle-threshold=1000             --settle-to=0
ILP CLI error: Unexpected response from server: 401 Unauthorized:

    at checkExecSyncError (child_process.js:621:11)
    at execSync (child_process.js:657:15)
    at run (/opt/app/run-testnet-bundle.js:64:9) {
  status: 1,
  signal: null,

I tried to run these calls in Postman. I used the same user parameters as bearer token (user_aluuuhdl:2v2q6lpcgunu2) on the https://rs3.xpring.dev node. Both the GET and the PUT were success, I got back the entire account record.

The calls are:
GET rs3.xpring.dev/accounts/user_aluuuhdl
PUT rs3.xpring.dev/accounts/user_aluuuhdl/settings

(With https:// of course, but I’m a new user, I cannot put more than 2 links into the post :-/ )

{
	"ilp-overhttp_incoming_token":"750d48ed62db62f3732d0df37be8350ad85e78c9",
	"ilp_over_http_outgoing_token":"xpring_xrp:750d48ed62db62f3732d0df37be8350ad85e78c9",
	"ilp_over_http_url":"https://ibanfi01.localtunnel.me/ilp",
	"settle_threshold":1000,
	"settle_to": 0	
}

Crosscheck

I went inside the container (docker exec -it ibanfi01 /bin/sh) and ran these commands:

ilp-cli --node=https://rs3.xpring.dev accounts update-settings user_aluuuhdl --auth=user_aluuuhdl:2v2q6lpcgunu2
// it is OK, I got back the entire record
ilp-cli --node=https://rs3.xpring.dev accounts update-settings user_aluuuhdl --auth=user_aluuuhdl:2v2q6lpcgunu2 --settle-to=0
// ILP CLI error: Unexpected response from server: 401 Unauthorized:

Additional info

I don’t know whether or not it is interesting, but when I’ve screwed the Postman PUT JSON (it becames invalid), I got exactly the same error msg (401 Unauthorized) from the remote server.

Hi, I’ve localised the problem: The ilp-cli converts the integer parameter to string. I put the ```I wrote the exact JSON string here.

The first call is --settle-to=0, it must be integer (Failed):

Running `/opt/projects/target/debug/ilp-cli '--node=https://rs3.xpring.dev' accounts update-settings user_aluuuhdl '--auth=user_aluuuhdl:2v2q6lpcgunu2' --settle-to=0`
Request: {"settle_to": "0"}
ILP CLI error: Unexpected response from server: 401 Unauthorized: 

The second call is --ilp-over-http-incoming-token=750d48ed62db62f3732d0df37be8350ad85e78c9, it must be string (success):

Running `/opt/projects/target/debug/ilp-cli '--node=https://rs3.xpring.dev' accounts update-settings user_aluuuhdl '--auth=user_aluuuhdl:2v2q6lpcgunu2' --ilp-over-http-incoming-token=750d48ed62db62f3732d0df37be8350ad85e78c9`
Request:  {"ilp_over_http_incoming_token": "750d48ed62db62f3732d0df37be8350ad85e78c9"}
{"id":"5483e945-4a4d-4152-8ea6-587e1f2ea28b","username":"user_aluuuhdl","ilp_address":"test.xpring-dev.rs3.user_aluuuhdl","asset_code":"XRP","asset_scale":9,"max_packet_amount":1000,"min_balance":null,"ilp_over_http_url":"https://ibanfi01.localtunnel.me/ilp","ilp_over_http_incoming_token":"SECRET","ilp_over_http_outgoing_token":"SECRET","ilp_over_btp_url":null,"ilp_over_btp_incoming_token":"SECRET","ilp_over_btp_outgoing_token":"SECRET","settle_threshold":1000,"settle_to":0,"routing_relation":"Child","round_trip_time":500,"packets_per_minute_limit":null,"amount_per_minute_limit":null,"settlement_engine_url":"http://settlement-xrp1-internal.xpring.dev:3000/"}

(Sorry, I’m a beginner in Rust, I don’t know how to fix it yet)

Hi @ibanfi, thanks for reporting this! Don’t worry about needing to fix it yourself, we’ve determined that the fix needs to take place on our end. Specifically, you’re using a recent version of ilp-cli whereas our testnet is using a slightly older version of ilp-node. Whereas recent versions of ilp-node can receive either string or integer parameters for settle_to, old versions could only handle integer parameters. When ilp-node was update to also accept string parameters, support for sending integer parameters was removed from ilp-cli, without realizing that the testnet was still on the old version. In the future we’ll anticipate needing to support older versions of ilp-node in the wild and will handle changes like this more gracefully (for example, we could have added string support to ilp-node without removing integer support from ilp-cli, which would have prevented this issue).

In the meantime we’ll work on getting the testnet updated to a recent version that doesn’t exhibit this behavior. I don’t have an ETA at the moment for when this will be done, but if the infrastructure team gives me an estimate I’ll try to pass it on to you.

2 Likes

Update: I hear tell that we’re preparing for a testnet update next week to coincide with a major hackathon we’re holding, so this should be fixed within a week.

1 Like