Proto commits in CommE2E/comm

These commits are when the Protocol Buffers files have changed: (only the last 100 relevant commits are shown)

2025-09-01

[identity][clients] Add supportsFarcasterDCs to GetFarcasterUsers RPC response Summary: We want this info when fetching FC-connected Comm users by FIDs Depends on D15260 Test Plan: Tested with localstack Reviewers: kamil Reviewed By: kamil Subscribers: ashoat, tomek Differential Revision: https://phab.comm.dev/D15262

The documentation is generated from this commit.

2025-08-28

[identity][clients] Add supportsFarcasterDCs to GetFarcasterUsers RPC response Summary: We want this info when fetching FC-connected Comm users by FIDs Depends on D15260 Test Plan: Tested with localstack Reviewers: kamil Subscribers: ashoat, tomek Differential Revision: https://phab.comm.dev/D15262

The documentation is generated from this commit.

[identity][clients] Add supportsFarcasterDCs to GetFarcasterUsers RPC response Summary: We want this info when fetching FC-connected Comm users by FIDs Depends on D15260 Test Plan: Tested with localstack Reviewers: kamil Subscribers: ashoat, tomek Differential Revision: https://phab.comm.dev/D15262

The documentation is generated from this commit.

[identity][clients] Add supportsFarcasterDCs to GetFarcasterUsers RPC response Summary: We want this info when fetching FC-connected Comm users by FIDs Depends on D15260 Test Plan: Tested with localstack Reviewers: kamil Subscribers:

The documentation is generated from this commit.

2025-07-25

[lib] Add info about DCs token into Identity Summary: https://linear.app/comm/issue/ENG-10903/inform-all-the-users-devices-about-the-successful-connection Depends on D14927 Test Plan: Tested in combination with the rest of the stack. Checked if linking during registration and from the profile screen works. Reviewers: kamil, bartek Reviewed By: bartek Subscribers: ashoat Differential Revision: https://phab.comm.dev/D14931

[identity] Allow linking Farcaster DCs Summary: 1. Expose a new endpoint that allows linking the DCs 2. Add an option to provide the token during registration https://linear.app/comm/issue/ENG-10893/receive-and-store-a-token-from-farcaster Test Plan: Tested in combination with the rest of the stack. Checked if linking during registration and from the profile screen works. Reviewers: kamil, bartek Reviewed By: bartek Subscribers: ashoat Differential Revision: https://phab.comm.dev/D14922

[lib] Add info about DCs token into Identity Summary: https://linear.app/comm/issue/ENG-10903/inform-all-the-users-devices-about-the-successful-connection Depends on D14927 Test Plan: TODO Reviewers: kamil, bartek Subscribers: ashoat Differential Revision: https://phab.comm.dev/D14931

[identity] Allow linking Farcaster DCs Summary: 1. Expose a new endpoint that allows linking the DCs 2. Add an option to provide the token during registration https://linear.app/comm/issue/ENG-10893/receive-and-store-a-token-from-farcaster Test Plan: TODO Reviewers: kamil, bartek Subscribers: ashoat Differential Revision: https://phab.comm.dev/D14922

[identity] Allow linking Farcaster DCs Summary: 1. Expose a new endpoint that allows linking the DCs 2. Add an option to provide the token during registration https://linear.app/comm/issue/ENG-10893/receive-and-store-a-token-from-farcaster Test Plan: TODO Reviewers: kamil, bartek Subscribers: ashoat Differential Revision: https://phab.comm.dev/D14922

[lib] Add info about DCs token into Identity Summary: https://linear.app/comm/issue/ENG-10903/inform-all-the-users-devices-about-the-successful-connection Depends on D14927 Test Plan: TODO Reviewers: kamil, bartek Subscribers: ashoat Differential Revision: https://phab.comm.dev/D14931

[identity] Allow linking Farcaster DCs Summary: 1. Expose a new endpoint that allows linking the DCs 2. Add an option to provide the token during registration https://linear.app/comm/issue/ENG-10893/receive-and-store-a-token-from-farcaster Test Plan: TODO Reviewers: kamil, bartek Subscribers: ashoat Differential Revision: https://phab.comm.dev/D14922

2025-07-23

[lib] Add info about DCs token into Identity Summary: https://linear.app/comm/issue/ENG-10903/inform-all-the-users-devices-about-the-successful-connection Depends on D14927 Test Plan: TODO Reviewers: kamil, bartek Subscribers: ashoat Differential Revision: https://phab.comm.dev/D14931

[identity] Allow linking Farcaster DCs Summary: 1. Expose a new endpoint that allows linking the DCs 2. Add an option to provide the token during registration https://linear.app/comm/issue/ENG-10893/receive-and-store-a-token-from-farcaster Test Plan: TODO Reviewers: kamil, bartek Subscribers: ashoat Differential Revision: https://phab.comm.dev/D14922

2025-07-15

[identity] Allow linking Farcaster DCs Summary: 1. Expose a new endpoint that allows linking the DCs 2. Add an option to provide the token during registration https://linear.app/comm/issue/ENG-10893/receive-and-store-a-token-from-farcaster Test Plan: TODO Reviewers: kamil, bartek Subscribers: ashoat Differential Revision: https://phab.comm.dev/D14922

[lib] Add info about DCs token into Identity Summary: https://linear.app/comm/issue/ENG-10903/inform-all-the-users-devices-about-the-successful-connection Depends on D14927 Test Plan: TODO Reviewers: kamil, bartek Subscribers: ashoat Differential Revision: https://phab.comm.dev/D14931

[lib] Add info about DCs token into Identity Summary: https://linear.app/comm/issue/ENG-10903/inform-all-the-users-devices-about-the-successful-connection Depends on D14927 Test Plan: TODO Reviewers: kamil, bartek

[identity] Allow linking Farcaster DCs Summary: 1. Expose a new endpoint that allows linking the DCs 2. Add an option to provide the token during registration https://linear.app/comm/issue/ENG-10893/receive-and-store-a-token-from-farcaster Test Plan: TODO Reviewers: kamil, bartek Subscribers: ashoat Differential Revision: https://phab.comm.dev/D14922

[identity] Allow linking Farcaster DCs Summary: 1. Expose a new endpoint that allows linking the DCs 2. Add an option to provide the token during registration https://linear.app/comm/issue/ENG-10893/receive-and-store-a-token-from-farcaster Test Plan: TODO Reviewers: kamil, bartek Subscribers: ashoat Differential Revision: https://phab.comm.dev/D14922

2025-07-14

[identity] Allow linking Farcaster DCs Summary: 1. Expose a new endpoint that allows linking the DCs 2. Add an option to provide the token during registration https://linear.app/comm/issue/ENG-10893/receive-and-store-a-token-from-farcaster Test Plan: TODO Reviewers: kamil, bartek Subscribers: ashoat Differential Revision: https://phab.comm.dev/D14922

[identity] Allow linking Farcaster DCs Summary: 1. Expose a new endpoint that allows linking the DCs 2. Add an option to provide the token during registration https://linear.app/comm/issue/ENG-10893/receive-and-store-a-token-from-farcaster Test Plan: TODO Reviewers: kamil, bartek Subscribers: ashoat Differential Revision: https://phab.comm.dev/D14922

[identity] Allow linking Farcaster DCs Summary: 1. Expose a new endpoint that allows linking the DCs 2. Add an option to provide the token during registration https://linear.app/comm/issue/ENG-10893/receive-and-store-a-token-from-farcaster Test Plan: TODO Reviewers: kamil, bartek

2025-05-28

[proto] Add devices filter param to X3DH RPC requests Summary: Part of [[ https://linear.app/comm/issue/ENG-10782/add-rpc-allowing-fetching-outbound-keys-for-users-with-whitelisted | ENG-10782 ]]. Added a param to Inbound/Outbound keys RPC requests. The param specifies a white list of devices for which we want to retrieve keys. On old clients built before this change, this field being missing is treated as an empty list. Treating empty lists as "unfiltered" will retain existing behavior and guarantee backwards-compatibility. From [[ https://protobuf.dev/programming-guides/proto3/#default | proto docs ]] about defaults: > The default value for repeated fields is empty (generally an empty list in the appropriate language). Test Plan: Tested two things: - Calling updated Inbound/Outbound from "old" clients built before this change - Calling these RPCs from new clients built with updated proto definitions Reviewers: tomek, kamil, ashoat Reviewed By: tomek, kamil, ashoat Differential Revision: https://phab.comm.dev/D14758

[proto] Add devices filter param to X3DH RPC requests Summary: Part of [[ https://linear.app/comm/issue/ENG-10782/add-rpc-allowing-fetching-outbound-keys-for-users-with-whitelisted | ENG-10782 ]]. Added a param to Inbound/Outbound keys RPC requests. The param specifies a white list of devices for which we want to retrieve keys. On old clients built before this change, this field being missing is treated as an empty list. Treating empty lists as "unfiltered" will retain existing behavior and guarantee backwards-compatibility. From [[ https://protobuf.dev/programming-guides/proto3/#default | proto docs ]] about defaults: > The default value for repeated fields is empty (generally an empty list in the appropriate language). Test Plan: Tested two things: - Calling updated Inbound/Outbound from "old" clients built before this change - Calling these RPCs from new clients built with updated proto definitions Reviewers: tomek, kamil, ashoat Differential Revision: https://phab.comm.dev/D14758

2025-05-26

[proto] Add devices filter param to X3DH RPC requests Summary: Part of [[ https://linear.app/comm/issue/ENG-10782/add-rpc-allowing-fetching-outbound-keys-for-users-with-whitelisted | ENG-10782 ]]. Added a param to Inbound/Outbound keys RPC requests. The param specifies a white list of devices for which we want to retrieve keys. On old clients built before this change, this field being missing is treated as an empty list. Treating empty lists as "unfiltered" will retain existing behavior and guarantee backwards-compatibility. From [[ https://protobuf.dev/programming-guides/proto3/#default | proto docs ]] about defaults: > The default value for repeated fields is empty (generally an empty list in the appropriate language). Test Plan: Tested two things: - Calling updated Inbound/Outbound from "old" clients built before this change - Calling these RPCs from new clients built with updated proto definitions Reviewers: tomek, kamil, ashoat Differential Revision: https://phab.comm.dev/D14758

[proto] Add devices filter param to X3DH RPC requests Summary: Part of [[ https://linear.app/comm/issue/ENG-10782/add-rpc-allowing-fetching-outbound-keys-for-users-with-whitelisted | ENG-10782 ]]. Added a param to Inbound/Outbound keys RPC requests. The param specifies a white list of devices for which we want to retrieve keys. On old clients built before this change, this field being missing is treated as an empty list. Treating empty lists as "unfiltered" will retain existing behavior and guarantee backwards-compatibility. From [[ https://protobuf.dev/programming-guides/proto3/#default | proto docs ]] about defaults: > The default value for repeated fields is empty (generally an empty list in the appropriate language). Test Plan: Tested two things: - Calling updated Inbound/Outbound from "old" clients built before this change - Calling these RPCs from new clients built with updated proto definitions Reviewers: tomek, kamil, ashoat Differential Revision: https://phab.comm.dev/D14758

[proto] Add devices filter param to X3DH RPC requests Summary: Part of [[ https://linear.app/comm/issue/ENG-10782/add-rpc-allowing-fetching-outbound-keys-for-users-with-whitelisted | ENG-10782 ]]. Added a param to Inbound/Outbound keys RPC requests. The param specifies a white list of devices for which we want to retrieve keys. On old clients built before this change, this field being missing is treated as an empty list. Treating empty lists as "unfiltered" will retain existing behavior and guarantee backwards-compatibility. From [[ https://protobuf.dev/programming-guides/proto3/#default | proto docs ]] about defaults: > The default value for repeated fields is empty (generally an empty list in the appropriate language). Test Plan: Tested two things: - Calling updated Inbound/Outbound from "old" clients built before this change - Calling these RPCs from new clients built with updated proto definitions Reviewers: tomek, kamil, ashoat Differential Revision: https://phab.comm.dev/D14758

[proto] Add devices filter param to X3DH RPC requests Summary: Part of [[ https://linear.app/comm/issue/ENG-10782/add-rpc-allowing-fetching-outbound-keys-for-users-with-whitelisted | ENG-10782 ]]. Added a param to Inbound/Outbound keys RPC requests. The param specifies a white list of devices for which we want to retrieve keys. On old clients built before this change, this field being missing is treated as an empty list. Treating empty lists as "unfiltered" will retain existing behavior and guarantee backwards-compatibility. From [[ https://protobuf.dev/programming-guides/proto3/#default | proto docs ]] about defaults: > The default value for repeated fields is empty (generally an empty list in the appropriate language). Test Plan: Tested two things: - Calling updated Inbound/Outbound from "old" clients built before this change - Calling these RPCs from new clients built with updated proto definitions Reviewers: tomek, kamil, ashoat Differential Revision: https://phab.comm.dev/D14758

[proto] Add devices filter param to X3DH RPC requests Summary: Part of [[ https://linear.app/comm/issue/ENG-10782/add-rpc-allowing-fetching-outbound-keys-for-users-with-whitelisted | ENG-10782 ]]. Added a param to Inbound/Outbound keys RPC requests. The param specifies a white list of devices for which we want to retrieve keys. On old clients built before this change, this field being missing is treated as an empty list. Treating empty lists as "unfiltered" will retain existing behavior and guarantee backwards-compatibility. From [[ https://protobuf.dev/programming-guides/proto3/#default | proto docs ]] about defaults: > The default value for repeated fields is empty (generally an empty list in the appropriate language). Test Plan: Tested two things: - Calling updated Inbound/Outbound from "old" clients built before this change - Calling these RPCs from new clients built with updated proto definitions Reviewers: tomek, kamil, ashoat Differential Revision: https://phab.comm.dev/D14758

[proto] Add devices filter param to X3DH RPC requests Summary: Part of [[ https://linear.app/comm/issue/ENG-10782/add-rpc-allowing-fetching-outbound-keys-for-users-with-whitelisted | ENG-10782 ]]. Added a param to Inbound/Outbound keys RPC requests. The param specifies a white list of devices for which we want to retrieve keys. On old clients built before this change, this field being missing is treated as an empty list. Treating empty lists as "unfiltered" will retain existing behavior and guarantee backwards-compatibility. From [[ https://protobuf.dev/programming-guides/proto3/#default | proto docs ]] about defaults: > The default value for repeated fields is empty (generally an empty list in the appropriate language). Test Plan: Tested two things: - Calling updated Inbound/Outbound from "old" clients built before this change - Calling these RPCs from new clients built with updated proto definitions Reviewers: tomek, kamil, ashoat Subscribers:

2025-04-14

[shared] Update NEXT_CODE_VERSION 483 for `native`, and 161 for `web`

2025-03-31

[protos] Update comment with NEXT_CODE_VERSION Summary: https://linear.app/comm/issue/ENG-10427/update-proto-comment-after-landing-client-changes Depends on D14508 Test Plan: None Reviewers: kamil, ashoat Reviewed By: ashoat Subscribers: tomek Differential Revision: https://phab.comm.dev/D14509

2025-03-27

[protos] Update comment with NEXT_CODE_VERSION Summary: https://linear.app/comm/issue/ENG-10427/update-proto-comment-after-landing-client-changes Depends on D14508 Test Plan: None Reviewers: kamil, ashoat Subscribers:

2025-03-26

[protos][identity] Remove primary device info from GetKeyserverKeys Summary: Address [[ https://linear.app/comm/issue/ENG-10247/handle-getkeyserverkeys-when-primary-is-logged-out | ENG-10247 ]]. We can remove this field. Although this is backwards compatible since this field wasn't used anywhere, I marked the field as 'reserved' to avoid reusing its number. Doing so would cause parsing errors on old clients Test Plan: flow, staging identity Reviewers: ashoat, kamil Reviewed By: ashoat, kamil Subscribers: tomek Differential Revision: https://phab.comm.dev/D14492

[protos][identity] Remove primary device info from GetKeyserverKeys Summary: Address [[ https://linear.app/comm/issue/ENG-10247/handle-getkeyserverkeys-when-primary-is-logged-out | ENG-10247 ]]. We can remove this field. Although this is backwards compatible since this field wasn't used anywhere, I marked the field as 'reserved' to avoid reusing its number. Doing so would cause parsing errors on old clients Test Plan: flow, staging identity Reviewers: ashoat!, kamil! Subscribers: tomek Differential Revision: https://phab.comm.dev/D14492

2025-03-24

[protos][identity] Remove primary device info from GetKeyserverKeys Summary: Address [[ https://linear.app/comm/issue/ENG-10247/handle-getkeyserverkeys-when-primary-is-logged-out | ENG-10247 ]]. We can remove this field. Although this is backwards compatible since this field wasn't used anywhere, I marked the field as 'reserved' to avoid reusing its number. Doing so would cause parsing errors on old clients Test Plan: flow, staging identity Reviewers: ashoat!, kamil! Subscribers: tomek Differential Revision: https://phab.comm.dev/D14492

[protos][identity] Remove primary device info from GetKeyserverKeys Summary: Address [[ https://linear.app/comm/issue/ENG-10247/handle-getkeyserverkeys-when-primary-is-logged-out | ENG-10247 ]]. We can remove this field. Although this is backwards compatible since this field wasn't used anywhere, I marked the field as 'reserved' to avoid reusing its number. Doing so would cause parsing errors on old clients Test Plan: flow, staging identity Reviewers: ashoat!, kamil! Subscribers:

2025-02-28

[proto] Add comment about siwe fields being social proof Summary: Address [[ https://linear.app/comm/issue/ENG-10151/add-proto-comments-clarifying-siwe-messagessignatures | ENG-10151 ]]. Added comment that `siwe_message` and `siwe_signature` are social proof related fields. Related: D14255 Test Plan: None Reviewers: kamil Reviewed By: kamil Subscribers: ashoat, tomek Differential Revision: https://phab.comm.dev/D14419

2025-02-27

[proto] Add comment about siwe fields being social proof Summary: Address [[ https://linear.app/comm/issue/ENG-10151/add-proto-comments-clarifying-siwe-messagessignatures | ENG-10151 ]]. Added comment that `siwe_message` and `siwe_signature` are social proof related fields. Related: D14255 Test Plan: None Reviewers: kamil Subscribers: ashoat, tomek Differential Revision: https://phab.comm.dev/D14419

[proto] Add comment about siwe fields being social proof Summary: Address [[ https://linear.app/comm/issue/ENG-10151/add-proto-comments-clarifying-siwe-messagessignatures | ENG-10151 ]]. Added comment that `siwe_message` and `siwe_signature` are social proof related fields. Related: D14255 Test Plan: None Reviewers: kamil Subscribers:

2025-02-05

[proto] Add UserKeys backup fields to RestoreUserRequest Summary: [[ https://linear.app/comm/issue/ENG-10114/modify-the-proto-so-that-the-user-keys-backup-is-a-part-of-the | ENG-10114 ]], details in its parent task. Added fields related to UserKeys backup to RestoreUser RPC. Depends on D14279 Test Plan: flow, cargo build. Full test plan in D14273 which is closely related to this diff Reviewers: tomek, ashoat, bartek Reviewed By: ashoat Subscribers: ashoat Differential Revision: https://phab.comm.dev/D14280

2025-02-02

[proto] Add UserKeys backup fields to RestoreUserRequest Summary: TBD Depends on D14279 Test Plan: TBD Reviewers: kamil, tomek Subscribers: ashoat Differential Revision: https://phab.comm.dev/D14280

2025-01-30

[proto] Add UserKeys backup fields to RestoreUserRequest Summary: TBD Depends on D14279 Test Plan: TBD Reviewers: kamil, tomek Subscribers: ashoat Differential Revision: https://phab.comm.dev/D14280

[proto] Add UserKeys backup fields to RestoreUserRequest Summary: TBD Depends on D14279 Test Plan: TBD Reviewers: kamil, tomek Subscribers: ashoat Differential Revision: https://phab.comm.dev/D14280

[proto] Add UserKeys backup fields to RestoreUserRequest Summary: TBD Depends on D14279 Test Plan: TBD Reviewers: kamil, tomek Subscribers: ashoat Differential Revision: https://phab.comm.dev/D14280

[proto] Add UserKeys backup fields to RestoreUserRequest Summary: TBD Depends on D14279 Test Plan: TBD Reviewers: kamil, tomek Subscribers:

2025-01-14

[protos] Add skipPasswordReset field to PrivilegedResetUserPassword Summary: Part of [[ https://linear.app/comm/issue/ENG-9628/plan-for-reverting-individual-users-to-v1-login | ENG-9628 ]] As mentioned in [[ https://linear.app/comm/issue/ENG-9628/plan-for-reverting-individual-users-to-v1-login#comment-2ef488a6 | this discussion ]], we want a flag to skip password reset while reverting users to V1 flows. Test Plan: CI, flow Reviewers: ashoat, kamil, tomek Reviewed By: ashoat Differential Revision: https://phab.comm.dev/D14198

2025-01-13

[protos] Add skipPasswordReset field to PrivilegedResetUserPassword Summary: Part of [[ https://linear.app/comm/issue/ENG-9628/plan-for-reverting-individual-users-to-v1-login | ENG-9628 ]] As mentioned in [[ https://linear.app/comm/issue/ENG-9628/plan-for-reverting-individual-users-to-v1-login#comment-2ef488a6 | this discussion ]], we want a flag to skip password reset while reverting users to V1 flows. Test Plan: CI, flow Reviewers: ashoat, kamil, tomek Differential Revision: https://phab.comm.dev/D14198

[protos] Add skipPasswordReset field to PrivilegedResetUserPassword Summary: Part of [[ https://linear.app/comm/issue/ENG-9628/plan-for-reverting-individual-users-to-v1-login | ENG-9628 ]] As mentioned in [[ https://linear.app/comm/issue/ENG-9628/plan-for-reverting-individual-users-to-v1-login#comment-2ef488a6 | this discussion ]], we want a flag to skip password reset while reverting users to V1 flows. Test Plan: CI, flow Reviewers: ashoat, kamil, tomek Differential Revision: https://phab.comm.dev/D14198

[protos] Add skipPasswordReset field to PrivilegedResetUserPassword Summary: Part of [[ https://linear.app/comm/issue/ENG-9628/plan-for-reverting-individual-users-to-v1-login | ENG-9628 ]] As mentioned in [[ https://linear.app/comm/issue/ENG-9628/plan-for-reverting-individual-users-to-v1-login#comment-2ef488a6 | this discussion ]], we want a flag to skip password reset while reverting users to V1 flows. Test Plan: CI, flow Reviewers: ashoat, kamil, tomek Subscribers:

2024-10-21

[proto] introduce new privileged rpcs for resetting user passwords Summary: we'll call these rpcs from a keyserver script when a user needs their password reset. will only allow-list ashoat's user ID for the time being, as we do with the privileged delete user rpc Test Plan: tested at end of stack by calling rpcs from keyserver script Reviewers: ashoat Reviewed By: ashoat Subscribers: tomek Differential Revision: https://phab.comm.dev/D13759

[proto] introduce new privileged rpcs for resetting user passwords Summary: we'll call these rpcs from a keyserver script when a user needs their password reset. will only allow-list ashoat's user ID for the time being, as we do with the privileged delete user rpc Test Plan: tested at end of stack by calling rpcs from keyserver script Reviewers: ashoat Subscribers: tomek Differential Revision: https://phab.comm.dev/D13759

[proto] introduce new privileged rpcs for resetting user passwords Summary: we'll call these rpcs from a keyserver script when a user needs their password reset. will only allow-list ashoat's user ID for the time being, as we do with the privileged delete user rpc Test Plan: tested at end of stack by calling rpcs from keyserver script Reviewers: ashoat Subscribers: tomek Differential Revision: https://phab.comm.dev/D13759

[proto] introduce new privileged rpcs for resetting user passwords Summary: we'll call these rpcs from a keyserver script when a user needs their password reset. will only allow-list ashoat's user ID for the time being, as we do with the privileged delete user rpc Test Plan: tested at end of stack by calling rpcs from keyserver script Reviewers: ashoat Subscribers:

2024-10-08

[proto] privileged delete users RPC Summary: we need this RPC to delete users who are sending spam on Comm Test Plan: tested at end of stack by calling the RPC Reviewers: ashoat, bartek, will Reviewed By: ashoat, bartek Subscribers: tomek Differential Revision: https://phab.comm.dev/D13629

[proto] privileged delete users RPC Summary: we need this RPC to delete users who are sending spam on Comm Test Plan: tested at end of stack by calling the RPC Reviewers: ashoat, bartek, will Subscribers: tomek Differential Revision: https://phab.comm.dev/D13629

[proto] privileged delete users RPC Summary: we need this RPC to delete users who are sending spam on Comm Test Plan: tested at end of stack by calling the RPC Reviewers: ashoat, bartek, will Subscribers:

2024-09-13

[protos][identity] Add RestoreUser RPCs Summary: Address [[ https://linear.app/comm/issue/ENG-8210/add-restore-rpcs-to-proto-and-grpc-web | ENG-8210 ]]. Added `RestorePasswordUser` and `RestoreWalletUser` RPCs. These are described as "a single RPC" in the Whitepaper 5.2. The API is very similiar to `LogInPasswordUser[Start]` / `LogInWalletUser`, with the additional device list payload. Also, we're not doing OPAQUE login here for password users. Test Plan: Flow, identity compiles. Reviewers: ashoat, varun Reviewed By: ashoat, varun Subscribers: tomek Differential Revision: https://phab.comm.dev/D13221

[protos][identity] Add RestoreUser RPCs Summary: Address [[ https://linear.app/comm/issue/ENG-8210/add-restore-rpcs-to-proto-and-grpc-web | ENG-8210 ]]. Added `RestorePasswordUser` and `RestoreWalletUser` RPCs. These are described as "a single RPC" in the Whitepaper 5.2. The API is very similiar to `LogInPasswordUser[Start]` / `LogInWalletUser`, with the additional device list payload. Also, we're not doing OPAQUE login here for password users. Test Plan: Flow, identity compiles. Reviewers: ashoat!, varun! Subscribers: tomek Differential Revision: https://phab.comm.dev/D13221

2024-09-11

[protos][identity] Add RestoreUser RPCs Summary: Address [[ https://linear.app/comm/issue/ENG-8210/add-restore-rpcs-to-proto-and-grpc-web | ENG-8210 ]]. Added `RestorePasswordUser` and `RestoreWalletUser` RPCs. These are described as "a single RPC" in the Whitepaper 5.2. The API is very similiar to `LogInPasswordUser[Start]` / `LogInWalletUser`, with the additional device list payload. Also, we're not doing OPAQUE login here for password users. Test Plan: Flow, identity compiles. Reviewers: ashoat!, varun! Subscribers: tomek Differential Revision: https://phab.comm.dev/D13221

2024-09-09

[tunnelbroker] Add RPC for closing WebSocket sessions Summary: Address [[ https://linear.app/comm/issue/ENG-8217/add-tunnelbroker-rpc-to-close-sessions | ENG-8217 ]]. Added Tunnelbroker RPC that force-closes WebSocket session with given device ID (if present). The message is not persisted - it makes no point of storing it if the device isn't connected to Tunnelbroker at the time. Depends on D13227 Test Plan: Repeated test plan from D13227, now by calling the RPC Reviewers: kamil, ashoat Reviewed By: kamil, ashoat Subscribers: tomek Differential Revision: https://phab.comm.dev/D13228

[tunnelbroker] Add RPC for closing WebSocket sessions Summary: Address [[ https://linear.app/comm/issue/ENG-8217/add-tunnelbroker-rpc-to-close-sessions | ENG-8217 ]]. Added Tunnelbroker RPC that force-closes WebSocket session with given device ID (if present). The message is not persisted - it makes no point of storing it if the device isn't connected to Tunnelbroker at the time. Depends on D13227 Test Plan: Repeated test plan from D13227, now by calling the RPC Reviewers: kamil!, ashoat Subscribers: tomek Differential Revision: https://phab.comm.dev/D13228

[protos][identity] Add RestoreUser RPCs Summary: Address [[ https://linear.app/comm/issue/ENG-8210/add-restore-rpcs-to-proto-and-grpc-web | ENG-8210 ]]. Added `RestorePasswordUser` and `RestoreWalletUser` RPCs. These are described as "a single RPC" in the Whitepaper 5.2. The API is very similiar to `LogInPasswordUser[Start]` / `LogInWalletUser`, with the additional device list payload. Also, we're not doing OPAQUE login here for password users. Test Plan: Flow, identity compiles. Reviewers: ashoat!, varun! Subscribers: tomek Differential Revision: https://phab.comm.dev/D13221

[protos][identity] Add RestoreUser RPCs Summary: Address [[ https://linear.app/comm/issue/ENG-8210/add-restore-rpcs-to-proto-and-grpc-web | ENG-8210 ]]. Added `RestorePasswordUser` and `RestoreWalletUser` RPCs. These are described as "a single RPC" in the Whitepaper 5.2. The API is very similiar to `LogInPasswordUser[Start]` / `LogInWalletUser`, with the additional device list payload. Also, we're not doing OPAQUE login here for password users. Test Plan: Flow, identity compiles. Reviewers: ashoat!, varun! Subscribers: tomek Differential Revision: https://phab.comm.dev/D13221

2024-09-04

[protos][identity] Add RestoreUser RPCs Summary: Address [[ https://linear.app/comm/issue/ENG-8210/add-restore-rpcs-to-proto-and-grpc-web | ENG-8210 ]]. Added `RestorePasswordUser` and `RestoreWalletUser` RPCs. These are described as "a single RPC" in the Whitepaper 5.2. The API is very similiar to `LogInPasswordUser[Start]` / `LogInWalletUser`, with the additional device list payload. Also, we're not doing OPAQUE login here for password users. Test Plan: Flow, identity compiles. Reviewers: ashoat!, varun! Subscribers: tomek Differential Revision: https://phab.comm.dev/D13221

[tunnelbroker] Add RPC for closing WebSocket sessions Summary: Address [[ https://linear.app/comm/issue/ENG-8217/add-tunnelbroker-rpc-to-close-sessions | ENG-8217 ]]. Added Tunnelbroker RPC that force-closes WebSocket session with given device ID (if present). The message is not persisted - it makes no point of storing it if the device isn't connected to Tunnelbroker at the time. Depends on D13227 Test Plan: Repeated test plan from D13227, now by calling the RPC Reviewers: kamil!, ashoat Subscribers: tomek Differential Revision: https://phab.comm.dev/D13228

2024-09-03

[tunnelbroker] Add RPC for closing WebSocket sessions Summary: Address [[ https://linear.app/comm/issue/ENG-8217/add-tunnelbroker-rpc-to-close-sessions | ENG-8217 ]]. Added Tunnelbroker RPC that force-closes WebSocket session with given device ID (if present). The message is not persisted - it makes no point of storing it if the device isn't connected to Tunnelbroker at the time. Depends on D13227 Test Plan: Repeated test plan from D13227, now by calling the RPC Reviewers: kamil!, ashoat Subscribers: tomek Differential Revision: https://phab.comm.dev/D13228

[tunnelbroker] Add RPC for closing WebSocket sessions Summary: Address [[ https://linear.app/comm/issue/ENG-8217/add-tunnelbroker-rpc-to-close-sessions | ENG-8217 ]]. Added Tunnelbroker RPC that force-closes WebSocket session with given device ID (if present). The message is not persisted - it makes no point of storing it if the device isn't connected to Tunnelbroker at the time. Depends on D13227 Test Plan: Repeated test plan from D13227, now by calling the RPC Reviewers: kamil!, ashoat Subscribers:

[protos][identity] Add RestoreUser RPCs Summary: Address [[ https://linear.app/comm/issue/ENG-8210/add-restore-rpcs-to-proto-and-grpc-web | ENG-8210 ]]. Added `RestorePasswordUser` and `RestoreWalletUser` RPCs. These are described as "a single RPC" in the Whitepaper 5.2. The API is very similiar to `LogInPasswordUser[Start]` / `LogInWalletUser`, with the additional device list payload. Also, we're not doing OPAQUE login here for password users. Test Plan: Flow, identity compiles. Reviewers: ashoat!, varun! Subscribers: tomek Differential Revision: https://phab.comm.dev/D13221

[protos][identity] Add RestoreUser RPCs Summary: Address [[ https://linear.app/comm/issue/ENG-8210/add-restore-rpcs-to-proto-and-grpc-web | ENG-8210 ]]. Added `RestorePasswordUser` and `RestoreWalletUser` RPCs. These are described as "a single RPC" in the Whitepaper 5.2. The API is very similiar to `LogInPasswordUser[Start]` / `LogInWalletUser`, with the additional device list payload. Also, we're not doing OPAQUE login here for password users. Test Plan: Flow, identity compiles. Reviewers: ashoat!, varun! Subscribers:

2024-07-31

[protos][identity] Add reserved usernames to UserIdentitiesResponse Summary: First part of [[ https://linear.app/comm/issue/ENG-8771/search-identity-reserved-usernames-in-finduseridentities | ENG-8771 ]] - added a new response field as proposed in [[ https://linear.app/comm/issue/ENG-8771/search-identity-reserved-usernames-in-finduseridentities#comment-f8a85c4a | this comment ]]. This change is backwards compatible, regardless if we release identity first or clients first. The new field will simply default to an empty map. Test Plan: Flow, cargo build. Logic is added in the next diffs Reviewers: ashoat, varun Reviewed By: ashoat, varun Subscribers: tomek Differential Revision: https://phab.comm.dev/D12922

[protos][identity] Add reserved usernames to UserIdentitiesResponse Summary: First part of [[ https://linear.app/comm/issue/ENG-8771/search-identity-reserved-usernames-in-finduseridentities | ENG-8771 ]] - added a new response field as proposed in [[ https://linear.app/comm/issue/ENG-8771/search-identity-reserved-usernames-in-finduseridentities#comment-f8a85c4a | this comment ]]. This change is backwards compatible, regardless if we release identity first or clients first. The new field will simply default to an empty map. Test Plan: Flow, cargo build. Logic is added in the next diffs Reviewers: ashoat!, varun Subscribers: tomek Differential Revision: https://phab.comm.dev/D12922

[protos][identity] Add reserved usernames to UserIdentitiesResponse Summary: First part of [[ https://linear.app/comm/issue/ENG-8771/search-identity-reserved-usernames-in-finduseridentities | ENG-8771 ]] - added a new response field as proposed in [[ https://linear.app/comm/issue/ENG-8771/search-identity-reserved-usernames-in-finduseridentities#comment-f8a85c4a | this comment ]]. This change is backwards compatible, regardless if we release identity first or clients first. The new field will simply default to an empty map. Test Plan: Flow, cargo build. Logic is added in the next diffs Reviewers: ashoat!, varun Subscribers: tomek Differential Revision: https://phab.comm.dev/D12922

2024-07-29

[protos][identity] Add reserved usernames to UserIdentitiesResponse Summary: First part of [[ https://linear.app/comm/issue/ENG-8771/search-identity-reserved-usernames-in-finduseridentities | ENG-8771 ]] - added a new response field as proposed in [[ https://linear.app/comm/issue/ENG-8771/search-identity-reserved-usernames-in-finduseridentities#comment-f8a85c4a | this comment ]]. This change is backwards compatible, regardless if we release identity first or clients first. The new field will simply default to an empty map. Test Plan: Flow, cargo build. Logic is added in the next diffs Reviewers: ashoat!, varun Subscribers: tomek Differential Revision: https://phab.comm.dev/D12922

[protos][identity] Add reserved usernames to UserIdentitiesResponse Summary: First part of [[ https://linear.app/comm/issue/ENG-8771/search-identity-reserved-usernames-in-finduseridentities | ENG-8771 ]] - added a new response field as proposed in [[ https://linear.app/comm/issue/ENG-8771/search-identity-reserved-usernames-in-finduseridentities#comment-f8a85c4a | this comment ]]. This change is backwards compatible, regardless if we release identity first or clients first. The new field will simply default to an empty map. Test Plan: Flow, cargo build. Logic is added in the next diffs Reviewers: ashoat!, varun Subscribers:

2024-07-08

[identity][proto] addWallet RPC Summary: https://linear.app/comm/issue/ENG-8306/addwalletstart-rpc do SIWE and add the wallet address to the user's item in the DDB users table if it's successful Test Plan: wallet login works. if nonce is expired, i get back the correct tonic status message Reviewers: bartek!, ashoat! Subscribers: tomek Differential Revision: https://phab.comm.dev/D12575

2024-07-03

[protos][identity] Add LogOutPrimaryDevice RPC Summary: [[ https://linear.app/comm/issue/ENG-7876/add-logoutprimarydevice-rpc | ENG-7876 ]]. Adding RPC that is going to be called by primary device to log out the primary device and all other user's devices. It is going to invalidate CSAT for all of them. It requires signed device list as an input - primary device logout will result in device list being replaced by a singleton of the primary device being logged out. Test Plan: Identity and flow compiles. RPC implementation will be added in later diffs Reviewers: ashoat, varun Reviewed By: ashoat, varun Subscribers: tomek Differential Revision: https://phab.comm.dev/D12571

[protos][identity] Add LogOutPrimaryDevice RPC Summary: [[ https://linear.app/comm/issue/ENG-7876/add-logoutprimarydevice-rpc | ENG-7876 ]]. Adding RPC that is going to be called by primary device to log out the primary device and all other user's devices. It is going to invalidate CSAT for all of them. It requires signed device list as an input - primary device logout will result in device list being replaced by a singleton of the primary device being logged out. Test Plan: Identity and flow compiles. RPC implementation will be added in later diffs Reviewers: ashoat!, varun Subscribers: tomek Differential Revision: https://phab.comm.dev/D12571

2024-07-02

[protos][identity] Add LogOutPrimaryDevice RPC Summary: [[ https://linear.app/comm/issue/ENG-7876/add-logoutprimarydevice-rpc | ENG-7876 ]]. Adding RPC that is going to be called by primary device to log out the primary device and all other user's devices. It is going to invalidate CSAT for all of them. It requires signed device list as an input - primary device logout will result in device list being replaced by a singleton of the primary device being logged out. Test Plan: Identity and flow compiles. RPC implementation will be added in later diffs Reviewers: ashoat!, varun Subscribers: tomek Differential Revision: https://phab.comm.dev/D12571

2024-07-01

[proto][Tunnelbroker] add RPC to delete device data from Tunnelbroker Summary: [ENG-8400](https://linear.app/comm/issue/ENG-8400/biggest-risk-tunnelbroker-inform-device-about-invalid-device-token) (see point 5. Logout). This RPC will be used by Identity to inform Tunnelbroker about device logout. Now remove the device token. Creating a follow-up task to delete persisted messages to device ([ENG-8495](https://linear.app/comm/issue/ENG-8495/implement-removing-data-from-tunnelbroker-undelivered-messages-on)). Test Plan: Tested in next diff Reviewers: bartek, marcin, ashoat Reviewed By: bartek, ashoat Subscribers: tomek Differential Revision: https://phab.comm.dev/D12525

[proto][Tunnelbroker] add RPC to delete device data from Tunnelbroker Summary: [ENG-8400](https://linear.app/comm/issue/ENG-8400/biggest-risk-tunnelbroker-inform-device-about-invalid-device-token) (see point 5. Logout). This RPC will be used by Identity to inform Tunnelbroker about device logout. Test Plan: Tested in next diff Reviewers: bartek, marcin, ashoat! Subscribers: tomek Differential Revision: https://phab.comm.dev/D12525

2024-06-28

[proto][Tunnelbroker] add RPC to delete device data from Tunnelbroker Summary: [ENG-8400](https://linear.app/comm/issue/ENG-8400/biggest-risk-tunnelbroker-inform-device-about-invalid-device-token) (see point 5. Logout). This RPC will be used by Identity to inform Tunnelbroker about device logout. Test Plan: Tested in next diff Reviewers: bartek, marcin, ashoat! Subscribers: tomek Differential Revision: https://phab.comm.dev/D12525

2024-06-27

[protos][identity] Add LogOutPrimaryDevice RPC Summary: [[ https://linear.app/comm/issue/ENG-7876/add-logoutprimarydevice-rpc | ENG-7876 ]]. Adding RPC that is going to be called by primary device to log out the primary device and all other user's devices. It is going to invalidate CSAT for all of them. It requires signed device list as an input - primary device logout will result in device list being replaced by a singleton of the primary device being logged out. Test Plan: Identity and flow compiles. RPC implementation will be added in later diffs Reviewers: ashoat!, varun Subscribers: tomek Differential Revision: https://phab.comm.dev/D12571

2024-06-26

[protos][identity] Add LogOutPrimaryDevice RPC Summary: [[ https://linear.app/comm/issue/ENG-7876/add-logoutprimarydevice-rpc | ENG-7876 ]]. Adding RPC that is going to be called by primary device to log out the primary device and all other user's devices. It is going to invalidate CSAT for all of them. It requires signed device list as an input - primary device logout will result in device list being replaced by a singleton of the primary device being logged out. Test Plan: Identity and flow compiles. RPC implementation will be added in later diffs Reviewers: ashoat!, varun Subscribers: tomek Differential Revision: https://phab.comm.dev/D12571

2024-06-25

[identity][proto] addWallet RPC Summary: https://linear.app/comm/issue/ENG-8306/addwalletstart-rpc do SIWE and add the wallet address to the user's item in the DDB users table if it's successful Test Plan: wallet login works. if nonce is expired, i get back the correct tonic status message Reviewers: bartek!, ashoat! Subscribers: tomek Differential Revision: https://phab.comm.dev/D12575

[identity][proto] addWallet RPC Summary: https://linear.app/comm/issue/ENG-8306/addwalletstart-rpc do SIWE and add the wallet address to the user's item in the DDB users table if it's successful Test Plan: wallet login works. if nonce is expired, i get back the correct tonic status message Reviewers: bartek!, ashoat! Subscribers:

[protos][identity] Add LogOutPrimaryDevice RPC Summary: [[ https://linear.app/comm/issue/ENG-7876/add-logoutprimarydevice-rpc | ENG-7876 ]]. Adding RPC that is going to be called by primary device to log out the primary device and all other user's devices. It is going to invalidate CSAT for all of them. It requires signed device list as an input - primary device logout will result in device list being replaced by a singleton of the primary device being logged out. Test Plan: Identity and flow compiles. RPC implementation will be added in later diffs Reviewers: ashoat!, varun Subscribers:

2024-06-24

remove reserved wallet registration RPC Summary: we don't need this. SIWE is enough to prove that a user owns a particular wallet address Depends on D12546 Test Plan: everything builds, git grep'd for any remaining references to this RPC and message type Reviewers: bartek Reviewed By: bartek Subscribers: ashoat, tomek Differential Revision: https://phab.comm.dev/D12547

remove reserved wallet registration RPC Summary: we don't need this. SIWE is enough to prove that a user owns a particular wallet address Depends on D12546 Test Plan: everything builds, git grep'd for any remaining references to this RPC and message type Reviewers: bartek! Subscribers: ashoat, tomek Differential Revision: https://phab.comm.dev/D12547

2024-06-21

remove reserved wallet registration RPC Summary: we don't need this. SIWE is enough to prove that a user owns a particular wallet address Depends on D12546 Test Plan: everything builds, git grep'd for any remaining references to this RPC and message type Reviewers: bartek! Subscribers: ashoat, tomek Differential Revision: https://phab.comm.dev/D12547

remove reserved wallet registration RPC Summary: we don't need this. SIWE is enough to prove that a user owns a particular wallet address Depends on D12546 Test Plan: everything builds, git grep'd for any remaining references to this RPC and message type Reviewers: bartek! Subscribers:

2024-06-20

[proto][Tunnelbroker] add RPC to delete device data from Tunnelbroker Summary: [ENG-8400](https://linear.app/comm/issue/ENG-8400/biggest-risk-tunnelbroker-inform-device-about-invalid-device-token) (see point 5. Logout). This RPC will be used by Identity to inform Tunnelbroker about device logout. Test Plan: Tested in next diff Reviewers: bartek, marcin, ashoat! Subscribers: tomek Differential Revision: https://phab.comm.dev/D12525

[proto][Tunnelbroker] add RPC to delete device data from Tunnelbroker Summary: [ENG-8400](https://linear.app/comm/issue/ENG-8400/biggest-risk-tunnelbroker-inform-device-about-invalid-device-token) (see point 5. Logout). This RPC will be used by Identity to inform Tunnelbroker about device logout. Test Plan: Tested in next diff Reviewers: bartek, marcin, ashoat!

[identity] update change password RPCs to match whitepaper Summary: per the whitepaper, we want clients to run Password-based Authentication before running Password-based Registration with the new password. Test Plan: tested later in stack by calling the new RPCs from web and native Reviewers: ashoat, bartek Reviewed By: ashoat, bartek Subscribers: tomek Differential Revision: https://phab.comm.dev/D12465

2024-06-19

[identity] update change password RPCs to match whitepaper Summary: per the whitepaper, we want clients to run Password-based Authentication before running Password-based Registration with the new password. Test Plan: tested later in stack by calling the new RPCs from web and native Reviewers: ashoat, bartek Reviewed By: ashoat, bartek Subscribers: tomek Differential Revision: https://phab.comm.dev/D12465

[identity] update change password RPCs to match whitepaper Summary: per the whitepaper, we want clients to run Password-based Authentication before running Password-based Registration with the new password. Test Plan: tested later in stack by calling the new RPCs from web and native Reviewers: ashoat!, bartek! Subscribers: tomek Differential Revision: https://phab.comm.dev/D12465

2024-06-18

[identity] update change password RPCs to match whitepaper Summary: per the whitepaper, we want clients to run Password-based Authentication before running Password-based Registration with the new password. Test Plan: tested later in stack by calling the new RPCs from web and native Reviewers: ashoat!, bartek! Subscribers: tomek Differential Revision: https://phab.comm.dev/D12465

[identity] update change password RPCs to match whitepaper Summary: per the whitepaper, we want clients to run Password-based Authentication before running Password-based Registration with the new password. Test Plan: tested later in stack by calling the new RPCs from web and native Reviewers: ashoat!, bartek! Subscribers: tomek Differential Revision: https://phab.comm.dev/D12465

[identity] update change password RPCs to match whitepaper Summary: per the whitepaper, we want clients to run Password-based Authentication before running Password-based Registration with the new password. Test Plan: tested later in stack by calling the new RPCs from web and native Reviewers: ashoat!, bartek! Subscribers:

2024-06-17

Rename new_content_prekeys and new_notif_prekeys Summary: We only upload one of each type of prekey, so these fields should not be plural Depends on D12436 Test Plan: ran flow, checked all invocations of `RefreshUserPrekeys` to make sure client code reflected the field name changes Reviewers: bartek, ashoat Reviewed By: ashoat Subscribers: tomek Differential Revision: https://phab.comm.dev/D12441

2024-06-14

Rename new_content_prekeys and new_notif_prekeys Summary: We only upload one of each type of prekey, so these fields should not be plural Depends on D12436 Test Plan: ran flow, checked all invocations of `RefreshUserPrekeys` to make sure client code reflected the field name changes Reviewers: bartek, ashoat Subscribers: tomek Differential Revision: https://phab.comm.dev/D12441