Do you mean just blocking until all hashes are complete (like it is currently) or something smarter (e.g. we send a request to the server to delay the state check)?
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Today
Yesterday
changing stack order/will need to rebase
Pass in null parameter from non-problematic call sites
(notifRobotextForMessageInfo and getMessageTitle)
rebase
we should also not show message button if the user and/or viewer is blocked
Is my understanding correct that there is still a toplevel connection field in redux state? Should we remove it inside of this migration?
Simplify test cases
Important context in D9007 - we just want to use the alt text for now
Sorry, could you actually rebase and use the renamed function getContentSigningKey (I just updated D9220)?
Rename getContentPublicKey -> getContentSigningKey and
contentPublicKey -> contentSigningKey
You could remove the text field and just do textPrefix + mentionText
Accepting to unblock, but please look at my comment about moving clearance code to DatabaseManager::clearSensitiveData()
I also tested another idea: let's do all "batch hashing" (where we hash all items of a store) on the keyserver side. So during login the keyserver would send client all thread hashes. The client would only update the hashes during thread ops. That means we should optimise the keyserver-side calculations, so we should do the schema conversion on the client. I tested it and got:
- Do the hashing (without conversion) on the keyserver during login => I got ~0.5s for 7300 threads
- From previous testing: updating one hash with conversion on native should take about ~10ms, but it should be a few threads at most at one time
iOS emulator takes about 1ms per one thread and the speed should be O(n). In the case from the linear task where the state check took 53s, there was about 2000 threads, so logging in would take additional 2s
Alternative approach in D9265
Alternative approach in D9265
Yeah, you are correct. Basically if the value you would add previously put in website-responders is:
- some default value than it should go to web/redux/default-state
- value calculated on the keyserver than it should go in getInitialReduxStateResponder (+ some dummy default in default-state so flow doesn't complain)
Thu, Sep 21
fix icon
In D9262#272510, @atul wrote:In D9262#272502, @ashoat wrote:In the past, we would need to update websites-responders.js when adding a new field to Redux state. Now that Redux state for the web is fetched via an API call, is there a different place we should be updating?
Based on my reading of https://phab.comm.dev/D9145, the "new place" is web/redux/default-state.js which I did update in this diff.
address feedback
In D9262#272502, @ashoat wrote:In the past, we would need to update websites-responders.js when adding a new field to Redux state. Now that Redux state for the web is fetched via an API call, is there a different place we should be updating?
In the past, we would need to update websites-responders.js when adding a new field to Redux state. Now that Redux state for the web is fetched via an API call, is there a different place we should be updating?
rebase before landing
rebase before landing
thank you! one comment inline
rebase
simplify/address comments