Question regarding Stellar Attachment Convention 'route' param and general clarification

Question

Regarding the attachment convention, is my interpretation correct?

• Attachments are sent outside of the ledger. The sha256 hash of the attachment data is included in the transaction's memo field only for the receiver to verify the integrity of the actual attachment data received through other means?

Attachments
Sometimes there is a need to send more information about a transaction than fits in the provided memo field, for example: KYC info, an invoice, a short note. Such data shouldn’t be placed in the ledger because of it’s size or private nature. Instead, you should create what we call an Attachment. A Stellar attachment is simply a JSON document. The sha256 hash of this attachment is included as a memo hash in the transaction. The actual attachment document can be sent to the receiver through some other channel, most likely through the receiver’s Auth server.

Attachment structure
Attachments have a flexible structure. They can include the following fields but these are optional and there can be extra information attached.

A few follow ups..

I noticed 'route' parameters defined in the attachment structure for the transaction and operations.. How does the Stellar network (federation server?) use that info? (ie, is that an automatic behavior, or up to a custom implementation?)

Are there limits to the size / fields allowed in the 'sender_info' object? KYC data is used in the example, but am I correct to assume that could really be anything?

Answer 1

Attachments are sent outside of the ledger using Compliance Protocol. The sha-256 hash of the attachment is part of a transaction to identify a previously sent attachment when a transaction is received.

route parameter contains the actual memo value returned by Federation server. Normally (for transactions that do not use Compliance Protocol) the memo returned by Federation server is used in transaction's memo field in the ledger. However, because we need to send sha-256 hash of the attachment in the memo we need another place to store the memo/route returned by Federation.

There are currently no limitations on the size/fields allowed in sender_info object. Go SDK contains SenderInfo struct that contains standard fields that so far have been working fine for partners. This can eventually become a new SEP but it's too early to tell.

The detailed flow can be found in Compliance Protocol doc.