# DID Messaging Service

## Use Cases

- did:xxx to did:nft communication
- did:nft to did:xxx communication
- did:nft to did:nft communication

did:xxx always refers to the DID of the controller of the did:nft.

## Requirements

- Easy onboarding without updating did:xxx to add encryption keys and service endpoints
-

## Staged Solution

### Phase 1

Assumptions:
- Centralized Messaging Service acting as an Inbox
- did:nft resolving to an Blockchain Account ID (e.g., Ethereum account) with no service endpoints and no encryption key

Communication types:
- did:xxx to did:xxx communication
- did:xxx to did:nft communication

How to send a message to a did:nft/did:xxx:
- Anyone can send non-encrypted messages to the did:xxx or did:nft
- Message is signed and sent by the did:xxx/did:nft to the recipient Ethereum account or did:xxx/did:nft (if available)
- Message is sent to a static centralized messaging endpoint in case of an Ethereum Account. If it is a DID, the service endpoint will be resolved and used to send the message to. If there is a DID but no service endpoint, the message will be sent to the centralized messaging endpoint.
- If recipient is an Ethereum account, Messaging Service will use any of the outlined options to establish mapping from Ethereum account to DID
**FIXME: why using DIDs for this option at all?**
- Messaging Service keeps messages until they are pulled from the owner of the NFT

How to obtain messages:
- Recipient goes to Messaging Service and connects with their MetaMask
- dApp asks Messaging Service if any messages were received.
- dApp receives challenge from Messaging Service
- dApp asks MetaMask to sign challenge that will act as an authorization token to obtain messages
- dApp receives messages from Messaging service

**FIXME: cannot become DIDComm v1/v2 compliant**
### Phase 2

- When the recipient goes to the Messaging Service, they can provide their email/phone number to receive updates about new messages.

**FIXME: cannot become DIDComm v1/v2 compliant**

### Phase 3

- When the recipient goes to the Messaging Service, they have the option to create a DID and register the mapping between Eth account and DID.
- The mapping is useful for did:nft and did:xxx recipients.
- In that manner, the public encryption key will be also registered to allow to receive encrypted messages.
- This approach can become DIDComm compliant if MM decides to accept our PR for support for XChacha20.

### Phase 4

- When the recipient goes to the Messaging Service, they have the option to add their own service endpoint to receive message to their DID.
- In that manner, the Messaging Service would still act as a routing service and will be added to the service section of the DID.

## Open Questions

- How to establish mapping between the Ethereum account of the owner of the NFT and thir did:xxx

- CAIP-10 link (Ceramic)
- Local mapping in the messaging service
- Serto Search
- Custom smart contract on Ethereum, e.g., ERC1056