Connecting MSAs to Additional External Non-Payment Addresses

[wilwade]

Feature Description

Note: The original version of this issue tried to cover both payment and non-payment addresses. After some discussion and work, the issue was split. #3 now handles the payment schema, while this issue is for the non-payment related work.

Details

• Writer: As a user with an MSA, I want to be able to connect my addresses on any chain to my MSA so they can be discovered by others
• User Reader: As a user looking at my connections, I want to know what addresses to use for them on any chain
• App Reader: As a application looking at a user, I want to know what other connected addresses they have on any chain to provide wider experiences to the user.

Options

• Don't do it
  • No: Connecting additional data and structures to MSAs is a core part of Frequency
• Custom MSA Pallet storage
  • No: Frequency does not need to read this information
• Use an existing org.dsnp schema
  • No: Not structured and requires indexing to discover
• Use up coming dsnp verified attributes
  • Both: This is a linking discovery need. It doesn't need verification and needs easy discoverability.
• Use IPFS batched Data
  • No: Would still require indexing, and doesn't provide a signature required setup
• Use Paginated Data
  • Maybe: Requires writing all each time, and these points of data are atomic
• Use Itemized Data
  • Yes: Atomic data points, can require signature, easy to discover

Searched for Related Issues

• I have done a search for related issues and either found none, or noted them

[wilwade]

Outcomes

• Separate schemas for Payment addresses vs Linking/Non-payment addresses
• Payment addresses can have the implied order (higher index = higher priority when more than one with the same chain)

Discussion:

It doesn't tell you priority in any way

• Order in the Itemized schema?
  • Could work, but tools try to minimized this, and may not be consistent
• Add another field
  • Could just be a priority integer with largest wins
  • Limit to one byte
• Remake as paginated
  • Not a great option
• Don't care, perhaps add a payment accepted bit
  • Might also need this?
  • Could then assume priority in last one wins order
• Separate out payment address schema from general linkage schemas
  • aka Schema X are all payment addresses and Schema Y are all linked, non-payment addresses

It doesn't have a signature for verification

Choice: Not worth it for payment addresses at least.

• Optional signature field?
  • Requires a table of how to sign?
  • What would be signed?
• Can we get this out of verified creds instead?

Specific Linkage

• If we want to link a specific chain or identity, should this this be a separate schema or use an optional signature field on the "Non-payment schema"?
• Or do the duplex setup where each side points at the other