- I was given the privilege of previewing and reviewing this stable draft of Status' unified approach to User Stories.
## Issues
- [Remove torrent dependencies at build time for mobile #5146](https://github.com/status-im/status-go/issues/5146)
- Begun working on this issue.
## Pulls
- [Removing torrent from mobile build #5257](https://github.com/status-im/status-go/pull/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.
- We agreed to target all of the `TestMessengerCommunitiesTokenPermissionsSuite` flakes
- [See the log file for more details](./attachments/2024-05/2024-05-29_02:48:00_nightly.log)
- We agreed to activate REQUIRED and considered a number of points that would need to be addressed.
- Generated files should be ignored
- Test coverage of 50% should be reasonable and not burdensome while effective at enforcing necessary code quality.
- We have a mechanism to override the requirement in EXTREME cases
- QA should be given visibility of this work
- [Make codeclimate diff coverage test reports Required #5254](https://github.com/status-im/status-go/issues/5254)
- [fix missing value of keyuid for old mobile user #5203](https://github.com/status-im/status-go/pull/5203) A case where the tests are present and seem to be robust but Codeclimate reports that the test coverage is only 36% (this case is notable because it seems unfair, may need investigation)
- [refactor_: ExtractTokenCriteria -> extractContractAddressesByChain #5226](https://github.com/status-im/status-go/pull/5226) A case where code changes are made but have no Codeclimate test coverage report
- [Direct settings updates (API) #5237](https://github.com/status-im/status-go/pull/5237) A case with 0% coverage
- [Router Filter Modularisation and Test suite #5177](https://github.com/status-im/status-go/pull/5177) A case with 100% coverage 😉
- [Refactor `fromIncluded` and `fromExcluded` Maps to Slices in Route Validation Logic](https://github.com/status-im/status-go/issues/5241) - `created`
- [Refactor and Simplify `hasSufficientCapacityV2` Logic to Ensure Correct Path Amount Validation](https://github.com/status-im/status-go/issues/5244) - `created`
- [Check Validity of `fromLockedAmount` in `SuggestedRoutesV2`](https://github.com/status-im/status-go/issues/5227) - `updated`
- 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.
- 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.
- 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.
-`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.
- [See here for details](./analysis/wallet/Router/code/filterRoutes.go)
- 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!
- 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.
