Walled Garden Connector

Yes, strange title lol - I am rebuilding AOL.com! j/k :laughing:

My question has to do with a scenario where you have only ONE CONNECTOR and multiple accounts.

It is my understanding that once that connector receives a PreparePacket it will look to its routes and determine if it needs to forward. Because it is local it will adjust the store balance.

To illustrate further, you have two accounts on that single connector backend:

Account-B
Account-A

Then from a client application you craft a PreparePacket to fire at the Connector. The packet contains the auth token for Account-B and the to: as Account-A.

Technically this seems to be allowed as the routing checks resolve local - no forward.

Please confirm I should see a local transfer take place.

Yeah, the connector should be able to forward the packet. Although I don’t know what you mean by “local transfer” exactly. If you’re referring to settlement then it is unlikely that a single ILP packet will trigger settlement but it depends on configuration. Hope this answers your question

This is more a test bed hacker type thing. There is only one connector.

In a command line app I simply connect raw socket to the /ilp route and send a packet crafted with the auth token of one user and the rest of the PrepareBuilder details to the other local connector account.

Once that connector receives the packet, there is no where to forward since the addresses are local to that single connector.

Yes I would expect the balance to change in the underlying store. I would not call this true settlement but I suppose it could be termed that even without a ledger.

The part I am trying to discover is if I can make the local transfer by crafting an authorized packet.

It sounds like you might be talking about the rust connector, which I’m not very familiar with the abstractions of.

You can have multiple addresses under a single connector, for instance a connector which accepts connections on two ‘child’ accounts, but I don’t know if that’s the topology you’re running.

Running moneyd local is an example of a single-connector topology, and you can still run SPSP sender/receivers or anything else that runs on ILP.

yes you are correct - I am in the rust connector, I recall seeing this occur in moneyd local in nodejs but I suspect now it was using SPSP.

I don’t know the details of the rust connector, maybe @emschwartzcan help here but generically, what you want to do is possible.

When you connect to the connector as Account-A or Account-B the first thing you will need to do is:
a) get an address which is a sub-address of that connector’s address, or
b) make the connector aware of your address

The most likely scenario is a) so imagine the connector has the address test.connector, you connect using the credentials of Account-A and perform an IL-DCP query to get your own address. This is returned as something like: test.connector.account-a.

You would repeat the same process for Account-B and likely have an address like: test.connector.account-b.

Now if you are connected as Account-A and send packets addressed to test.connector.account-b they will be routed to the entity connected as Account-B.

Note that the internal routing table of the connector should track the lifecycle of peer connections. If a connection to a peer is down then the connector should remove routes to that peer (and possibly replace them with routes via another peer if it is aware of these).

The only time a connector routes a packet to itself is if it able to fulfil that packet (not a scenario I’ve seen implemented in any connectors) or if the packet is being used for a protocol like the Echo protocol for network analysis.

@fractal-synapse in order to have the receiving account fulfill the packet, you’ll probably want to use higher level protocols like STREAM and SPSP.

To send a local payment on the Rust implementation, you would send an HTTP request to /pay with the receiver field set to the SPSP URL of the other account (something like http://localhost:7770/spsp/2 where 2 is the AccountId of the receiving account.

Note: the Rust implementation’s HTTP API is not yet stable so the exact API calls and paths may change in the future.

Agreed, I am in a research phase to grok ILP packets at the lower layers, then I will layer in the goodness of higher level abstractions after I understand the foundations of the protocol.

I am however getting a bit further in this test now by firing manually crafted packets into the /ilp endpoint. I’ll continue these experiments and posts into the rust topic area since things are getting “rusty”.

To close off this thread, it seems to be possible what I am suggesting but I see now in the code that at the very least the routing is looking for an outgoing btp address which would imply wanting at least two connectors in this idea. I may try to formulate a local btp address for the destination and see if it routes to the btp port.

Thanks for the insights.

Instead of having a second connector, you could also use a script that connects via BTP (as a client) to 2 accounts on the same node. If you send a packet with the destination set to the second account’s ILP address, the node will forward it over the open BTP/Websocket connection to the second node. To fulfill the packet, you’ll need to have the script send back a Fulfill packet with the preimage of the execution_condition.

1 Like