Wallet Object Types and Resource Addressing

[calvincs]

Proposal

Define an easy way to identify a group of resources associated with an XRP Ledger wallet address; thus, one can quickly determine what the resource pointer group represents. This data will exist in the Domain field via an AccountSet.

Example:

@xnft:
btih:1e3ec2d9d231b7dbe0b0ba2db911cb97eadd40bb
ipfs:Qmct4KDxLbpXTgpKPXYv6enj4yRBCNkxtfAEWP9jFqLtkW
ilp:$ilp.uphold.com/ZQ9a44qFAxLk
http:nft.xrpfs.com

157 of 256 bytes

The first line identifies what this group of resources represents, in this case, an xNFT.

The first line starts with a @ and ending with a new line.

@[name of resource group] : [flags/other instructions / optional] [newline delimited]

The following lines identify the [scheme/proto] : [resource address / instructions] ending with a newline. These will be our resource or instruction pointers for the object. These will define off ledger resources or instructions associated with this object.

In the example above, they represent the NFT data storage locations. These include an IPFS cid, Bittorrent id, ILP address, and a web URL.

The resource/instruction pointers will honor existing scheme names but without // slashes to conserve space.

Examples:

https://    -> http:
ftp://      -> ftp:
ipfs://     -> ipfs:
callto://  -> callto:
mailto://  -> mailto:
payto://   -> pay:

Ideally, the resource/instruction pointers would be ordered by their priority, depending on the resource group requirements, in the case of an NFT, the best source of the object(s) data. Suggestion, not required.

Existing Domain values can be updated easily to follow the new schema or allowed backward compatibility. Where values set with [scheme]:// are still valid entries.

Example:

Domain:

https://www.example.com/.well-known/xrp-ledger.toml

This is equivalent to

Domain:

@xrp-ledger-toml:
http:www.example.com
http:example.com

@xrp-ldeger-toml:

• this is a validator toml file for domain verification, valid paths must be [url]/.well-known/xrp-ledger.toml (https://tools.ietf.org/html/rfc5785) per the spec. Because we know this upfront, we can assume that path is appended to each domain.

http

• always translates to https

Also allow for non-pointer objects, with small data payloads / instructions
Example:

@data:text/plain;base64
VGhlIFN0YW5kYXJkLCBYUlA=

or

@data:data:text/html
%3Ca+href%3D%22https%3A%2F%2Fgithub.com%2FXRPLF%2FXRPL-Standards%22%3EXRPL+Standards%3Ca%2F%3E

All @[Type]s would be pre-defined and agreed on by the foundation to create a set of standards for each @[Type]. This will enable developers to create indexes, search efficiently, and extend the XRP wallet's functionality in a defined way.

Type w/ Instructions for validation

This is an examle of using the ledger to do resolution, in this case, domain name resolution.

At a glance I know what kind of record this is, and have instructions on how to validate it, and where to point to on resolution.

@xdns:example.com
lindex:16492737
validation:918552C4C215193D3FBF76097B9B0281A12594A9E74BD86634303B94A99F85E6
ttl:86400
ipfs:QmZjKMuL5aHyd96HVob6QqhmBBwy19LAzvdr6R7CiR5tPD

• 171 bytes of 256 bytes max
• lindex: ledger index
• validation: hash of the transaction use to do the initial set of @xdns:example.com
• ttl: Time to Live before any caching services should recheck this wallet address for updates.

Motivation

Help identify and index wallet Types and Resources in said wallets that build on the ledger's existing features today.

Limitations

The Domain field is limited to 256 bytes; however, this has not been as limiting as one might expect in my testing.

Example Usage

• https://github.com/calvincs/xrpl-nft-creator/blob/main/index.js#L530
• 0019 XLS-19d (DEPRECATED) Wallet based Proof of Digital Asset Property and Rights (NFT) #40

[mDuo13]

I think we can un-deprecate the WalletLocator field to use for these purposes as well. The WalletLocator was originally intended for use with content-addressable storage (something along the lines of IPFS) to begin with. That's not nearly as much space as Domain gives you, but it lets you leave the domain as just a domain so it can be used for other things too.

EDIT: from a quick test, setting WalletLocator to an arbitrary 256-bit value works, but the WalletSize field of AccountSet appears to be valid but ignored during transaction processing (weeeeird). So without an amendment, we can use WalletLocator but not WalletSize.

[calvincs]

@mDuo13 Awesome! If this was the original intention of the WalletLocator field, then I think this use case fits well there. I will do some testing as well to ensure it works as desired. Also assuming when you say 256 bit you mean 256 bytes? Ill find out during testing :-)

[mDuo13]

Nope, WalletLocator really is only 256 bits. It's intended to hold a SHA-256 or similar value

[nbougalis]

Since there's only a single Domain field, I suggest you consider using the xrp-ledger.toml format and defining sections that contain the specific data. That way, the content that's referenced is expandable.

[calvincs]

I initially had the same thought, but there are some drawbacks to doing this.

• The toml lives outside of the ledger and does not allow for versioning or history of said pointers/data in the toml file. The ledger would have no record of any changes to the toml file if one wanted to see such changes.

• You cannot determine at a glance the Type / Service(s) /pointers for a given wallet without visiting the toml file. As well, a script would need to crawl each wallet's toml configuration for indexing.

• The toml file being hosting is a potential single point of failure, and the domain field doesn't seem to allow for a failover addressing scheme.

• Hooks cannot see into the toml file, as it exists off the ledger, not a part of the wallets account meta. I believe hooks can use this additional meta information to expand its functionality further, as the pointers can instead serve as instructions.

Thoughts?

[calvincs]

An example of using instructions w/ a Type

At a glance I know what kind of record this is, and have instructions on how to validate it, and where to point to on resolution.

@xdns:example.com
lindex:16492737
validation:918552C4C215193D3FBF76097B9B0281A12594A9E74BD86634303B94A99F85E6
ttl:86400
ipfs:QmZjKMuL5aHyd96HVob6QqhmBBwy19LAzvdr6R7CiR5tPD

171 bytes of 256 bytes max

Adding example to above document as well.