I planned changes because I thought there was an issue with the current users - they are already registered, so we won't put the version into the DB for them and their backup won't contain it. Actually, there's no such problem, because in order to create a backup, the app should be run, and the migration from the previous diff will be performed and will put the version into the DB.

flow + close reading for now

Sounds risky for a change that changes the flow.

This code is almost entirely a copy-paste from existing endpoints. Can we reduce the duplication?

Thanks for making this change!

I considered specifying this on the message specs, but there's no way to do that without leading to an import cycle.

It would be great if we could make a corresponding change to RawUnsupportedMessageInfo type (update unsupportedMessageInfo). Maybe we can define this type in another / new file? The problem with the current solution is that we have to remember to update the validator and our types don't protect us against forgetting about this.

however, my local keyserver/mariadb isn't designed to handle switching between false and true.

What do you mean by that? After you go with https://www.notion.so/commapp/Running-two-keyservers-0d373941f2494d949846da02752b91db instructions, you can change the client's flags however you want - at least that's what I'm doing and it works reliably. So my keyserver is always configured in a multi-keyserver manner.

Update a comment

Fix a comment

Add a comment

Simplify

Not going to block it, but the approach doesn't make too much sense to me. Introducing something just to be removed a little later could be avoided by a better sequencing of work.

Are there any actions that need ops processing dispatched before we render TunnelbrokerProvider?

Handle syncing with non-auth keyservers

Is native also affected by this bug?

Will test generally at end to make sure things work as expected.

Is this something that will be done later in the stack?

I think you should consider having a test plan that actually verifies that this logic is correct.