status-im
/
samyoul-notes
mirror of https://github.com/status-im/samyoul-notes.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity
My notes on the work I do at Status.
317 Commits 1 Branch 0 Tags 17 MiB
HTML 99.8%
Go 0.2%
Go to file
Samuel Hawksby-Robinson 66de09e79c Updated 2024-05-31 2024-06-02 13:48:30 +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 2024-05-29 2024-05-29 20:45:04 +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-31 2024-06-02 13:48:30 +01:00

README.md

2024-05-31

Pulls

  • Removing torrent from mobile build #5257 - commits, scoping
    • I've fully split Manager from TorrentManager
      • I've removed any mention or dependency of TorrentManager from Manager. There is still more work to do, but Messenger now communicates directly with a TorrentManager rather than asking the communities Manager to handle it.
      • I've ensured that LogStdout() is only called from TorrentManager and removed entirely from Manager, this functionality seems to be some kind of debug tool specifically for torrent related functionality.
      • Next I need to focus on functions within Messenger that call a TorrentManager and see how to isolate these from the main flows.
      • I also need fix the tests that are broken.
      • I also need to refactor torrentClientReady() so that it is a function of TorrentManager, this may allow for pushing more functions into TorrentManager which will lead to better torrent encapsulation.
    • Made torrentClientReady() belong to TorrentManager
    • Unexported all exported funcs not used externally in TorrentManager
    • Mapped for restructure torrent specific Messenger functionality
    • Mapped entire TorrentManager API Usage
      • https://github.com/status-im/status-go/pull/5257#issuecomment-2142881649
      • This will augment the restructure of torrent specific Messenger functionality, as Messenger is split across multiple go files.
      • Once this is done I can identify 2 key things:
        1. What Messenger functionality can be pushed into TorrentManager
        2. What the bare minimum TorrentManager interface signature needs to be.

2024-05-30

Pulls

  • Removing torrent from mobile build #5257 - commits, scoping
    • Resolved TorrentManager dep injection
      • I mapped out the details of the deps
      • I'm not particularly proud of this work. I've just passed in all the deps as vars, there are way too many concerns handled by the TorrentManager that I don't know what is the best approach to removing them. I've even resorted to declaring an 'Publisher' interface to handle all the 'publish()' calls the TorrentManager makes. Next up I need to resolved the communities Manager API, because I've removed all of its end points. The TorrentManager needs to be a lot more simple than it is.
    • Scoping of the TorrentManager API usage

Schedule

2024-05-29

Documents

Issues

Pulls

  • Removing torrent from mobile build #5257 - commits
    • Initial migration of all torrent dependent code
      • Code moved into new TorrentManager. This is BROKEN! The code is not ready to use so don't use it, lots more work to do. Biggest problem is that the torrent management in Manager is very tightly coupled to sending encrypting etc. All of that needs to be prised apart
    • Ensured move of all torrent funcs and structs
      • I also ensured that the order of functions matches the original code, to make comparison easier during review.

Schedule

Note details of this below call were shared in the Snow Blowers' chat and in the general status-go Discord / Status channel.

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