Identity Check-In: Agendas and Notes

When: Daily until March 22nd

Tracking Issues:

None, yet


Mar 19, 2024

  • [Rich] - Deciding between one-way and two-way associations, including the decision in the XIP.
  • [Cameron] - Looking at the UX descriptions for users and devs for offchain
  • [Tong] - Looking at how much additional work does this add to decentralization
  • [Andrew] - UX descriptions, looking for feedback on multiple wallet flow for onchain
  • [Nick] - Migration plans

Agenda:

  • Plan to make that decision at tomorrows meeting. What criteria are we using?

    • What’s going to be easiest for us to implement now?
    • How much additional work does this add to decentralization?
    • Migration difficulty?
    • What’s the best for users?
    • What’s the best for developers?
    • Visibility and analytics
    • Cost and risk
  • What other information do we need to make a decision between onchain and offchain?

    • We need to make some smaller decisions between alternatives on each of these proposals to agree on the best possible version of each
    • Technical risk of time-travel @Nick
    • UX description for users @Andrew
    • UX description for developers @Andrew
  • DRI for consolidating all these documents into a coherent XIP for Friday

  • Check in

  • One-way vs two-way

    • Potential for embarrassing ENS names to be associated with strangers
    • We might need a coordination layer anyways for message history
1 Like

Mar 20, 2024

Agenda:

  • Review Team Offchain XIP
  • Review Team Onchain XIP
  • Compare two approaches based on previously defined criteria
    • Security and trust model

      • Offchain might actually be better for EOAs. More trust given to XMTP node to verify the list of identities in onchain.
    • What’s going to be easiest for us to implement now?

      • Multiple forms of sybil resistance in onchain are additional work for us
      • Onchain is simpler at the time of credential verification
      • Sybil resistance is going to be hard. Need to build a whole new set of services around
        these, and maintain availability of them
      • Smart contracts are scary and updates are difficult
      • Audits are expensive and time-consuming
      • Offchain requires more backend work now, and more work to synchronize the registry in a decentralized network
      • Offchain relies heavily on the availability of archive nodes. Onchain only has optional use of an archive node
    • How much additional work does this add to decentralization?

      • Offchain requires new synchronization mechanisms
      • Onchain de-risks decentralization because identity will have independent uptime of XMTP nodes
      • Onchain helps with decentralization narrative. Faster to decentralize and
      • Decentralizing the sybil resistance service will be difficult
      • Having decentralized partners who don’t use subsidized gateway would be a worse experience. But not all partners may want to either subsidize or use our subsidy service
    • Migration difficulty?

      • Offchain can work with existing XMTP identities
      • Onchain is going to be more difficult and costly
    • What’s the best for users?

      • Migration path for existing users is easier in offchain
      • Phone number verification is a new form of friction for onchain
      • 3 signatures for new users until we deprecate V2 fully for onchain
      • Potential privacy impact of phone number verification for onchain
      • A lot of explaining around phone number verification for onchain
      • Have to be on the right chain for SCWs in onchain. Chain agnostic for offchain
    • What’s the best for developers?

      • Onchain is a more familiar set of primitives
      • Latency shouldn’t be a huge difference
      • Both should be cacheable
      • Phone number verification is new work for devs
      • Getting block height in the offchain flow is new work for devs
      • Supporting multi-chain is complicated in onchain solution
      • Public API
    • Visibility and analytics

      • Onchain
    • Cost and risk

      • Offchain is lower risk
  • Decide which path to go down

March 21, 2024

Agenda:

  • Association loose-ends
  • Ideas around improved visibility and analytics
  • Ideas around sybil resistance and slowing down identity registration
  • Next steps for wrapping up the XIP

March 22, 2024

Agenda:

  • XIDs and associations
  • Sequencing of work for next week

March 26, 2024

Agenda

  • Standup
  • XID unresolved questions
    • State sync with MLS.
      • Using epochs to sync group state
      • What happens if there are gaps in the epoch history?
      • Next steps: define the message types for synchronization/revocation messages
    • Moving wallets
      • Is this one step or two steps?
      • What is the worst-case scenario around migrations?
    • Signer

Standup

  • [Andrew] Been working on the traits for credential verification in libxmtp. Set up the new identity crate. Working through a refactor of legacy and EOA.
  • [Tong] Working on the Smart Wallet verification. Testing against Coinbase Smart Wallet.
  • [Rich] Focusing on the unresolved XID questions. What happens if you don’t change the installation keys.
  • [Nick] Writing some of the tickets for the project. Moving to code-writing today (hopefully)

Agenda

Standup

  • [Andrew] Still working through the credential traits
  • [Tong] Working on smart wallet. Deployed the wallet. Currently working on figuring out logic for signature verification. Working towards a short demo. Need to figure out how to change the owner so we can test those changes.
  • [Rich] Ironing out the UX with Converse and Saul. Some things Converse would like, but we currently can’t do. Cannot roll out multi-wallet on V2. Looked into wallet moving flow. Wipe message history on your current device and re-associate, other devices will all get logged out.
  • [Nick] Working out MLS state resolution and new APIs.

April 2, 2024

Agenda

  • Standup
  • For the Rust service: is it going to be on the client side or the server? The answer is likely both. We will support on the client, but offer a service to do those requests on client’s behalf. Both should be able to be implemented with the CredentialVerifier trait.

Standup

  • [Andrew] Just finished the scaffolding/trait PR. Reviewing the SCW PR. Was reviewing the smart contract PR. Working on issue 599 next.
  • [Tong] Smart Wallet PR is up. Responding to PR feedback to use 1271 interface. Next up is integration tests for key rotation.
  • [Rich]
  • [Nick] Working through backend design for XID, and how it interacts with the client. Toy implementation

April 4, 2024

Agenda

  • Standup
  • Questions around smart wallet or EOA
    • Are we always sure a signer is going to have an address? Yes
    • The only good way for checking if it’s a smart contract wallet or an EOA is checking the code size.
    • Does the app developer always know if they’re dealing with a smart wallet or a regular wallet?
  • Open questions for Multi-Wallet XIP
  • Review Universal Identity KR tasks

Standup

  • [Andrew] Working on the Smart Wallet or EOA interface
  • [Tong] Finished the integration tests, except for the part about the block tolerance. Will follow-up with some questions
  • [Rich] Working on the protos and the XIP
  • [Nick] Working on toy implementation of the IdentityUpdate validation work.

April 9, 2024

Agenda

  • Review the tracking issue
  • Standup
  • Priorities between the two tracking issues

Standup

  • [Rich] Final touches on the XIP. Protos are merged. The XIP can likely be published today, then working on the identity backend.
  • [Tong] Working on the signature verification issue.
  • [Andrew] Reviewed all the PRs and the Notion doc. Getting the SCW vs EOA interface merged
  • [Nick] Working on updates to the batch

April 11, 2024

Agenda

  • Standup
  • What belongs in xmtp_id and what belongs in xmtp_mls
    • Credential should live in xmtp_id
    • "If it talks to the nodes or it talks to the database, it belongs in xmtp_mls. All the stateless stuff belongs in xmtp_id. We may need a third crate that holds all the constants.

Standup

  • [Tong] Continued working on key recovery. Need to figure out installation key recovery, and connect the dots on Legacy Keys
  • [Rich] Landed some stubs for the identity backend. Working on the database schema. First step, write the identity updates to the DB without validation.
  • [Nick] Checked off a bunch of small items (API Client, Database Schema)
  • [Andrew] Association state API for the Validation Service. PRs should be going up soon

April 16, 2024

Agenda

  • Review the tracking issue
  • Standup
  • Discuss how MLS Validation service will work with the backend

Standup

  • [Nick] Working on MLS commit validation, which involves plumbing together a bunch of different pieces
  • [Tong] Breaking down the signature verification work into smaller PRs.
  • [Rich] Landed the database schema and algorithm. Implementing the DB operations.
  • [Andrew] Working on MLS validation service. Got some PR feedback

April 18, 2024

Agenda

  • Standup
  • Next week’s demo

Standup

  • [Tong] Almost finished the set of signers. Will put up a draft PR to review some of the interface changes
  • [Andrew] Hopefully the MLS API PR will get merged in today.
  • [Rich] Implemented the publish endpoint. Stubbed out the validation for now. Written fetching the identity log.
  • [Nick] Working on a bunch of utility methods for building Association State

April 23, 2024

Agenda

  • Standup
  • Demo TODO items
    • Create inbox with a wallet
    • Add a smart wallet
    • Update recovery wallet
    • Remove a wallet
    • Smart wallet with passkey
  • Configuring RPC URLs
    • We will need to add a client creation argument for the RPC URL provider, so that apps can configure what node provider our SDK verifies signatures against. As a “should have” we can have an API that does the signature verification for devs on our Alchemy account.

Standup

  • [Nick] Working on removing blockers to demoing creating identities. Will hand off some of the outstanding backend work to Rich.
  • [Andrew] Working out how we’re going to interact with the existing identity stuff in xmtp_mls
  • [Tong] Signature verification PR is up. Working on putting some validation logic inside recoverSigner

April 25, 2024

Agenda

  • Standup
  • Demo check-in. What can we do to make the demo “more real”
  • Integration with xmtp_mls

Standup

  • [Andrew]
  • [Tong] wrapped up signature verification - out Wed - reviewed PRs. Would like to take #674, #675. (create / validate credentials with inbox_id)
  • [Nick]