Proposal: moneyd with Multiple Currencies / Uplinks

[emschwartz]

moneyd was originally envisioned as a daemon for holding a single currency that would let the user send and receive all Interledger payments from a single account. However, as pointed out by @karzak and @kincaidoneil, among others, many people want to be able to transact and trade multiple currencies. Previously, the question we asked was how moneyd or applications connected to it would determine what currency to use at a given moment. The assumption was that we would need moneyd to have a local view of the respective value of the currencies in order to decide automatically.

We should:

• enable moneyd to connect to multiple uplinks at the same time
• allow the user to specify defaults for sending and receiving
• enable the default settings to be temporarily overridden

This is partially inspired by the experience of using rustup with Rust. You can install multiple versions of the rust compiler and toolchain (rustup install stable), set the default toolchain to use (rustup default nightly), and then run specific commands using a given toolchain (rustup run stable <command>). (This isn't a perfect comparison because moneyd is a daemon that keeps running, rather than a toolchain you'll use to run a single command.)

Open questions:

• Would we need a separate local mini accounts denominated in each currency?
• If an application connects to moneyd while it is set to use one currency, should that application keep using that currency even if moneyd's settings change?
• Should applications be aware of what currency they're connecting to? If so, that would enable you to send money between your different accounts by doing something like spsp server --asset=XRP --port=3000 && spsp pay --asset=ETH --receiver=http://localhost:3000 --amount 10000

What do you think?

[sharafian]

It's a bit rare that you'll be using the same instance of moneyd to do sending and receiving. Codius hosts, for example, are typically run on a remote machine. I guess in the future you might have some kind of wallet that does sending and receiving, though.

On currency aware applications, I think the use of currencies to denominate amounts should be separate from the actual currency that the uplink is configured with. If we used something like landmark-based price discovery (as in https://github.com/interledgerjs/ilp-price) then any application could denominate amounts in any currency that the user specifies, so long as there's a destination on the network that supports it.

[adrianhopebailie]

Clarifying question: Are you suggesting that local clients of moneyd use different currencies or just that moneyd has multiple uplinks?

I am assuming the former...

If an application connects to moneyd while it is set to use one currency, should that application keep using that currency even if moneyd's settings change?

I don't think it would be a good idea to break the session <-> accountInfo binding. i.e. When you have a session with moneyd that session has a currency and scale and those never change for that session.

Given that 'moneyd' listens on a single default port, how would you propose it differentiate between clients that use different currencies?

Would we need a separate local mini accounts denominated in each currency?

Part of our TODO list for the new connector architecture is to update moneyd to use it. That would mean not using mini-accounts but rather a listener that spawns a plugin instance for each incoming connection. This could be implemented such that there is a handshake protocol allowing clients to select an asset and scale.

Should applications be aware of what currency they're connecting to?

I think they have to be otherwise it becomes very difficult to, for example, run an SPSP server because you can't tell clients what asset you accept.

[emschwartz]

It's a bit rare that you'll be using the same instance of moneyd to do sending and receiving... I guess in the future you might have some kind of wallet that does sending and receiving, though.

The experience I'm imagining is for what a user or developer would run on their local machine. Right now it is exceptionally difficult to get yourself set up locally to try out ILP and use features like sending cross-currency payments. This makes it hard for us to get more developers interested in using ILP and building with it.

Are you suggesting that local clients of moneyd use different currencies or just that moneyd has multiple uplinks?

Both

I don't think it would be a good idea to break the session <-> accountInfo binding. i.e. When you have a session with moneyd that session has a currency and scale and those never change for that session.

Good point. Agreed.

I think they have to be otherwise it becomes very difficult to, for example, run an SPSP server because you can't tell clients what asset you accept.

I meant should applications be able to specify what currency they're using. They definitely need to be able to find out what they are using once they're connected.

[kincaidoneil]

As Evan noted, we agree that whatever app is used to connect to Interledger should support multiple uplinks simultaneously, for different currencies. We've been working on an SDK and desktop wallet that implements this concept for cross-currency exchanges. (Unfortunately, this has taken longer than we anticipated, as working through the UX has exposed challenges in some of the plugins/underlying infrastructure -- slow settlements, handling fees, etc).

Part of our TODO list for the new connector architecture is to update moneyd to use it. That would mean not using mini-accounts but rather a listener that spawns a plugin instance for each incoming connection. This could be implemented such that there is a handshake protocol allowing clients to select an asset and scale.

👍I really like the idea of spawning a new "account" per application, e.g. to enable per-client balance limitations. Also seems like a natural way to implement choosing a specific currency. However, I don't think you'd want a new uplink for each client/how would that work?

[emschwartz]

I'm not a big fan of the idea of spawning a new account/plugin per client that connects. I think we should move in a more stateless direction such that the most that's stored in memory is a way to correlate ILP Prepare packets with the Fulfill/Reject.

[adrianhopebailie]

I'm not a big fan of the idea of spawning a new account/plugin per client that connects. I think we should move in a more stateless direction such that the most that's stored in memory is a way to correlate ILP Prepare packets with the Fulfill/Reject.

I don't really follow this. You seem to be mixing concepts. Request/reply correlation is one thing but plugins do a lot more (like dealing with settlement).

If you don't have a plugin for each client, how does a client settle with the connector? Do you not track a balance for each client at all?

The accountProvider model is a replacement for mini-accounts. It decouples the server that accepts connections from the business logic of a plugin. i.e. You spawn a plugin to "wrap" each new connection and the plugin handles settlement etc.

If you don't want to do settlement you could spawn a "pass-through" plugin.

[emschwartz]

If you don't have a plugin for each client, how does a client settle with the connector? Do you not track a balance for each client at all?

I'm thinking you'd track the in the database without instantiating anything in memory for that client. Settlement could either be done when the balance in the db gets to a certain level or there could be a separate payment channel manager that does that.

[kincaidoneil]

I feel like we're conflating two separate things.

While today spawning a new "account" instantiates a plugin and middleware stack (in the connector refactor), it's conceivable that it could load account-related data from the DB on a per-request/as-needed basis and keep very little in the V8 memory (only persistent services, e.g. the BTP server/connection, an LND/eth node/Rippled connection, and/or channel watcher).

(Evan's argument I think being that (e.g.) Redis is more optimized from a memory standpoint compared to keeping everything in JS throughout the connection).

Regardless of whether we go in that direction, I'm just saying I like the notion of each account/client connection having its own unique middleware config, for the moneyd use case.