Please always check with me about any copy you get from @ted

This diff should be split, and more work should be done to explain the changes and why they're necessary

I wish I didn't have to rewrite every single docs diff...

Please internalize all of the feedback here so it doesn't have to be repeated in future docs diffs

Exciting to see this launched! We should make sure we announce this to users in the Comm supporters community, since I know some of them had requested this

High-level approach makes sense, but it's unfortunate that we're complicating a component that is already too complicated. Feedback below should be relatively easy to address

Dependencies seem fine

This appears to be the only place in the codebase where we need to manually call setScrollBlockingModalStatus('closed'). All other places are handled directly by the code inside OverlayNavigator.

This diff is doing a lot of things, and could probably be decomposed in four different diffs. At this point we don't have time for that unfortunately.

Should services/lib/docker/proto_codegen.sh also be deleted? How about any of the other scripts in that folder?

Maybe next code version?

In D8230#243760, @jon wrote:

Can you be more concrete about the performance / efficiency benefits?

Personally, it was a lot faster in getting the image to initially build

In D8200#243739, @atul wrote:

I vaguely recall chatting with @atul recently about some other reason that it would be good to have this parameter, but I don't recall the exact details (I think it was related to permissions?)

I believe this was so we could avoid storing computed permissions for other users in ThreadStore?

Resigning since I'm going to be out-of-office starting tomorrow, and I want to avoid blocking this diff. Instead, going to set @atul as blocking to confirm that my concerns are addressed, and so that he responds to the question above

Yes, it is. I don't know the beginnings of this convention, but we're doing the same with other values like loop, dimensions etc (probably the media could be processed on keyserver and these values could change).

However, it turns out to be convenient to have the blob hash and holder returned as well to avoid hacks (by passing them some other way) - it will be used in web client later (for blob deletion).

BTW. Are we going to opt out of using docker-compose at all? Having this script + nix localstack, it would be no longer needed (unless somebody still uses docker in local dev)

Seems reasonable

Thanks for explaining!

Hey @marcin, in your daily update yesterday you mentioned:

Didn't do a close review, just nits