Query: Advanced Search

[comm-lib] Let BlobServiceClient accept service-to-service token

[native] Skip keyserver upload for thick thread avatars

[native] Update ThreadAvatarCameraModal screen to take threadInfo

[native] Update avatar hooks to support skipping keyserver upload

[web] Support setting image avatars for thick threads

[lib] Support image avatars in DM thread-action

[lib] Add type for thick thread avatar update request

[lib] Fix resetting thick thread avatars

[web] Avoid keyserver call when deleting media for DMs

[lib] Make media metadata upload to keyserver optional

[web][native] Enable blob uploads for thick threads in input-state-container

	Include stories about projects I am a member of.

Rebase before landing

Rebase, make type readonly

Replace ternaries to make conditions more readable

[identity] Replace handle_db_error mapping with question mark

[native][lib] Add RestoreUser RPCs to Identity client

[native] Add RestoreUser RPCs to JSI

[native_rust_library] Add RestoreUser RPCs to client

[identity] Implement RestoreUser RPCs

[identity] Ask Tunnelbroker to terminate old device sessions

[protos][identity] Add RestoreUser RPCs

Rename user_id to userID

[lib] Add more keys to redacted values

I'm letting others review as well.
Generally feels alright and solves the original issue. Left one comment that's concerning to me

[identity] Add function to update social proof

[identity] Allow register_primary_device() to overwrite device list

[identity] Update SignedDeviceList::from_str to return tonic::Status

[identity] Verify lastPrimarySignature for singleton lists

[tunnelbroker] Add RPC for closing WebSocket sessions

[tunnelbroker] Close WS session when received special AMQP message

[terraform] Hide prod Tunnelbroker gRPC endpoint from the Internet

Rebase on feedback: Merge RPCs into one

Merged RPCs into one
Made the RPC accept userID

Besides that one thing, device removal logic looks good

In D13221#373423, @ashoat wrote:

Discussed my above feedback with @bartek today in our 1:1. We identified several potential paths forward for unifying these two RPCs:

Take userID as input here instead of username

The backup service could return the userID in the initial RPC

Alternately, if that is too complicated for some reason, the client could get the userID via FindUserID, but this would require an additional RPC

Take oneof identifier as input here, to match FindUserIDRequest

This is probably slightly worse as it might require us to change / update this RPC later as part of ENG-8414

Based on this discussion it looks like the backup service doesn't query for the userID at all currently, and instead just uses the username. We'll need to update that as part of this work, so it's probably a good time to consider option 1a.

In D13228#373308, @ashoat wrote:

This is meant to be called by other services, right? After ENG-9129 is resolved, it should only be possible to access from other services?

In D13221#373282, @ashoat wrote:

Overall I don't think the dichotomy between password and Ethereum users makes sense here, given the protocol is substantially similar, and given that we're trying to get rid of this distinction going forward.

Maybe we could have a single RPC that has an optional input of a social proof? If the account is using an Ethereum wallet as their display name, then the RPC will fail without a new social proof. What do you think?

Advanced Search
Use Results
Edit Query
Hide Query

Sep 13 2024

Sep 11 2024

Sep 10 2024

Sep 9 2024

Sep 5 2024

Sep 3 2024