Contact Operations – Registry

[jac18281828]

The Contact Directory operates on the premise that an Ethereum public key (EPK) can effectively act as a proxy for a decentralized identity registered under the did:eth registry protocol. This registry offers a decentralized means to link a key bundle with an EPK, forming a unique contact ID. It's important to note that, with the long-term goals of XMTP in mind, the aim is to facilitate contact workflows that do not necessarily rely on Ethereum. In such scenarios, the on-chain registry must incorporate a mapping to accommodate a broader decentralized identity (DID) framework.

A decentralized identity allows a user to validate their own registration request using a robust cryptographic signature. This can typically be done with a blockchain wallet. This on-chain registration can serve to mitigate spam while providing a robust and censorship resistant identity record.

sequenceDiagram
    Client 1 --x Client 1: Creates Installation Key
    Client 1 --X Wallet: Signs Installation Key
    Client 1 -->> Registry: setAttribute(did:xmtp:contact, contact bundle)
    Registry -->> Ethereum Log: DIDAttributeChanged
    Client 2 -->> Ethereum Log: search for Client 1 DIDAttributeChanged
    Note right of Registry: Contact bundle is stored in Ethereum log based on Change event

Loading

Contact Registry Workflow

1. The client creates a registration message that includes the user's contact details and credentials, like cryptographic keys.
2. This registration message is sent to the wallet provider for off-chain signature verification.
3. Once signed, the registration details are sent to the XMTP identity gateway.
4. The identity gateway groups multiple registration requests and sends them to L1 (Layer 1). At this point, the identity gateway covers the transaction costs.
5. The L1 Confirmation contract checks the validity of the signature from step 2.
6. If the signature is verified, the user's credentials are issued and added to the did:eth registry.

As part of developing this workflow. We are working on a prototype or POC of XMTP integration with did:eth. The following operations directly support implementation of a Contact Directory.

Installation Management

grantInstallation(wallet, keyBundle, metadata)

Declares that an installation is associated with a wallet. Currently, we do this by signing the installation’s keys using the wallet’s keys.
In v3, an installation has two keys, a Curve25519 + Ed25519 key. In MLS, the keys may be different, but the overall concept is the same.
One day we might consider adding an expiry date for the grant, before which it must be renewed.

Pseudo Implementation

function saveAttribute(web3, name, value, validity) {
     signature_message = ['setAttribute', name, value, validity]
     owner_nonce = web3.call('nonce()')
     digest_payload = [ 0x19, 0, registry_address, owner_nonce, public_key, signature_message ]
     digest = keccak256(digest_payload)
     (sigV, sigR, sigS) = wallet.sign(digest)
     didReg = web3.contract(registry_address)
     didReg.send('setAttributeSigned', [public_key, sigV, sigR, sigS, name, value, validity])
}

function  saveInstallation() {
     web3 = new JsonRpc(RPC_URL, Network)
     install_key = generate_install_key()
     did = `did:xmtp:${did_id}`
     saveAttribute(web3,  'did:xmtp:v3:installkey', install_key)
     saveAttribute(web3, 'did:xmtp:v3:did, did)
 }

Required Configuration

Network := MAINNET | TESTNET
RPC_URL =  Ethereum node url
REGISTRY_ADDRESS

revokeInstallation(wallet, installationId)

Declares that an installation is no longer associated with a wallet (e.g. if it is compromised, or no longer used). Currently, we would do this by signing a revocation payload containing the installation’s keys using the wallet’s keys.

Pseudo Implementation

function  revokeAttribute(web3, name, value, validity) {
     signature_message = ['revokeAttribute', name, value, validity]
     owner_nonce = web3.call('nonce()')
     digest_payload = [ 0x19, 0, registry_address, owner_nonce, public_key, signature_message ]
     digest = keccak256(digest_payload)
     (sigV, sigR, sigS) = wallet.sign(digest)
     didReg = web3.contract(registry_address)
     didReg.send('revokeAttributeSigned', [public_key, sigV, sigR, sigS, name, value, validity])
}

function revokeInstallation() {
   web3 = new JsonRpc(RPC_URL, Network)
   install_key = retrieve_install_key()
   revokeAttribute(web3,  'did:xmtp:v3:installkey', install_key)
}

Required Configuration

Network := MAINNET | TESTNET
RPC_URL =  Ethereum node url
REGISTRY_ADDRESS

Installation Search

getAllInstallations(wallet)

Fetch all valid installations for a given wallet. Basically, fetch all granted installations, and subtract revoked installations. This could be done manually by the client, or pre-computed by a trusted entity such as a smart contract before surfacing to the client.
A client would do this step before communicating with a wallet address.
A client might also enumerate its own installations for account management - in this case they would want to fetch the metadata too.

Pseudo Implementation

Iterate change history, checking revocation and expiration, saving a list of all prior changes

const history = []
let prevChange = (await DidReg.changed(identityAddress)).toNumber()
while (prevChange) {
  const logs = await ethers.provider.getLogs({
    topics: [null, `0x000000000000000000000000${identityAddress}`],
    fromBlock: prevChange,
    toBlock: prevChange,
  })
  prevChange = 0
  for (const log of logs) {
    const logDescription = DidReg.interface.parseLog(log)
    history.unshift(logDescription)
    prevChange = logDescription.args.previousChange.toNumber()
  }
}

Required Configuration

Network := MAINNET | TESTNET
RPC_URL =  Ethereum node url
REGISTRY_ADDRESS

Supporting Contract Operations

The did-eth registry supports a basic operational model for storage and retrieval of a contact key bundle. All API operations must be implemented on top of the following model operations

identityOwner

retrieve delegated owner id

validDelegate

confirm current identity is a valid delegate of identity specified

changeOwner

assign ownership of current identity to specified address

addDelegate

delegate control of identity to address for the specified time range

revokeDelegate

remove a previously associated delegate from identity

setAttribute

Assign name and value for attribute, aka key bundle, on identity

revokeAttribute

Remove the previous assignment for a name and value on identity

Issues

In the current contract specification, setAttribute does not store any data on-chain. This is a cost optimization. The burden will fall on the client to search for and retrieve the indexed data from Ethereum event logs. My intention is to propose and implement a storage solution for this problem that will take possibly both of the following approaches.

1. Store critical profile data on chain in a mapping [github issue]
2. Validate additional data using a Merkle Tree and Proof [Requires ticket]

[jac18281828]

👀 @snormore @insipx

[jac18281828]

👀 @richardhuaaa

[jac18281828]

Attribute names are limited to 32 bytes. This will impose a barrier on id generation as well as registry namespace.

[insipx]

if this is the name of the attribute, did:xmtp:v3:installkey -- just want to clarify where we generate the ID from

[jac18281828]

did generation is a broader topic which we can discuss offline. A good strategy would be to start with a random number and then check the registry if that number is taken.

[jac18281828]

While there is no named limit to the size of the contact bundle stored in the registry, there is a practical limit of a few kb.

[jac18281828]

Long term the combination of saving the did and install key bundle might make more sense if it was part of an XMTP specific contract that uses the did registry as a form of perpetual storage. The following sequence would be reduced to a single transaction.

     saveAttribute(web3,  'did:xmtp:v3:installkey', install_key)
     saveAttribute(web3, 'did:xmtp:v3:did, did)

This is intended for POC purposes so the UX might not be as ideal as is required for a production release.

[insipx]

Just thinking aloud here,

I'm a little bit concerned about the indexing strategy for these event logs -- what's an example of critical profile data that would be stored onchain/query-able from the contract?

Once we have that, I assume we then expect inbox providers to each run this indexing service separately -- or would we provide the service for people to query? Or would we maybe use something like TheGraph or another pre-existing indexing service for the event logs

Using merkle trees -- we keep the root of the event logs w/ attributes somewhere, but we still need to keep some logs around to send back w/ the proof. In general I really like this idea since it significantly reduces storage cost associated with indexing ETH, but re-indexing from the start would still require looking through all the historical blocks on ETH right?

[jac18281828]

Sure, we should chat offline as this is more pertinent to our eventual, production, solution rather than a prototype or proof of concept. As you mention Ethereum does not provide a data storage solution, it only provides an approach to data availability. There are several strategies that we can employ to achieve both but that is not part of the current work.

TLDR; This discussion represents an effort to put together a POC XMTP client with an Ethereum contact directory. The scope is intentionally limited to build a working model.

[37ng]

@jac18281828 wdym by Ethereum does not provide a data storage solution? Can't we store the data in a smart contract?

[jac18281828]

Data can be stored on chain but it not usually practical due to the extreme cost. Ethereum is better used as a data verification or data availability layer than a data store

[37ng]

Using Ethereum logs is cheaper but it is not worth the complexity(indexer), also I think using Ethereum as DA is for L2s since they can only store merkle roots on L1 while using calldata as DA.
In our case, can we deploy a registry SC on an L2 and use it?

[jac18281828]

I'll setup a call with you on Tuesday so we can go over your questions.

[trebor-yatska]

Just want to get some clarity on the below statement.

with the long-term goals of XMTP in mind, the aim is to facilitate contact workflows that do not necessarily rely on Ethereum

Does this mean we should not expect to tether the workflow to Ethereum signature schemes indefinitely? Or, that parts, or all of, the contact bundle could eventually live outside of Ethereum? I suppose it could be both?

There is a small typo in "did:eth" in the below sentence

As part of developing this workflow. We are working on a prototype or POC of XMTP integration with did:eh

Why would a user want to predefine an expiration date for the grant?

One day we might consider adding an expiry date for the grant, before which it must be renewed.

What is the difference between grantInstallation() and saveInstallation()?

[jac18281828]

Just want to get some clarity on the below statement.

with the long-term goals of XMTP in mind, the aim is to facilitate contact workflows that do not necessarily rely on Ethereum

This is a statement of intent. First, to indicate that the eventual did mapping that we implement should be flexible enough to live in external storage with a variety of possible paths to resolution. Second, to indicate that we should not 'rest on our laurels' with a functional Ethereum implementation. We need to push past Ethereum to include additional possible layers and solutions.

Having said this, as prototyping work, we will depend strongly on Ethereum as our DA.

Does this mean we should not expect to tether the workflow to Ethereum signature schemes indefinitely? Or, that parts, or all of, the contact bundle could eventually live outside of Ethereum? I suppose it could be both?

Choice of signature scheme is going to be determined by the implementation of meta transactions. Putting something on Ethereum will require an Ethereum signature. That is not a choice. However, in the future, there may be additional paths to resolving the contact credential that does not involve Ethereum.

There is a small typo in "did:eth" in the below sentence

As part of developing this workflow. We are working on a prototype or POC of XMTP integration with did:eh

Why would a user want to predefine an expiration date for the grant?

Because the installation bundle contains a public key. That key should have a fixed lifetime for security reasons and we should impose a requirement to rotate the keys at sufficient intervals to guarantee the safety of the users profile.

One day we might consider adding an expiry date for the grant, before which it must be renewed.

What is the difference between grantInstallation() and saveInstallation()?

The pseudo implementation is not meant to be complete or final. I tried to offer some insight to the potential implementor as to some of the challenges they will face with signing this data to go on chain but there are more details that I left out.

[trebor-yatska]

This is a statement of intent. First, to indicate that the eventual did mapping that we implement should be flexible enough to live in external storage with a variety of possible paths to resolution. Second, to indicate that we should not 'rest on our laurels' with a functional Ethereum implementation. We need to push past Ethereum to include additional possible layers and solutions.

Having said this, as prototyping work, we will depend strongly on Ethereum as our DA

Choice of signature scheme is going to be determined by the implementation of meta transactions. Putting something on Ethereum will require an Ethereum signature. That is not a choice. However, in the future, there may be additional paths to resolving the contact credential that does not involve Ethereum.

Makes sense

Because the installation bundle contains a public key. That key should have a fixed lifetime for security reasons and we should impose a requirement to rotate the keys at sufficient intervals to guarantee the safety of the users profile.

Ok, got it. Lot's of UX considerations here.