Data structures for E2EE push keys#2193
Merged
gnprice merged 17 commits intozulip:mainfrom Mar 9, 2026
Merged
Conversation
Member
Author
chrisbobbe
reviewed
Mar 3, 2026
Collaborator
chrisbobbe
left a comment
chrisbobbe
left a comment
There was a problem hiding this comment.
Looks great! Just one nit below, otherwise LGTM.
Comment on lines
+70
to
+74
| Future<PushKey> doInsertPushKey(PushKeysCompanion data); | ||
|
|
||
| Future<void> doUpdatePushKey(int pushKeyId, PushKeysCompanion data); | ||
|
|
||
| Future<void> doRemovePushKey(int pushKeyId); |
Collaborator
There was a problem hiding this comment.
nit: could add dartdocs for these, like the global-settings methods above
Member
Author
|
Thanks! Revision pushed. |
gnprice
force-pushed
the
pr-e2een-keys
branch
2 times, most recently
from
3c87713 to
07d1f40
Compare
Collaborator
|
LGTM! |
In particular, updating the generated code for `build_runner` first and `drift` later goes a bit smoother: if going in the other order, one has to make a temporary commit in between in order to reassure the `build_runner` suite it won't clobber the output of `drift`.
Initially when adding the deviceId column, I'd forgotten that this bit of code existed and needed updating. The result was some confused debugging, as the column remained stubbornly null in the tests' data no matter how I initially tried to give it a value. To prevent that happening again, I wrote up a somewhat ridiculous (but effective) check, involving a switch in a loop, to remind us to update this code: zulip#2181 (comment) Then I filed a feature request in Drift upstream for a way to automate this away entirely. From that thread, here's a workaround to automate this construction today. It's a bit more complex than ideal, but much nicer than the manual code we had.
This should make it significantly less tedious to add and test further migrations that just add columns to this table.
As a bonus, we add coverage for several migrations that are boring enough that they previously hadn't been worth the tedium. Now they only add one line each to the test, plus a one-line comment to match the list up.
This will let us keep things clean as we add additional fields whose values get generated by the client rather than set by the user or the server.
This diff is mostly indentation; try `git diff -b` to read it. All these existing tests are for the legacy pre-E2EE notification subsystem, so have them explicitly use a pre-E2EE feature level. As we start implementing the new system and adding logic that conditions on the E2EE notifications feature, we'll add corresponding tests here that use a current feature level.
I think we won't end up ever making the change this suggested, and that's fine. Discussion here: zulip#2181 (comment) On the other hand it would be good to register the token proactively for all accounts, not just the current one, in case it's changed. Filed that as its own issue, zulip#2197.
This comment is from the very early prototype of this app, and refers to a data structure from the legacy app. * The push token wound up on NotificationService, in a ValueNotifier of its own. * Two other fields on the legacy app's GlobalSessionState are `orientation` and `isOnline`, both referring to state of the device, for which Flutter has better APIs than putting the data on the app's global state object. * The remaining field is `isHydrated`, which is false only when the legacy app hasn't yet loaded data from its database. That effectively means that none of the data in most of the rest of the store can be trusted, because it's all just bogus initial values that the various Redux substates start with. In the new app, we eliminate that whole problem architecturally: there is no GlobalStore until we have non-bogus data to put into it.
This line was getting a bit long to read.
Member
Author
|
Thanks for the reviews! Merging, since #2160 is in. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Toward #1764. Stacked atop #2181.
This PR adds a table PushKeys, and substores PushKeyStore and GlobalPushKeyStore, to manage remembering our encryption keys for end-to-end-encrypted push notifications #1764.