My notes on the work I do at Status.
Go to file
Samuel Hawksby-Robinson c5720a0cd5 Updated 2024-05-28 2024-05-28 22:13:48 +01:00
analysis/wallet/Router Added suggested restructure for filterRoutes 2024-05-15 15:45:06 +01:00
archive Archived current log 2024-05-13 12:07:11 +01:00
attachments Updated filter test results 2024-05-17 20:27:12 +01:00
priorities Updated priorities 2022-01-05 13:34:36 +00:00
tags Updated 2024-05-13 2024-05-13 21:42:30 +01:00
README.md Updated 2024-05-28 2024-05-28 22:13:48 +01:00

README.md

2024-05-28

Issues

Pulls

Schedule


2024-05-27

AFK - Spring public holiday 🚂🚃🚃🚃


2024-05-24

Issues

Pulls

  • Router Filter Modularisation #5177
    • Finished! 🎉 Ready for full review
    • Big commit implementing additional test cases to make the test suite as comprehensive as I can.
      • That doesn't mean it is fully comprehensive
    • Addressed feedback
    • Resolved insufficient rest test case issue
    • Implemented testing.T t.Logf test level logging
    • Implemented pure zap debug logging for all relevant filter functions.

Schedule

  • 10:30 11:30 : Desktop Send modal review
    • https://meet.google.com/pow-qyes-pcv
    • "A meeting to dispel doubts about the design and current state of SendModal."
    • Attendees:
      • Michal C (Facilitator)
      • Alisher
      • Ben
      • Brian
      • John (Lea)
      • Sale
      • Myself
    • Summary:
      • Discussion clarifying the rules and requirements of the desktop designs for sending tokens.
        • No agreement yet on where to capture the rules
      • Initially some confusion on the distinction between multichain send "without bridge" and "bridging"
        • Confusion as sending over multiple chains requires bridging
        • Clarity eventually given; references to "bridging" is a term for a specific UI action and not an implementation behaviour.
          • ie in the UI context bridging refers to the user pressing a "bridging" button to perform an explicit bridging action. Not the required routing performed by status-go Wallet Router.
          • ⚠️ Attention. Devs and QAs particularly should be mindful of this.
      • Emphasised that the app should mint ERC1155 rather than ERC721 tokens
        • Confirmation that this is the case was suggested.
      • Highlighted that there is an inconsistency with the current desktop app functionality verse the intention of the design.
        • Locking behaviour for values on specific chains does not work as the product design intended
          • Full requirements not yet provided, expected to follow.
          • Additional clarification and validation likely to be needed
        • Discussed that ERC1155 tokens of the same kind should be grouped together.
          • Unclear if designs and requirements for this feature exist in the form needed by Desktop UI.
          • Dario has mentioned in chat: > "This is mostly a backend effort with relatively high complexity (define a special kind of token for these "community ERC721 we want to treat as ERC1155" ones, do the grouping backend-side when fetching them, do the un-grouping backend-side when sending, ensure no side effects in activity). I see low chances of swap-team being able to work on + finish that for 2.30, unless it's prioritized over Swap."
          • So this intent is / has been expressed somewhere.
      • Brief update from Brian and me.
        • The call expressed a blithesome response to the update that the Wallet Router filter modularisation and test suite was complete and ready for review.

2024-05-23

Pulls

  • Router Filter Modularisation #5177
    • Resolved a boat load of test scenario issues
      • I'm super seriously very nearly finished now.
      • However, I do need reviewers to pay super close attention to the test cases and check that the intent of the functions is matched by the cases.
    • The full list of changes is available in the PR commits.

Schedule


2024-05-22

Pulls

  • Router Filter Modularisation #5177
    • Resolved a boat load of test scenario issues
      • I'm very nearly finished now. However, I do need reviewers to pay super close attention to the test cases and check that the intent of the functions is matched by the cases.
    • The full list of changes is available in the PR commit.

Scoping

Ad Hoc

  • Confirming details about my EthCC presentation

2024-05-21

Pulls

Schedule

  • SendModal designs review : 10:00 12:00
    • https://meet.google.com/qdq-wrzq-mha
    • Meeting notes
    • Attendees:
      • Sale (Facilitator)
      • Alisher
      • Ben
      • Magnus
      • Michal C
      • Myself
    • A very in depth meeting reviewing the send flows of desktop.
    • Key Decisions:
      • Reduce the scope of the Send, Bridge and Swap UI designs for 2.30
      • UI and design to work together
        • Desktop UI should detail what is feasible for the 2.30 release
        • Alisher and Ben are supportive of facilitating a highly iterative framework.
        • Alisher and Ben will adapt sending flows as required
      • Michal and Sale would discuss the best process for improving the UI while at the same time being able to deliver something. Include Noelia
      • Identified distinctions between the concepts of backend Router and UI Router
        • Backend Router is a logic model for sending blockchain tokens. This model contains functionality that manages:
          • Calculating the best path for any given transaction requirements:
            • From address(es)
            • To address(es)
            • From network(s)
            • To network(s)
            • From token type(s)
            • To token type(s)
          • The Router is capable of using multiple input tokens and addresses to plan a route to multiple output addresses and tokens.
            • The Router determines which swaps and bridges may be required to achieve the goal
        • Backend Router can be called by multiple UI components:
          • Bridging
          • Sending
          • Swapping
        • Backend Router handles all of these transaction types internally.
        • UI Router is a complex high level UI component that allows a user to plan with great detail which tokens, addresses and networks they wish for a transaction (or series of transactions to take).
        • UI Router is part of the UI bridging functionality.
  • mobile-core retro : 13:00 14:00

2024-05-20

Pulls

Schedule

  • 13:00 13:45 : bi-weekly status-go call
    • https://meet.google.com/gbq-tyqe-vju
    • Stand-ups
    • Discussion about changes required for Wallet Router to accommodate swap functionality.
    • Discussion about the stability work done on Wallet Router.

2024-05-17

Pulls

2024-05-16

Issues

Reviews

  • https://github.com/status-im/status-go/pull/5159 approved, feedback
    • A re-review after Sale made some changes in response to all of the feedback given.
    • I've suggested one opinion based change based on function signature complexity, aside from that I've approved the PR.

Schedule


2024-05-15

Coding

  • filterRoutes is a very complex function, and it is very difficult to read. I've split it apart and named the levels of filter after what they do rather when they happen.

Reviews

Scoping


2024-05-14

Scoping

Schedule

  • I raised an axe to the crew meetings, swung hard and true. Toppled and prostrate they settled motionless. Tonight we revel in the light of their embers!

2024-05-13

Scoping

  • Wallet Router
    • I began work on reading and building context of the Route status-go logic.
    • This work is tricky to track, but I have begun making notes of the logic. I plan to continue to build out a description or documentation detailing the analysis.
  • Torrent dependencies in mobile build

Schedule

  • 10:30 11:30 : Discussion and sync with Sale about planning and scoping of Wallet Router work.
  • 12:00 12:30 : Wallet Router Sync
    • https://meet.google.com/amj-krdp-dta
    • Attendees:
      • Alisher
      • Andrea
      • Emil
      • Ivan
      • Jamie
      • Sale
      • Myself
    • Notes
      • Discussed what should be priorities
      • Decided the following:
        • Scope the Wallet Router to understand the logic
        • Tests should be writen to validate any changes the Router code, but we do not build tests out without introducing changes.
          • Tests can be written in the context of demonstrating / exploring how code works.
        • Alisher was meant to present the product expectations, but we ran out of time.
  • 14:30 15:00 : team update