Layer 3: Social

The XIO Social Layer considers how a peer to peer messaging could be added to the platform, this could enable 1-1 or Group Chat capability.

1. XIO-based Identity for Messaging (XIOM)

XIOP Creation: Use DID standards (e.g., W3C DID) to create a decentralized identity for each user. This DID would represent the user's identity on the blockchain and in the XIOM network.
- The DID could be managed via a smart contract or a DID registry on the L2 blockchain in our case an EVM L2 chain
- For messaging, you would use a unique Identifier to resolve the public keys associated with the user, allowing encryption and verification of XIOP messages.
Linking DID to EVM Address: The DID must be associated with the user's wallet address or an account on the EVM blockchain, ensuring that the identity used for XIOM is cryptographically linked to the same identity used for blockchain transactions.
- This can be done using off-chain signatures that prove ownership of both the DID and the EVM address.
Storage of DID Documents: The DID document, which holds the metadata such as public keys or service endpoints, can be stored either on-chain (on the L2 blockchain) or off-chain (e.g., via IPFS), with a reference stored on-chain.

2. On-Chain Message Metadata Transport

Message Signing: Each message exchanged via XIOM should be signed by the user's DID private key. This ensures authenticity and can serve as proof that the message originates from the correct user.
- The signed message could include metadata like the timestamp, message hash, and transaction ID if the message involves a blockchain transaction.
Blockchain Transactions for Metadata: For transporting message metadata:
- Store metadata about messages (like message hash, timestamp, DID sender, DID recipient) on the L2 blockchain as part of a minimal transaction.
- Leverage the gas efficiency of the L2 EVM network for recording metadata that allows verifiable on-chain audit trails of the messages exchanged.
- If the XIOM message includes data critical for smart contracts or governance, the on-chain metadata can also include a reference to smart contract events triggered by the message.

3. Message Encryption and Decentralized Key Management

Encryption: Use asymmetric encryption (e.g., ECDSA or EdDSA) where the sender encrypts the message using the recipient’s DID public key. This ensures that only the recipient can decrypt the message, preserving confidentiality.
Decentralized Key Management: Leverage a decentralized key management solution, possibly stored on-chain or linked to the DID document. This allows seamless key rotation or recovery, reducing reliance on centralized services.

4. Integration of L2 EVM and XIOM Messaging

L2 for Scalability: Use an L2 EVM chain (e.g., Optimism, Arbitrum) to handle the message metadata and DID-related transactions. This reduces costs and increases scalability, allowing XIOM messaging at high speed and low gas costs.
Bridging to L1 (Mainnet): If necessary, you can bridge specific DID transactions or message metadata to the Ethereum L1, ensuring interoperability and access to the wider Ethereum ecosystem.

5. Use of Verifiable Credentials

Verifiable Credentials (VCs): The DID holder can issue VCs (e.g., proof of identity, KYC data) to further authenticate messaging interactions or specific transactions. VCs can be verified by smart contracts on the L2 blockchain.

Example Workflow:

User Registration:
- User creates a DID (e.g., did:ethr:0x123) on the L2 EVM blockchain.
- DID is linked to the user's wallet address on L2 (e.g., 0x123).
Message Sending:
- User A sends an encrypted message to User B via XIOM.
- The message is signed by User A’s DID.
- A transaction on the L2 blockchain stores the message metadata (hash, timestamp, sender and recipient DIDs).
Message Verification and Metadata Audit:
- User B receives and decrypts the message.
- User B (or any third party) can verify the message's authenticity by checking the DID signature and consulting the on-chain metadata for verification.

This integration makes messaging secure, decentralized, and verifiable, with blockchain-backed identity management and metadata tracking. The DID workflows ensure that each message is linked to a cryptographically verifiable identity, while the L2 EVM chain ensures scalability and cost-efficiency for on-chain operations

Last updated 2 months ago

On-Chain DID Workflow for Social Messaging and Transactions

1. XIO-based Identity for Messaging (XIOM)

XIOP Creation: Use DID standards (e.g., W3C DID) to create a decentralized identity for each user. This DID would represent the user's identity on the blockchain and in the XIOM network.

The DID could be managed via a smart contract or a DID registry on the L2 blockchain in our case an EVM L2 chain
For messaging, you would use a unique Identifier to resolve the public keys associated with the user, allowing encryption and verification of XIOP messages.

Linking DID to EVM Address: The DID must be associated with the user's wallet address or an account on the EVM blockchain, ensuring that the identity used for XIOM is cryptographically linked to the same identity used for blockchain transactions.

This can be done using off-chain signatures that prove ownership of both the DID and the EVM address.

Storage of DID Documents: The DID document, which holds the metadata such as public keys or service endpoints, can be stored either on-chain (on the L2 blockchain) or off-chain (e.g., via IPFS), with a reference stored on-chain.

2. On-Chain Message Metadata Transport

Message Signing: Each message exchanged via XIOM should be signed by the user's DID private key. This ensures authenticity and can serve as proof that the message originates from the correct user.

The signed message could include metadata like the timestamp, message hash, and transaction ID if the message involves a blockchain transaction.

Blockchain Transactions for Metadata: For transporting message metadata:

Store metadata about messages (like message hash, timestamp, DID sender, DID recipient) on the L2 blockchain as part of a minimal transaction.
Leverage the gas efficiency of the L2 EVM network for recording metadata that allows verifiable on-chain audit trails of the messages exchanged.
If the XIOM message includes data critical for smart contracts or governance, the on-chain metadata can also include a reference to smart contract events triggered by the message.

3. Message Encryption and Decentralized Key Management

Encryption: Use asymmetric encryption (e.g., ECDSA or EdDSA) where the sender encrypts the message using the recipient’s DID public key. This ensures that only the recipient can decrypt the message, preserving confidentiality.

Decentralized Key Management: Leverage a decentralized key management solution, possibly stored on-chain or linked to the DID document. This allows seamless key rotation or recovery, reducing reliance on centralized services.

4. Integration of L2 EVM and XIOM Messaging

L2 for Scalability: Use an L2 EVM chain (e.g., Optimism, Arbitrum) to handle the message metadata and DID-related transactions. This reduces costs and increases scalability, allowing XIOM messaging at high speed and low gas costs.

Bridging to L1 (Mainnet): If necessary, you can bridge specific DID transactions or message metadata to the Ethereum L1, ensuring interoperability and access to the wider Ethereum ecosystem.

5. Use of Verifiable Credentials

Verifiable Credentials (VCs): The DID holder can issue VCs (e.g., proof of identity, KYC data) to further authenticate messaging interactions or specific transactions. VCs can be verified by smart contracts on the L2 blockchain.

Example Workflow:

User Registration:

User creates a DID (e.g., did:ethr:0x123) on the L2 EVM blockchain.
DID is linked to the user's wallet address on L2 (e.g., 0x123).

Message Sending:

User A sends an encrypted message to User B via XIOM.
The message is signed by User A’s DID.
A transaction on the L2 blockchain stores the message metadata (hash, timestamp, sender and recipient DIDs).

Message Verification and Metadata Audit:

User B receives and decrypts the message.
User B (or any third party) can verify the message's authenticity by checking the DID signature and consulting the on-chain metadata for verification.