You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: XLS-0006-visual-account-icons/README.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,9 +9,9 @@
9
9
created: 2019-09-22
10
10
</pre>
11
11
12
-
Following from [XLS-5d](https://github.com/XRPLF/XLS-0005-standards-for-addressing), it has become necessary to provide XRPL users a way to identify their XRPL account, which effectively now has two different identifiers: an 'r-address' and an 'X-address'.
12
+
Following from [XLS-5](https://github.com/XRPLF/XLS-0005-standards-for-addressing), it has become necessary to provide XRPL users a way to identify their XRPL account, which effectively now has two different identifiers: an 'r-address' and an 'X-address'.
13
13
14
-
To solve this problem XLS-6d provides for a standard way to visually identify accounts irrespective of which addressing system is used by the rest of the user interface.
14
+
To solve this problem XLS-6 provides for a standard way to visually identify accounts irrespective of which addressing system is used by the rest of the user interface.
15
15
16
16
For a user account take the X-address of the account without destination tag and feed it into hashicon https://www.npmjs.com/package/hashicon
Copy file name to clipboardExpand all lines: XLS-0016-nft-metadata/README.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,7 +8,7 @@
8
8
category: Ecosystem
9
9
</pre>
10
10
11
-
In addition to @WietseWind 's [XLS-14d](https://github.com/XRPLF/XRPL-Standards/discussions/30) and @RichardAH 's proposal [XLS-15d](https://github.com/XRPLF/XRPL-Standards/discussions/34) here is a proposal to create a standard for the creation of metadata for the tokens created with a CTI in the currency code.
11
+
In addition to @WietseWind 's [XLS-14](https://github.com/XRPLF/XRPL-Standards/discussions/30) and @RichardAH 's proposal [XLS-15](../XLS-0015-concise-tx-id/README.md) here is a proposal to create a standard for the creation of metadata for the tokens created with a CTI in the currency code.
12
12
13
13
When issuing an indivisible token on the XRPL the only data given is the currency code. For optimal usage, there has to be more metadata for an NFT. For example a description and a URI to an IPFS file.
14
14
Using the Concise Transaction Identifier, a prior transaction can be used to mark the metadata contained in the memo's field for the use of the NFT.
@@ -41,7 +41,7 @@ For the metadata, there has to be created a transaction from the same address as
Copy file name to clipboardExpand all lines: XLS-0021-asset-code-prefixes/README.md
+9-9Lines changed: 9 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -19,15 +19,15 @@ Various other formats have been proposed and even implemented, but until now the
19
19
20
20
A table of asset code prefixes would be added to xrpl.org and maintained by the XRPL.org contributors. A starting point for the table might be something like this:
Copy file name to clipboardExpand all lines: XLS-0024-nft-metadata/README.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -17,7 +17,7 @@ The data which represents the underlying asset/rights are often described and th
17
17
18
18
## Motivation
19
19
20
-
With the release of the [XLS-20d](https://github.com/XRPLF/XRPL-Standards/discussions/46) NFT dev network, there has been significant development of applications utilizing the proposed XLS-20d standard. The areas of interest utilizing NFTs are vast and thus requires a scalable standard for the representation of metadata to facilitate NFToken interoperability amongst applications.
20
+
With the release of the [XLS-20](../XLS-0020-non-fungible-tokens/README.md) NFT dev network, there has been significant development of applications utilizing the proposed XLS-20 standard. The areas of interest utilizing NFTs are vast and thus requires a scalable standard for the representation of metadata to facilitate NFToken interoperability amongst applications.
21
21
22
22
## Advantages
23
23
@@ -335,7 +335,7 @@ Example 2 shows a valid art.v0 metadata file which includes all of the supported
335
335
}
336
336
```
337
337
338
-
Example 3 shows a valid art.v0 metadata file which includes all of the supported fields as well as additional properties that an issuer might need for their application. Although XLS-24d enables you to add as much additional information as you'd like, it is up to the marketplace/viewing application to determine if they will handle and display that information.
338
+
Example 3 shows a valid art.v0 metadata file which includes all of the supported fields as well as additional properties that an issuer might need for their application. Although XLS-24 enables you to add as much additional information as you'd like, it is up to the marketplace/viewing application to determine if they will handle and display that information.
Copy file name to clipboardExpand all lines: XLS-0032-tx-request-uri/README.md
+15-15Lines changed: 15 additions & 15 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -29,7 +29,7 @@ XRPL Labs, by way of the XUMM app, relies upon QR codes for main interactions be
29
29
30
30
### 1.2 Problem/Solution
31
31
32
-
Limitations to this payload structure include passing simple parameters such as account address, destination tag, or messages. A thoughtful and defined XRPL URI standard could give direction to new developers and could provide more interoperability between applications. See [XLS-2d](https://github.com/XRPLF/XRPL-Standards/discussions/27) for the beginning discussions around a URI standard for combining account addresses and destination tags, represented by query parameter “dt”.
32
+
Limitations to this payload structure include passing simple parameters such as account address, destination tag, or messages. A thoughtful and defined XRPL URI standard could give direction to new developers and could provide more interoperability between applications. See [XLS-2](../XLS-0002-destination-information/README.md) for the beginning discussions around a URI standard for combining account addresses and destination tags, represented by query parameter “dt”.
33
33
34
34
### 1.3 Motivation
35
35
@@ -173,7 +173,7 @@ The `type` field is required. This is how we determine what type of XRPL data is
173
173
174
174
### 2.6.1 Account Type
175
175
176
-
This type is intended for passing a single XRPL address and tag. Currently, you can achieve this same functionality by the use of XLS 2d. This standard will supersede XLS 2d.
176
+
This type is intended for passing a single XRPL address and tag. Currently, you can achieve this same functionality by the use of XLS 2. This standard will supersede XLS 2.
177
177
178
178
The address parameter is required for this data type. The tag parameter is optional.
179
179
@@ -271,7 +271,7 @@ Considering the size limitations, we have chosen to split the URI into data type
271
271
272
272
# 4. Backward Compatibility
273
273
274
-
Adopting previous standards and schemas, if the data type field is not provided, the schema will fall back to XLS 2d. The schema is written as follows:
274
+
Adopting previous standards and schemas, if the data type field is not provided, the schema will fall back to XLS 2. The schema is written as follows:
Copy file name to clipboardExpand all lines: XLS-0040-decentralized-identity/README.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -151,7 +151,7 @@ The components specific to the XRPL network are the following:
151
151
A DID that uses this method MUST begin with the following prefix: `did:xrpl`. Per the DID specification, this string MUST be in lowercase. The remainder of the DID, after the prefix, is specified below.
152
152
153
153
-`method-specific-idstring` is formed by `network-id` and `xrpl-specific-idstring`
154
-
-`network-id`: `network-id` is a chain ID which is an identifier of XRP ledger networks. It specifies the underlying network instance where the `DID` is stored. Per [XLS-37d specification](https://github.com/XRPLF/rippled/pull/4418), in XRPL Protocol Chains the Network ID should match the chosen peer port.
154
+
-`network-id`: `network-id` is a chain ID which is an identifier of XRP ledger networks. It specifies the underlying network instance where the `DID` is stored. Per [XLS-37 specification](../XLS-0037-concise-transaction-identifier-ctid/README.md), in XRPL Protocol Chains the Network ID should match the chosen peer port.
155
155
156
156
-`xrpl-specific-idstring` is generated as described in the next section.
0 commit comments