Memos Format Standard

[jonathanlei]

Purpose and Scope

The purpose of this standard is to define a format for the memo field in XRP Ledger transactions. The memo field can be used for various applications, including but not limited to adding on-chain analytics information for a transaction. This standard is intended to be used by client libraries and user agents across various applications.

This document covers the general format for memos and includes a specific subsection for the fundWallet function in client libraries for Testnet transactions.

Data Structure and Format

The memo field should be an object with the following properties:

• data: An optional string that represents the data.
• type: An optional string that represents the type of data.
• format: An optional string that represents the format of the data.

The type and format fields should follow existing standards for user agent identification. The type field should specify the type of data, and the format field should specify the format of the data.

The format field should follow the format of standard MIME types. MIME types are used to specify the format of files sent over the Internet, such as images, videos, and audio files. The format of a MIME type is as follows:

type/subtype

The type field indicates the general category of the data, such as text, image, or audio. The subtype field indicates the specific format of the data within the category.

Example

{
  "data": "Some data",
  "type": "Application Name/Version Number",
  "format": "text/plain"
}

Validation Rules

To ensure that the memo field is consistent with the standard and can be read by compatible software, the following validation rules should be followed:

• The data, type, and format fields should be strings.
• The data field is optional.
• The type field is optional.
• The format field is optional.
• If the format field is present, it should follow the format of standard MIME types.

Best Practices

To ensure that the memo field is easy to read and consistent across different user agents, the following best practices are recommended:

• Use standard formats for the type and format fields.
• Use a concise and descriptive type field.
• Use a standard format for the format field, such as MIME types.
• Use the data field only when necessary.

fundWallet Function (Testnet)

For the fundWallet function used in Testnet transactions across all client libraries, the memo field is used to add on-chain analytics information for a transaction. This tracking is only done for Testnet transactions and is not applicable to Mainnet usage.

In order to protect user privacy and security, client details (such as name and version number) should not be included in the memo field. Rather, client analytics can be collected during the connection process and do not need to be included in the memo field.

References

• MIME Types
• Content Types
• Memo Format on xrpl.org
• User Agent Format

[WietseWind]

The data, type, and format fields should be strings.

I don't think this is a correct rule to follow / assumption: data can be anything, in case of the mentioned examples like images, data isn't string, it's blob / binary.

image/jpeg: JPEG image file.
image/png: PNG image file.
audio/mpeg: MP3 audio file.
video/mp4: MP4 video file.

I propose to remove these examples from the opening post in this discussion, it will without a doubt land us in episode 143 of the "I'll put my files on ledger in chunks" discussion. While sane people know this is a bad idea, attempts are being made every now and then. These examples might come across as endorsement.

Format should follow mime:

✅ Agree

Final note worth mentioning: "application/version" could be a bad idea to use as an example, as including app name and version in Memos could give away extra attack/scam surface: it could help to provide an easy to use attack vector when a user is already identified by r-address.

[jonathanlei]

I think what I meant was that the MemoData field has to be a string -
from xrpl.org documentation:
MemoData | String | Blob | Arbitrary hex value, conventionally containing the content of the memo.

[justinr1234]

@WietseWind i don’t follow you attack example. Can you elaborate?

[WietseWind]

1. You know how to reach rABCDwhatever123 (account address) per mail / text / ...
2. You know their application based on the memo (if you know the r-address you can see the tx history)
3. You can craft a phising mail in the branding of wallet app from point 2
4. It's extra convincing because that is indeed the client the user is using

[crtag]

I agree that standardisation should be brought into memos, and, please, not only for that particular transaction type. Although, nothing prevents anyone to create a transaction blob with something they deem to be useful. Libraries should enforce and popularise the practice.

MemoFormat preferably is just the MIME type as per the existing standard. Hence MemoData is whatever it is with respect to the indicated format. In the above scenario, I'm not sure why the client details have to make into the memo. Chain analytics on clients/versions might be collected during the connection and don't need to live on the chain imho.
MemoType type is something that I always read that is more of a descriptor nature to the memo object. In this particular example of a funding transaction, it can be just an empty.