Endpoint: 'resolveDid'

[jac18281828]

Endpoint Documentation: resolveDid

Overview

The resolveDid endpoint is designed to receive an Ethereum public key and return did document in a JSON format. This endpoint is part of our decentralized data service, which provides access to decentralized identity.

Endpoint

POST /api/v1/resolveDid

Request Format

The request should be a JSON object containing one field: publicKey.

• publicKey (string, required): The Ethereum public key (starting with '0x').

Example Request:

{
  "publicKey": "0x123abc..."
}

Response Format

The response will be a JSON object containing a did document for related to the provided Ethereum public key.

Example Response:

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "controller": "did:ethr:0x6CEb0bF1f28ca4165d5C0A04f61DC733987eD6ad",
  "id": "did:ethr:0x6CEb0bF1f28ca4165d5C0A04f61DC733987eD6ad",
  "service": [
    {
      "id": "did:ethr:0x6CEb0bF1f28ca4165d5C0A04f61DC733987eD6ad",
      "recipientKeys": "0x6CEb0bF1f28ca4165d5C0A04f61DC733987eD6ad",
      "serviceEndpoint": "https://xmtp.com/resolver",
      "type": "MessagingService"
    }
  ],
  "verificationMethod": [
    {
      "controller": "did:ethr:0x6CEb0bF1f28ca4165d5C0A04f61DC733987eD6ad",
      "id": "did:ethr:0x6CEb0bF1f28ca4165d5C0A04f61DC733987eD6ad",
      "publicKeyMultibase": "0x6CEb0bF1f28ca4165d5C0A04f61DC733987eD6ad",
      "type": "Ed25519VerificationKey2020"
    }
  ]

Error Handling

In case of an error (e.g., invalid public key, server error), the endpoint will return a JSON object with an error field describing the issue.

Example Error Response:

{
  "error": "Invalid public key format"
}

Security and Authentication

• The endpoint is open access.

Future requirements

• Access control
• All requests must be made over HTTPS.
• Rate limiting is applied to prevent abuse.

Support

Please refer to the DID specification: DID

[jac18281828]

👀 @insipx

[jac18281828]

Suggested initial setup:

pub const REQUIRED_CONFIRMATIONS: usize = 2;
// did registry prototype is currently deployed here - this address is stable
pub const DID_ETH_REGISTRY: &str = "0xd1D374DDE031075157fDb64536eF5cC13Ae75000";

[insipx]

So, my thoughts on setting up this modular gateway/server format so far:

It makes sense to use JSONRPC or derivative. It's Already standard on ETH/Optimism/Other Chains, and it's easier to interact without prior protobuf encoding setups (i.e on the cli or with a debugging app somewhere like PostMan)
JSONRPC also has better wasm support, so we wouldn't need anything hacky like for GRPC in libxmtp.

As far as it goes though, I think we need to decide whether we want endpoints to live in each gateway individually, or within one place. We can define endpoints within each gateway and have a separate crate spin up a server with just selected functionality (resolver, inbox, or both) or just have one crate that uses didresolver and postal_service as libraries and defines endpoints in one place and still able to spin both up

I think for now, a super simple server will be totally fine for what we're doing, but as we get going and want to add, maybe, proxies/websockets or whatever else for security / functionality it could get hairy and we'll want to split that code off.

As far as a design for this goes, I will draft up a doc that uses the rust jsonrpsee library and shows how to define these things separating their concerns per gateway if it makes this clearer. It's fairly composable, and we could either have each gateway define methods within their crate or store all the declarations in one crate

Protobuf Pros:

• maps well to typesafe languages out of the box
• already used in libxmtp
• protobuf definitions serve as some form of 'standard' across all SDKs
• supports wide range of streaming/non-streaming methods

Protobuf Cons:

• requires some extra work to use in wasm
• requires strict encoding scheme, more boilerplate to setup simple code examples
• JSON support would be hacky to include for code interacting with eth nodes, would need some layer that translates JSONRPC Json into Protobuf -- something like GSON does not exist for rust afaik

JsonRPC Pros:

• JSONRPC is standard across the blockchain world
• JSONRPC is easily composable and understandable; can be queried from the commandline without extra steps and return expected output (curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "did_resolveIdentity", "params": ["..", ".."] }' http://localhost:9955/). If concerned about transport size, can still use compression/byte encoding libs like msgpack/bincode/gzip/zlib etc.
• JSONRPC is used by L2 node, Eth, etc, so we're already importing it in our prototype/demo examples, and require it for blockchain interaction
• JSONRPC still supports streaming via websockets, for apis which may require that. Subscribing to topics or identity updates are important for some user applications
• JSONRPC is supported well in rust via jsonrpsee
• Better Rust WASM Support in JSONRPC (simple HTTP or WebSockets Requests, jsonrpsee compiles to wasm)
  Cons:
• Complicates backend code, need to conform to JSON
• requires some rewriting in libxmtp
• maybe more bugs b/c JSON changes can be harder to track than protobuf spec

Would be good to get @snormore input too

[snormore]

JSONRPC makes sense to me. I like the idea of organizing xps-gateway with multiple crates for the different modules (resolver, inbox, etc), and think we should probably just expose those via a single server crate like you suggested too.

The resolver spec from the OP in here LGTM too.