establish names for hops etc.

[michielbdejong]

We have a lot of ambiguity in how we use some ILP-related words. For instance, if you have one connector in a payment, is that a one-hop or a two-hop payment? Is the connector also a receiver and a sender? What is the difference between a payment and a transfer? I would propose we add a sort of 'glossary' section to one of the RFCs. After discussion with @sharafian on the way to lunch today, my suggestion for terminology would be as follows:

Suppose a human being named Alice wants to send money to a human being named Bob. This makes Alice the sender and makes Bob the receiver of the payment. If Alice and Bob both have an account on the same ledger, they can do a one-hop payment, involving just one transfer, on that one ledger. The amount of the transfer is measured in the ledger's base unit, which can for instance be micro-dollars.

If they don't have accounts on a same ledger, but they do have accounts on different ledgers, they can do a multi-hop payment, consisting of multiple transfers. The first transfer in the chain is the source transfer, the last one is the destination transfer, and if there are more than two, then the inbetween ones are intermediate transfers. The parties in the middle are called connectors.

Alice now is the source sender. The first connector's account on the source ledger is the source receiver. The last connector's account on the destination ledger is the destination sender, and Bob is the destination receiver.

[sappenin]

@michielbdejong this explanation is great!

Not sure if this issue is the proper place, but I think we should also include in the proposed glossary a brief expansion of the various Interledger protocol acronyms. For example, see this comment. It's not clear to me if SPSP and ILP are both "Interledger protocols", or instead more accurately "Protocols in the Interledger architecture."

The answer to that question will determine (in my mind at least) if RFC-3 should be called ILP or if it's really something like ILP Core, or ILPC.

EDIT: Looks like PR-181 resolves this issue by calling it Interledger Architecture (specifically, see here).

[sappenin]

Also, there's still some ambiguity in my mind between the person sending a payment (i.e., an account holder, which I think you've defined as a sender) and the institution that payment is coming from (e.g., the sender's bank).

In the banking world it seems like the terms originator and beneficiary are commonly used to refer to institutions/organizations that actually own the ledgers that a sender and receiver are utilizing.

So, perhaps the terms originator and beneficiary are used in concert with the word institution to represent entities that own a ledger, and the terms sender and receiver are used to denote the account holders? Not sure if there are more commonly used words that would be better here.

[michielbdejong]

institution that payment is coming from (e.g., the sender's bank).

that would be the 'source ledger', right? but if you think it's better, we can use 'originator' instead of 'source', and then use 'beneficiary' instead of 'destination'. Only issue with that is that SPSP and ILQP already use the terms source/destination now.

[michielbdejong]

totally agree that we should add our various TLAs to this glossary.

so, should it have its own RFC number?

[sappenin]

that would be the 'source ledger', right? but if you think it's better, we can use 'originator' instead of 'source', and then use 'beneficiary' instead of 'destination'.

Actually, I personally prefer sender and receiver. Words like "beneficiary" seems rather unapproachable to me, and your suggestion of source ledger sounds great.

Additionally, I ran this by some of my co-workers here, and the general opinion is that either sender or originator is fine to use, so I would say -- disregard my suggestion about "originator" and "beneficiary" and use something like source and receiver as much as possible (and even maybe Sending Bank or whatever).

Sorry for the noise...

[sappenin]

so, should it have its own RFC number?

That, or perhaps add the glossary to RFC-1?

[adrianhopebailie]

I would recommend that we take care to:

1. use well understood terminology that is already documented by standards bodies like ISO20022 for the financial services industry
2. distinguish between the end-to-end payment and the parties to an individual ledger transfer

For the end-to-end payment I would recommend payerand payee as the names for the parties as this is widely accepted and also doesn't get confusing when the sender of the first message to initiate the payment may be the payee (e.g. a merchant payment at a POS or online).

Rather than over-loading the names of the transfers I'd simply refer to them in terms of their order: first transfer, second transfer, last transfer etc.

Each transfer has a sender and receiver.

So, re-writing @michielbdejong 's example above:

Suppose a human being named Alice wants to send money to a human being named Bob. This makes Alice the payer and makes Bob the payee of the payment. If Alice and Bob both have an account on the same ledger, they can do a one-hop payment, involving just one transfer, on that one ledger. The amount of the transfer is measured in the ledger's base unit, which can for instance be micro-dollars.

If they don't have accounts on the same ledger, but they do have accounts on different ledgers, they can do a multi-hop payment, consisting of multiple transfers. The transfer initiated by Alice on her ledger is the first transfer, the transfer that delivers funds into Bob's account on his ledger is the last transfer, and if there are more than two transfers, then the in-between ones are intermediate transfers. The parties in the middle are called connectors (or liquidity providers).

Alice now is the sender of the first transfer. The first connector (who has an account on the payer ledger is the receiver of the first transfer. The last connector, who has an account on the payee ledger is the sender of the last transfer, and Bob is the receiver of the last transfer.

[emschwartz]

For the end-to-end payment I would recommend payer and payee

The only issue I have with this terminology is that the words look and sound far too similar. I think this is a problem both for having clear discussions about what is going on as well as for code clarity.

[michielbdejong]

One important measure, I think, is which words we already use in practice now. For many statements, it's understood from the context if 'sender' means 'hop sender' or 'source sender', and if 'receiver' means 'hop receiver' or 'destination receiver'. In itself I like Adrian's proposal to rename the destination receiver to payee, but I think the migration to the new naming would be too difficult to internalize, and in practice we would just still call Bob the receiver. Also, if someone is trying to understand ILP and calls Bob the receiver, I don't want to tell them "you mean the payee", it seems a bit overengineered / unnatural.

To make this ontology as 'descriptive' as possible and only 'prescriptive' where necessary, I think it would be confusing to let 'receiver' mean any receiver in any of the hops. I think 'receiver' should mean 'destination receiver' and we can introduce 'hop receiver' where you mean 'receiver of any of the hops'. The 'source receiver', 'intermediate receivers' and 'destination receiver (or receiver, for short)' then, are all 'hop receivers'.

I'll create a PR that adds a Glossary to RFC 1.

[professorhantzen]

The only issue I have with this terminology is that the words look and sound far too similar. I think this is a problem both for having clear discussions about what is going on as well as for code clarity.

I thought this also. Some considerations that may be useful when defining terms:

1. What are the potential impacts of choices in nomenclature on a scenario of widespread adoption? Easily-confused terms may scale badly (especially when money is involved). Minor considerations can appear overwrought until it is considered the impact even minor choices may have on efficiency and error-rates if, for example, the spec is adopted as an internet standard. How could faster code-completion for standard variable names affect productivity when scaled to millions of developers?

2. Are terms representing distinct concepts both visually and verbally distinct from one another, and are they as succinct as they could be? Visual and verbal distinctions ease language barriers and aid discussion taking place over poor communication lines, which amongst many things can include the aforementioned language barriers, intermittent network connections (a bad video call), and - these days - even smartphone auto-correct. Succinctness also implies a well-appropriated word.

To these ends, terms intended to represent different concepts might do well to not begin with the same letter, and single-letter distinctions between terms might be avoided. Having too many terms prefixed "source" and "destination" or suffixed "sender" and "receiver" might also be good to mitigate, if possible.

[adrianhopebailie]

The only issue I have with this terminology is that the words look and sound far too similar. I think this is a problem both for having clear discussions about what is going on as well as for code clarity.

I agree BUT we are not really in a position to define new nomenclature in such a broad topic as payments. If we could go back to the groups that originally defined this and persuade them it's a terrible idea then I'd be in favor. We could say something like:

in the Interledger specs we refer to the payer as the "sender" and the payee as the "receiver"...
(not great ☹️ )

Some good points from @professorhantzen worth considering too. I like the idea of distinguishing between a payment sender/receiver and transfer sender/receiver though. The value of using payer/payee is that at least these are distinct terms from sender/receiver.

[michielbdejong]

Continued in #184.