Weekly Sync - 13 August 2024

[github-actions[bot]]

Please add agenda items below and give your weekly update in a comment. Thank you!

Agenda

• @mkurapov(?) : incoming payments without an amount and AML
• @sabineschaller @raducristianpopa : should OP keys be unique?
• @raducristianpopa subsequent/concurrent outgoing payments performance testing
• @sabineschaller: update of Rafiki Work Week tracks

Discussions

Incoming Payments without Specified Amount & AML Concerns

An actionable incoming payment is one that a receiving ASE can choose to accept or cancel.

@mkurapov raised the need for actionable incoming payments, which has been highlighted in the PCH work. Sometimes accounts have tiered KYC so not all accounts meet the regulatory requirements for receiving large funds. This is even more true in cross-border scenarios.

In cases where the receiving account may not be able to accept the payment due to constraints such as regulatory limits or Anti-Money Laundering (AML) / Know Your Customer (KYC) requirements, or simply because the account is not in good standing, it is better to fail early in the process.

In order to fail early:

• The receiving ASE needs to have the ability to either accept or cancel incoming payments. Max’s proposal is that when the incoming payment is created, a webhook should fire, allowing the receiving ASE to either accept or cancel the payment immediately.
• One of the reasons to cancel an incoming payment is if the amount is too large to pass AML for instance. To fail early, the amount needs to be known. Currently in the fixed send model, the receiving ASE does not know the payment amount until after the outgoing payment completes. To address this we’d need to create incoming payments with a defined full amount upfront. Max’s proposal for this was using the quote as a rate probe. So the quote is used to retrieve the destination asset information from the wallet address itself instead of from a receiver. Once we have the quote, that means we also have the minimum delivery amount and maximum send amount. So we have everything we need to create an incoming payment and we can go ahead and automatically create a receiver. Once the incoming payment has been created the outgoing payment can be created on the sender. Nothing will have changed from the perspective of the sender. This solution also allows us to still have scenarios without specified incoming amounts, which is needed for the web monetization case. It removes one extra call to the recipient to create a receiver, just pass the wallet address for the quote creation and Rafiki can package up the functionality to create the receiver from the quote. This does not have to change the Open Payments flow. It does change the existing Rafiki API flow. If this goes ahead then Rafiki will include additional internal functionality beyond what Open Payments specifies.

Unique Open Payment Keys for Wallet Addresses

Rafiki currently allows multiple wallet addresses to share the same public/private key. We have no uniqueness checks.

@sabineschaller raised concerns about whether the same public key should be used across multiple wallet addresses, especially when they belong to different accounts.

However it is no easy task to try and differentiate between keys being assigned to different wallet addresses that are for the same account, or for different accounts.

Not to mention, that one person can hold different accounts and in that case it would still seem okay for them to manage their keys as they wish.

Also, even if we did try enforce uniqueness we can only do that per ASE. If the same keys are being used in two different accounts but those accounts are at different ASEs we have no way to enforce that uniqueness.

@raducristianpopa argued that, similar to SSH keys, this should be up to the user, and it’s not Rafiki’s responsibility to enforce uniqueness.

Decision: There should at least be checks to not add the same key more than once for the same wallet address. Sabine is working on a migration file to delete duplicate keys associated with a single wallet address.

Performance Testing for Subsequent/Concurrent Outgoing Payments

Web Monetization (Web Mo) has encountered performance issues with outgoing payments. These are asset scale 9 payments, where an outgoing payment (without quote) is created every second. They seem to have a linear increase in response times with subsequent payments that get slower erratically. There is ongoing work to find what is causing the issue. @raducristianpopa asks that we add performance tests that test repeated outgoing payments from one account and see how the performance tracks with subsequent payments.

Currently we’ve been working on load testing creating outgoing payments. But would also like to be mindful of whether we’d get different behavior from testing the Admin API calls versus the Open Payment routes themselves.

Decision: We’ll put it on the roadmap.

Update on Rafiki Work Week Tracks

Plans are still preliminary
Changes:

• Instead of finding an alternative to Rapyd, there is a possibility we’ll be shifting to using a test environment from Fynbos Wallet. If that pans out then this track can rather be assigned to Settlement Simulation in Test Wallet.

Rafiki Work doc can be found here.

Final decisions on these issues will be made by the following Tuesday, considering who all will be participating and how the current work week progresses.

[BlairCurrey]

• added new trace-based metrics (histogram for graphql resolver durations)
• working on local rafiki payments. finished db migrations and model changes, going to implement new getQuote/pay methods

[JoblersTune]

Re-worked my telemetry packet count PR to capture metrics on the sending node. It's waiting additional reviews and a bit more of a write up from me about all our learning along the way.
Getting up to speed with Brad about collaborating on creating better Rafiki Admin docs.
Will be starting work next on making authorisation optional for Rafiki Admin.