JSON RPC sendMessage

[jac18281828]

This discussion is about establishing a new method in the messaging workflow called sendMessage. This method will forward a signed payload to the xps-contract MessageSender.

related to: xmtp/xps-contract#14

Documentation for JSON RPC Endpoint: sendMessage

Overview

The sendMessage method is used to send a message within a specified conversation. It is an external function that is part of a larger system managing communications between users or entities. This method requires two parameters: a unique identifier for the conversation (conversationId) and the message content (payload).

JSON RPC Endpoint Specification

Method Name

sendMessage

Request Parameters

1. conversationId: A unique identifier for the conversation. This is a 32-byte string, typically in hexadecimal format.
2. payload: The content of the message. This is a variable-length byte array that can hold any form of data, such as text, images, or other binary formats.
3. sigV: The signature V
4. sigR: The signature R
5. sigS: The signature S

Request Format

{
  "jsonrpc": "2.0",
  "method": "sendMessage",
  "params": {
    "conversationId": "<conversationId>",
    "payload": "<payload>",
     "V": "<V>",
     "R": "<R>",
     "S": "<S>"
  },
  "id": 1
}

• jsonrpc: Specifies the version of the JSON RPC protocol being used. Always "2.0".
• method: The name of the method being called. Here it is "sendMessage".
• params: A structured value holding the parameters necessary for the method. It contains:
  • conversationId: The unique identifier for the conversation.
  • payload: The message content in bytes.
  • V: The signature V
  • R: The signature R
  • S: The signature S
• id: A unique identifier established by the client that must be number or string. Used for correlating the response with the request.

Response Format

The response will typically include the result of the operation or an error if the operation was unsuccessful.

Success Response

{
  "jsonrpc": "2.0",
  "result": "status",
  "tx": "<tx receipt>",
  "id": 1
}

• result: Contains data related to the success of the operation. The nature of this data can vary based on the implementation.

Error Response

{
  "jsonrpc": "2.0",
  "error": {
    "code": <error_code>,
    "message": "<error_message>"
  },
  "id": 1
}

• error: An object containing details about the error.
  • code: A numeric error code.
  • message: A human-readable string describing the error.

Example Usage

Request

{
  "jsonrpc": "2.0",
  "method": "sendMessage",
  "params": {
    "conversationId": "0x1234abcd...",
    "payload": "SGVsbG8sIHdvcmxkIQ==",
    "V": "####",
    "R": "#####",
    "S": "#####"
  },
  "id": 42
}

Response

{
  "jsonrpc": "2.0",
  "result": "Message sent successfully",
  "tx": "<tx receipt>",
  "id": 42
}

Notes

• Ensure that the conversationId is valid and exists in the system.
• The payload should be properly encoded (e.g., base64) if it contains binary data.
• The method must be called by an authorized entity, adhering to any authentication and authorization mechanisms in place.
• The system should have proper error handling to deal with invalid requests, unauthorized access, and other potential issues.
• Revert should be returned to caller as an error status

[jac18281828]

xmtp/xps-contract#14

[jac18281828]

xmtp/xps-contract#15

[insipx]

small nit: I believe in xmtp-mls, we are moving to groupId rather than conversationId, so I think we should stick with that terminology for consistency

[jac18281828]

small nit: I believe in xmtp-mls, we are moving to groupId rather than conversationId, so I think we should stick with that terminology for consistency
This might be a useful distinction however because this value should be the sha3 hash of the groupId you are mentioning

[insipx]

Ah I didn't realize, that makes sense then

[jac18281828]

Working example here: https://github.com/xmtp/xps-conversation-producer