Weekly Sync - 04 June 2024

[github-actions[bot]]

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

Agenda

1. @raducristianpopa @interledger/pay rounding amounts where it should not
2. @sanducb Asset scale 9 vs asset scale 2:

• Same problem as described above by @raducristianpopa on Rafiki money -> wallet address (asset scale 9) sends amount to wallet address (asset scale 2) over a peering relationship on asset scale 2, losses seem to occur when conversion is done by the rate service in Rafiki. When sending 10000 (asset scale 9), received amount is 1 (asset scale 2) because the amount is ceiled.
• Accounting related tables should also be migrated to asset scale 9 -> I need guidance and will reach out to Rafiki team.

3. @JoblersTune: Discuss Admin UI's handling of incoming vs outgoing auth tokens to better avoid confusion

Discussion

Discussed the issue where payments rounding up to the smallest unit of receiver’s scale in cross currency payments. In this case the account servicing entity (ASE) may lose money since it fulfills more to the receiver than it takes from the sender. All we can do on Rafiki’s side is refuse payments if the sender is sending something too small for the recipient to receive.

Discussed the problem that when an outgoing payment is complete the assumption is that the payment has gone through, but the payment could still fail under the hood. How do we handle this in the case of Web Monetization? Can we do periodic checks? This raised concerns about the high number of requests that would be involved. Intervals may not be an acceptable approach in cases where intervals or asset scales means significant money is being transferred. Maybe that’s okay if it’s transferring fractions of a cent but perhaps not okay to mismatch when sending whole cents.
Realized we have two issues

1. What to do with failed payments? We need to consider how best to communicate this to the user. The best approach is probably to do a maximum number of retries and then fail the payment and find a way to alert the user of this.
2. Minimum amount problem. If we simply refuse payments that are sending amounts below the receiver’s minimum ability to accept it then we still have another problem. There are still ‘bits’ left over in cross currency instances. E.g. sending 1 usd cent to an ASE whose minimum amount is 1 euro cent means the conversion isn’t 1 to 1, what happens to the ‘bits’ left over in that conversion that are below a cent and too small for the ASE to process? Perhaps this could be compensated for by fees charged to the sender.

On the Admin UI the incoming auth tokens field behaves differently than the outgoing auth token field when editing a peer. We’d like to make this behavior more intuitive. The proposal was to rather have an editable drop down that allows users to select and edit incoming auth tokens in that way. So we will expose them to the frontend so users can see what incoming auth tokens they have currently listed. But the drop down will make it such that interacting with them will also be clear and deliberate.

TestNet team says they will update to the latest version of Rafiki once they have resolved the Kratos setup. Right now this is a blocker for them and they are unable to utilize the Admin UI without getting Kratos going as well.

[BlairCurrey]

• merged in open payments changes for adding spent amounts to outgoing payment creation
• have a draft pr ready to imlpement these spec changes in rafiki. just ran into a hurdle with a new open-payments dynamic import in the integration tests. probably the last hurdle before I can open the PR for review.
• reviewing Jason's PR for the new additionalProperties field on wallet address - will need those changes before I can start the task for the update mutaiton

[JoblersTune]

Working on the Admin UI to allow payments to be viewed by optionally filtering them to only see payments for a particular wallet address.

[njlie]

• Working on updating the Rafiki backend graphql resolvers logs.
  • Just rebased an old branch to latest main, and am refactoring resolvers added since then to use the new logging method

[beniaminmunteanu]

Worked on jopacc