I don't see anything I feel strongly about, I'll keep on the queue for others

looks mostly right, but we need to validate the existing access token before we allow an update, right?

We need PakeRegistrationRequestAndUserID plus the existing access token for the user in the first UpdateUserRequest message, right?

Rebase on master

Rebase on master

Rebase on master

Rebase on top of latest master

i think cloning here is pretty inexpensive since we're just incrementing the atomic reference count, but you're right, we should avoid it altogether when possible

We don't need 15 difference copies of the Arc wrapping; just when we cross a thread boundary like tokio::spawn.

Reuse registerUser request message

Flip the isPinned condition

rebase before landing

rebase before landing

good catch finding this in the docs

Taking it off of @tomek's plate

Minor

Avoid "coupling" in favor of a linear data flow

DatabaseClient essentially just wraps the AWS DynamoDB client in an Arc. I'm not sure why we need to avoid cloning

I'm going to wait until the architecture of pinned_messages is decided in D6924 before requesting review, I just put this up so I could continue working locally.

Got it, thanks for explaining!

Seems reasonable

Thought about this a bit more. We need to make sure that we don't accidentally initialize two tbClientBinding, but TunnelbrokerPublisher.connect is an async function, which makes this difficult to guarantee.

In D6913#205664, @ashoat wrote:

I think it would've been good to separate this into two diffs: one that moves the code around, and the other than changes things (eg. the interceptor that you added). More details here

Haven't figured out how to send a request from host, but verifying that is the next step.

Not sure what you exactly mean, but docker-compose exposes the service port to host, so you should be able to simply

yarn run-feature-flags-service-in-sandbox
# in a separate terminal
curl "http://localhost:50055/features?platform=..." # etc

The issue was caused by a fact that I was using localhost instead of 0.0.0.0. When running the service locally, there's no difference. But when a service is run within a container, the localhost doesn't work properly.

Bind to 0.0.0.0

I don't know Rust :(

API looks good as far as I can tell, but I don't really understand the OPAQUE protocol definition so mostly deferring to you

Okay, never mind... let's pause on this work until you have time to pair with me

Include tag in commit name

Use user_id instead of username for identitifying users

rebase + land

rebase before landing