I pulled this from the version of the types in node_modules. Will try to make those improvements, with exceptions for any methods that might not exist in this older version of Olm (I think you're looking at master, which I linked above)

Did we make sure this passed keyserver Docker build before landing? Just want to make that sure that running build:debug before we run build doesn't break build (doubt it)

(To your queue and off my mine while you figure things out with @kamil)

Seems reasonable

One thing not mentioned by @varun is that the current AUTH_TOKEN hack we use for keyserver is implemented on a per-service basis. So we can roll out a new service without "authorization headers", while maintaining the current keyserver paradigm.

Ahh sorry that was a bad misreading on my part, I get what you mean about user IDs now.

I'm more confused as to why are we're separating the protos / services out at all

1. Huh wait a user should know their userID, did you guys discard of the concept of a userID entirely because you didn't see it in the whitepaper?
2. I don't understand why we're separating into two services, can you explain that?

Move some type changes from parent diff to this diff

Hmm are we using usernames as an identifier? Ideally we use user IDs for that

Can RobotextChatMessageInfoItem be edited?

This honestly feels like bike-shedding… I’d love if we could start out the work on this project with a focus on derisking the big risks, rather than renaming things

Can we avoid putting this in TextMessageInfo? I don't think it belongs there... and you're doing something pretty inconsistent with how we approached reactions.

The title is somewhat misleading, but mostly the fault of Webpack docs. Before this diff, the polyfills were not included. After this diff, each of these is set to the empty object (I think)

Not sure what you mean – deviceTypesObj can't be extended outside of this file since it's not exported. We're actually using Object.freeze for Flow, otherwise $Values<typeof deviceTypesObj> maps to string instead of 'ios' | 'android'

Please address comments before landing

JS looks good with some minor nits. Somebody should look at Rust

Okay, great – let's ship it!

I considered a solution like this, but I was worried that we would need some synchronization. @marcin, can you share some resources that show that NativeAndroidAccessProvider::runTask is "blocking", ie. it guarantees that the lambda passed to it will finish executing before it returns?

(Please don't land until D6959 is accepted and ready to land as well)

Separately, I think it might be good to add @ginsu to your list of reviewers for this work, given how recently he touched reactions

Can you also updates lib/types/messages.js? EDIT ah I see these are in the next diff

Okay, based on that it sounds like your solution is probably better than mine.

Open to it if there is some benefit over approach in D6958, but would like to see a discussion of tradeoffs.

I'd probably include this with another diff tbh... I think it's easier to see stuff like this combined with the usage, and it's easier to put a concrete test plan too

Seems reasonable, defer to others on Rust