Skip to content

Commit 784152c

Browse files
Copilotmvadari
Copilot
and
mvadari
authored
Update XLS preambles: standardize metadata format with requires field, discussion links, proper indentation, and clean author fields (#327)
Co-authored-by: mvadari <8029314+mvadari@users.noreply.github.com> Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: Mayukha Vadari <mvadari@gmail.com> Co-authored-by: Mayukha Vadari <mvadari@ripple.com>
1 parent a7f78e8 commit 784152c

File tree

42 files changed

+627
-538
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

42 files changed

+627
-538
lines changed

‎.github/workflows/deploy.yml‎

Lines changed: 0 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -3,8 +3,6 @@ name: Deploy XLS Standards to GitHub Pages
33
on:
44
push:
55
branches: [master]
6-
pull_request:
7-
branches: [master]
86
workflow_dispatch:
97

108
permissions:

‎.github/workflows/validate-xls.yml‎

Lines changed: 0 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -4,7 +4,6 @@ on:
44
push:
55
branches: [master]
66
pull_request:
7-
branches: [master]
87
workflow_dispatch:
98

109
jobs:

XLS-0002d-destination-information/README.md renamed to XLS-0002-destination-information/README.md

Lines changed: 36 additions & 27 deletions
Original file line numberDiff line numberDiff line change
@@ -1,28 +1,37 @@
1-
# 0002 XLS-2d Standard for XRPL destination information
2-
3-
Currently several apps are using a variety of methods to encode destination information;
4-
5-
- rPEPPER7kfTD9w2To4CQk6UCfuHM9c6GDY?dt=123
6-
- rPEPPER7kfTD9w2To4CQk6UCfuHM9c6GDY:123
7-
- Deprecated Ripple URI syntax: https://ripple.com//send?to=rPEPPER7kfTD9w2To4CQk6UCfuHM9c6GDY&amount=30&dt=123
8-
9-
I feel the best way to implement this, is by allowing Apps to register Deep Links (URI handlers) while keeping the destinations backwards compatible with Web browsers, so users without any app to handle a URI can display a page by the app creator with an instruction.
10-
11-
I propose to allow any URL prefix, with a default set of GET URL params, supporting the existing params proposed in the (deprecated) Ripple URI standard;
12-
13-
so:
14-
15-
{ any URL } ? { params }
16-
17-
Where params may _all_ be optional except for the account address:
18-
19-
- `to` (account address, rXXXX..)
20-
- `dt` (destination tag, uint32)
21-
- `amount` (float, default currency: XRP (1000000 drops))
22-
- ...
23-
24-
So App 1 may use:
25-
https://someapp.com/sendXrp?to=...
26-
27-
... While App 2 uses:
1+
<pre>
2+
xls: 2
3+
title: XRPL destination information
4+
description: A standard for encoding destination information with backwards compatibility for web browsers
5+
author: Wietse Wind <w@xrpl-labs.com>
6+
discussion-from: https://github.com/XRPLF/XRPL-Standards/discussions/27
7+
status: Stagnant
8+
category: Community
9+
created: 2019-02-25
10+
</pre>
11+
12+
Currently several apps are using a variety of methods to encode destination information;
13+
14+
- rPEPPER7kfTD9w2To4CQk6UCfuHM9c6GDY?dt=123
15+
- rPEPPER7kfTD9w2To4CQk6UCfuHM9c6GDY:123
16+
- Deprecated Ripple URI syntax: https://ripple.com//send?to=rPEPPER7kfTD9w2To4CQk6UCfuHM9c6GDY&amount=30&dt=123
17+
18+
I feel the best way to implement this, is by allowing Apps to register Deep Links (URI handlers) while keeping the destinations backwards compatible with Web browsers, so users without any app to handle a URI can display a page by the app creator with an instruction.
19+
20+
I propose to allow any URL prefix, with a default set of GET URL params, supporting the existing params proposed in the (deprecated) Ripple URI standard;
21+
22+
so:
23+
24+
{ any URL } ? { params }
25+
26+
Where params may _all_ be optional except for the account address:
27+
28+
- `to` (account address, rXXXX..)
29+
- `dt` (destination tag, uint32)
30+
- `amount` (float, default currency: XRP (1000000 drops))
31+
- ...
32+
33+
So App 1 may use:
34+
https://someapp.com/sendXrp?to=...
35+
36+
... While App 2 uses:
2837
https://anotherapp.net/deposit-xrp?to=...&dt=1234&amount=10

XLS-0002d-destination-information/xls-2d-reference.js renamed to XLS-0002-destination-information/reference.js

File renamed without changes.

‎XLS-0003-deeplink-signed-transactions/README.md‎

Lines changed: 36 additions & 27 deletions
Original file line numberDiff line numberDiff line change
@@ -1,28 +1,37 @@
1-
# 0003 XLS-3d Standard for (sharing / deeplinking) signed transactions
2-
3-
Currently several apps are using a variety of methods to encode HEX signed transactions (to be submitted air gapped);
4-
5-
- { HEX }
6-
- ripple:signed-transaction:{ HEX }
7-
- ripple://signed/{ HEX }
8-
9-
I feel the best way to implement this, is by allowing Apps to register Deep Links (URI handlers) while keeping the destinations backwards compatible with Web browsers, so users without any app to handle a URI can display a page by the app creator with an instruction.
10-
11-
I propose to allow any URL prefix:
12-
{ any URI with exactly one folder } / { HEX }
13-
14-
So App 1 may use:
15-
https://someapp.com/submitTx/{ HEX }
16-
17-
... While App 2 uses:
18-
https://someapp.com/send-xrpl-tx/{ HEX }
19-
20-
I would propose to limit the amount of slashes before the HEX to a _fixed amount of slashes_ (eg. one folder, as the App 1 and App 2 examples show) so parsers can easily split the URI without having to use regular expressions.
21-
22-
Limitations:
23-
MSIE limits URL parsing to 2,083 chars. Safari 65k chars. Todo: need to test this on modern mobile OS'es.
24-
25-
P.S. Another option (proposal) would be to use a specific syntax (prefix) instead of fixed (one) folder; eg.
26-
`https://xrpl-labs.com/xrpl:signed-transaction:<SIGNEDBLOB>`
27-
1+
<pre>
2+
xls: 3
3+
title: Sharing and deeplinking signed transactions
4+
description: A standard for encoding HEX signed transactions for air-gapped submissions with deep link support
5+
author: Wietse Wind <w@xrpl-labs.com>
6+
discussion-from: https://github.com/XRPLF/XRPL-Standards/discussions/26
7+
status: Stagnant
8+
category: Community
9+
created: 2019-02-25
10+
</pre>
11+
12+
Currently several apps are using a variety of methods to encode HEX signed transactions (to be submitted air gapped);
13+
14+
- { HEX }
15+
- ripple:signed-transaction:{ HEX }
16+
- ripple://signed/{ HEX }
17+
18+
I feel the best way to implement this, is by allowing Apps to register Deep Links (URI handlers) while keeping the destinations backwards compatible with Web browsers, so users without any app to handle a URI can display a page by the app creator with an instruction.
19+
20+
I propose to allow any URL prefix:
21+
{ any URI with exactly one folder } / { HEX }
22+
23+
So App 1 may use:
24+
https://someapp.com/submitTx/{ HEX }
25+
26+
... While App 2 uses:
27+
https://someapp.com/send-xrpl-tx/{ HEX }
28+
29+
I would propose to limit the amount of slashes before the HEX to a _fixed amount of slashes_ (eg. one folder, as the App 1 and App 2 examples show) so parsers can easily split the URI without having to use regular expressions.
30+
31+
Limitations:
32+
MSIE limits URL parsing to 2,083 chars. Safari 65k chars. Todo: need to test this on modern mobile OS'es.
33+
34+
P.S. Another option (proposal) would be to use a specific syntax (prefix) instead of fixed (one) folder; eg.
35+
`https://xrpl-labs.com/xrpl:signed-transaction:<SIGNEDBLOB>`
36+
2837
... Where the fixed prefix in this case is `xrpl:signed-transaction:`.

XLS-0004d-trustline-uri/README.md renamed to XLS-0004-trustline-uri/README.md

Lines changed: 26 additions & 17 deletions
Original file line numberDiff line numberDiff line change
@@ -1,19 +1,28 @@
1-
# 0004 XLS-4d Standard URI instructing a wallet to add a trustline
1+
<pre>
2+
xls: 4
3+
title: Trustline Add URI
4+
description: A URI standard for instructing wallets to add trustlines following the design of XLS-2d
5+
author: Richard Holland (@RichardAH)
6+
discussion-from: https://github.com/XRPLF/XRPL-Standards/discussions/25
7+
status: Stagnant
8+
category: Community
9+
created: 2019-03-06
10+
</pre>
11+
12+
I suggest we follow on closely from the design of XLS-2d
13+
14+
Query parameters:
15+
`action=trustline`
16+
`limit=<integer>`
17+
`currency=<issuer address>:<currency code>`
18+
`rippling=true|false (optional, default = false)`
19+
20+
I.e.
21+
22+
`{ url } ? { trust line instructions }`
23+
24+
So for example
25+
26+
`anything://any.domain/url/?action=trustline&limit=10000&currency=rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B:USD&rippling=false`
227

3-
I suggest we follow on closely from the design of XLS-2d
4-
5-
Query parameters:
6-
`action=trustline`
7-
`limit=<integer>`
8-
`currency=<issuer address>:<currency code>`
9-
`rippling=true|false (optional, default = false)`
10-
11-
I.e.
12-
13-
`{ url } ? { trust line instructions }`
14-
15-
So for example
16-
17-
`anything://any.domain/url/?action=trustline&limit=10000&currency=rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B:USD&rippling=false`
18-
1928
I realise compounding the currency and issuer information is a little tacky here but we did it in the previous standard

‎XLS-0005-tagged-addresses/README.md‎

Lines changed: 8 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -1,12 +1,12 @@
11
<pre>
2-
XLS-5 - XRP Ledger Proposed Standard #5
3-
4-
Title: Tagged Addresses
5-
Author: Nikolaos D. Bougalis <nikb@bougalis.net>
6-
Affiliation: Ripple
7-
Created: 2019-05-15
8-
9-
Original: https://github.com/xrp-community/standards-drafts/issues/6
2+
xls: 5
3+
title: Tagged Addresses
4+
description: A standard for addresses that contain both the target wallet and destination tag as a single unit
5+
author: Nikolaos D. Bougalis <nikb@bougalis.net>
6+
discussion-from: https://github.com/XRPLF/XRPL-Standards/discussions/142
7+
status: Final
8+
category: Community
9+
created: 2019-06-04
1010
</pre>
1111

1212
# Abstract

‎XLS-0007-deletable-accounts/README.md‎

Lines changed: 8 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -1,12 +1,12 @@
11
<pre>
2-
XLS-7 - XRP Ledger Proposed Standard #7
3-
4-
Title: Deletable Accounts on the XRP Ledger
5-
Author: Scott Schurr &lt;scott@ripple.com&gt;
6-
Nik Bougalis &lt;nikb@bougalis.net&gt;
7-
Affiliation: Ripple
8-
Created: 2019-10-01
9-
Issue: https://github.com/xrp-community/standards-drafts/issues/8
2+
xls: 7
3+
title: Deletable Accounts
4+
description: A feature for completely removing accounts from the ledger and recovering the reserve from those accounts
5+
author: Scott Schurr <scott@ripple.com>, Nik Bougalis <nikb@bougalis.net>
6+
discussion-from: https://github.com/XRPLF/XRPL-Standards/discussions/8
7+
status: Final
8+
category: Amendment
9+
created: 2019-10-01
1010
</pre>
1111

1212
# Abstract

‎XLS-0012-secret-numbers/README.md‎

Lines changed: 10 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -1,11 +1,13 @@
1-
| | Info |
2-
|-------|---------|
3-
| Draft | XLS-12 |
4-
| Title | Secret Numbers |
5-
| Author(s) | Wietse Wind <w@xrpl-labs.com>, based on an idea by [Nik Bougalis](https://github.com/nbougalis) |
6-
| Created | 2019-07-12 ([TS Lib.](https://github.com/WietseWind/xrpl-secret-numbers)) / 2020-05-13 (Draft) |
7-
8-
---
1+
<pre>
2+
xls: 12
3+
title: Secret Numbers
4+
description: Derive XRPL account keypairs based on 8x 6 digits for user-friendly, language-agnostic account secrets
5+
author: Wietse Wind <w@xrpl-labs.com>, Nik Bougalis (@nbougalis)
6+
discussion-from: https://github.com/XRPLF/XRPL-Standards/discussions/15
7+
status: Final
8+
category: Community
9+
created: 2020-05-13
10+
</pre>
911

1012
# XLS-12: Secret Numbers
1113
### Derive XRPL account keypairs based on 8x 6 digits

‎XLS-0020-non-fungible-tokens/README.md‎

Lines changed: 9 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -1,12 +1,12 @@
11
<pre>
2-
Title: <b>Non-Fungible Token Support</b>
3-
Revision: <b>10</b> (2023-03-27)
4-
5-
<hr> Author: <a href="mailto:david@ripple.com">David J. Schwartz</a>
6-
<a href="mailto:amalhotra@ripple.com">Aanchal Malhotra</a>
7-
<a href="mailto:nikb@bougalis.net">Nikolaos D. Bougalis</a>
8-
Editor: <a href="mailto:shawnxie@ripple.com">Shawn Xie</a>
9-
Affiliation: <a href="https://ripple.com">Ripple</a>
2+
xls: 20
3+
title: Non-Fungible Token Support
4+
description: Extensions to the XRP Ledger that support a native non-fungible token type with operations to enumerate, purchase, sell and hold such tokens
5+
author: David J. Schwartz <david@ripple.com>, Aanchal Malhotra <amalhotra@ripple.com>, Nikolaos D. Bougalis <nikb@bougalis.net>
6+
discussion-from: https://github.com/XRPLF/XRPL-Standards/discussions/46
7+
status: Final
8+
category: Amendment
9+
created: 2021-05-24
1010
</pre>
1111

1212
# 1. Non-Fungible Token Support
@@ -859,4 +859,4 @@ Without this restriction, the following example demonstrates how a duplicate NFT
859859

860860
## History
861861

862-
This spec, at revision 10, describes XLS-20 with [the `fixNFTokenRemint` amendment](https://xrpl.org/known-amendments.html#fixnftokenremint) active. For earlier versions of this spec, please see [the commit history](https://github.com/XRPLF/XRPL-Standards/commits/master/XLS-20).
862+
This spec, at revision 10, describes XLS-20 with [the `fixNFTokenRemint` amendment](https://xrpl.org/known-amendments.html#fixnftokenremint) active. For earlier versions of this spec, please see [the commit history](https://github.com/XRPLF/XRPL-Standards/commits/master/XLS-0020-non-fungible-tokens/README.md).

0 commit comments

Comments
 (0)