Skip to content

Commit 2050062

Browse files
dangell7dangell7
authored
Merge branch 'master' into xls-35d
2 parents 005ee04 + 7ce783a commit 2050062

File tree

78 files changed

+19719
-886
lines changed

Some content is hidden

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

78 files changed

+19719
-886
lines changed

‎.github/dependabot.yml‎

Lines changed: 34 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,34 @@
1+
# Dependabot configuration for keeping dependencies updated
2+
# https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file
3+
4+
version: 2
5+
updates:
6+
# Python dependencies (requirements.txt)
7+
- package-ecosystem: "pip"
8+
directory: "/"
9+
schedule:
10+
interval: "weekly"
11+
day: "monday"
12+
time: "09:00"
13+
open-pull-requests-limit: 5
14+
reviewers:
15+
- "mvadari"
16+
- "intelliot"
17+
commit-message:
18+
prefix: "deps"
19+
include: "scope"
20+
21+
# GitHub Actions dependencies
22+
- package-ecosystem: "github-actions"
23+
directory: "/"
24+
schedule:
25+
interval: "weekly"
26+
day: "monday"
27+
time: "09:00"
28+
open-pull-requests-limit: 5
29+
reviewers:
30+
- "mvadari"
31+
- "intelliot"
32+
commit-message:
33+
prefix: "ci"
34+
include: "scope"

‎.github/workflows/deploy.yml‎

Lines changed: 67 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,67 @@
1+
name: Deploy XLS Standards to GitHub Pages
2+
3+
on:
4+
push:
5+
branches: [master]
6+
workflow_dispatch:
7+
8+
permissions:
9+
contents: read
10+
pages: write
11+
id-token: write
12+
13+
concurrency:
14+
group: "pages"
15+
cancel-in-progress: false
16+
17+
jobs:
18+
build:
19+
if: github.repository == 'XRPLF/XRPL-Standards'
20+
runs-on: ubuntu-latest
21+
steps:
22+
- name: Checkout
23+
uses: actions/checkout@v5
24+
25+
- name: Setup Python
26+
uses: actions/setup-python@v6
27+
with:
28+
python-version: "3.11"
29+
30+
- name: Cache Python dependencies
31+
uses: actions/cache@v4
32+
id: cache-deps
33+
with:
34+
path: ~/.cache/pip
35+
key: ${{ runner.os }}-pip-${{ hashFiles('**/site/requirements.txt') }}
36+
restore-keys: |
37+
${{ runner.os }}-pip-
38+
39+
- name: Install dependencies
40+
run: |
41+
python -m pip install --upgrade pip
42+
pip install -r site/requirements.txt
43+
44+
- name: Build site
45+
run: python site/build_site.py
46+
env:
47+
GITHUB_PAGES_BASE_URL: ""
48+
49+
- name: Setup Pages
50+
uses: actions/configure-pages@v5
51+
52+
- name: Upload artifact
53+
uses: actions/upload-pages-artifact@v4
54+
with:
55+
path: "site/_site"
56+
57+
deploy:
58+
if: github.repository == 'XRPLF/XRPL-Standards'
59+
environment:
60+
name: github-pages
61+
url: ${{ steps.deployment.outputs.page_url }}
62+
runs-on: ubuntu-latest
63+
needs: build
64+
steps:
65+
- name: Deploy to GitHub Pages
66+
id: deployment
67+
uses: actions/deploy-pages@v4

‎.github/workflows/lint.yml‎

Lines changed: 25 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,25 @@
1+
name: Lint
2+
3+
on:
4+
push:
5+
branches: [master]
6+
pull_request:
7+
workflow_dispatch:
8+
9+
jobs:
10+
prettier:
11+
runs-on: ubuntu-latest
12+
steps:
13+
- name: Checkout code
14+
uses: actions/checkout@v5
15+
16+
- name: Set up Node.js
17+
uses: actions/setup-node@v5
18+
with:
19+
node-version: "24"
20+
21+
- name: Install dependencies
22+
run: npm install -g prettier
23+
24+
- name: Run Prettier
25+
run: npx prettier --check .

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

Lines changed: 47 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,47 @@
1+
name: Validate XLS Documents
2+
3+
on:
4+
push:
5+
branches: [master]
6+
pull_request:
7+
workflow_dispatch:
8+
9+
jobs:
10+
validate-xls:
11+
runs-on: ubuntu-latest
12+
name: Validate XLS Document Parsing
13+
14+
steps:
15+
- name: Checkout repository
16+
uses: actions/checkout@v5
17+
18+
- name: Setup Python
19+
uses: actions/setup-python@v6
20+
with:
21+
python-version: "3.11"
22+
23+
- name: Cache Python dependencies
24+
id: cache-deps
25+
uses: actions/cache@v4
26+
with:
27+
path: ~/.cache/pip
28+
key: ${{ runner.os }}-pip-${{ hashFiles('**/site/requirements.txt') }}
29+
restore-keys: |
30+
${{ runner.os }}-pip-
31+
32+
- name: Install dependencies
33+
run: |
34+
python -m pip install --upgrade pip
35+
pip install -r site/requirements.txt
36+
37+
- name: Validate XLS document parsing
38+
run: |
39+
echo "Running XLS document validation..."
40+
python site/xls_parser.py
41+
42+
- name: Report validation results
43+
if: always()
44+
run: |
45+
echo "XLS validation completed"
46+
echo "This pipeline validates that all XLS documents can be parsed correctly"
47+
echo "If this fails, it indicates issues with XLS document formatting or metadata"

‎.gitignore‎

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,8 @@
1+
.DS_Store
2+
/.idea
3+
_site/
4+
5+
# Python cache files
6+
__pycache__/
7+
*.pyc
8+
*.pyo

‎.pre-commit-config.yaml‎

Lines changed: 14 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,14 @@
1+
repos:
2+
- repo: https://github.com/pre-commit/pre-commit-hooks
3+
rev: 3e8a8703264a2f4a69428a0aa4dcb512790b2c8c # frozen: v6.0.0
4+
hooks:
5+
- id: trailing-whitespace
6+
- id: end-of-file-fixer
7+
- id: mixed-line-ending
8+
- id: check-merge-conflict
9+
args: [--assume-in-merge]
10+
11+
- repo: https://github.com/rbubley/mirrors-prettier
12+
rev: 5ba47274f9b181bce26a5150a725577f3c336011 # frozen: v3.6.2
13+
hooks:
14+
- id: prettier

‎CONTRIBUTING.md‎

Lines changed: 32 additions & 40 deletions
Original file line numberDiff line numberDiff line change
@@ -1,81 +1,73 @@
11
# CONTRIBUTING
22

3-
Contributions to this repo are free, open-source, and follow the process outlined below:
3+
The work of the [XRP Ledger](https://xrpl.org) community is open, collaborative, and welcoming of all contributors participating in good faith. Part of that effort involves standardization, and this document outlines how anyone can contribute to that process.
44

5-
Any XRPL-Standards document can be referred to interchangeably as an "XLS", "XRPL Standard", or "document".
5+
## Licensing
66

7-
## Summary
7+
Any XRPL Standards document can be referred to interchangeably as an "XLS", "XRPL Standard", or "document". Copyright on all content is subject to the terms of this [license](LICENSE), and all contributors grant everyone a royalty-free license to use their contributions, including the following grants:
88

9-
Copyright on all content is subject to the terms of the [license](LICENSE).
9+
- Copyright: a royalty-free license to anyone to use any contributions submitted to this repository.
10+
- Patent: a commitment to license on a royalty-free basis any essential patent claims relating to any contributions in this repository.
1011

11-
All contributors grant everyone:
12+
## Specification Process
1213

13-
Copyright: a royalty-free license to use the copyrights for their contributions.
14-
Patent: a commitment to license on a royalty-free basis their essential patent claims reading on their contributions.
14+
### 1. Start a Discussion & Gather Feedback
1515

16-
## Background
16+
Before opening a PR with any kind of formal proposal, please first gather community input by starting a [Discussion](https://github.com/XRPLF/XRPL-Standards/discussions). Discussions are suitable for early work-in-progress: ask, suggest, add, and make sweeping changes. Collecting such feedback helps to refine your concept, and is required in order to move forward in the specification process.
1717

18-
The work of the XRP Ledger community is open source, collaborative, and welcoming of all contributors participating in good faith. [Learn more about the XRP Ledger at XRPL.org](https://xrpl.org/).
18+
#### Discussion Title
1919

20+
When creating a new discussion for your idea, the discussion title should follow the naming convention `XLS-{0000}d {Title}`, where `{0000}` is a unique number for the XLS, `d` indicates that the document is a Draft (i.e., work in progress), and `{Title}` is a descriptive title for the proposed document.
2021

21-
## Process
22+
#### Specification Number
2223

23-
The XRPL-Standards process attempts to be easy to use, but also rigorous enough that there are permalinks to revisions of documents for reference purposes.
24+
Use the next number that has not yet been used. If a conflict occurs, it will be fixed by a maintainer or editor. Maintainers or editors also reserve the right to remove or re-number proposals as necessary. The number is important, as it will be used to reference features and ideas throughout the community.
2425

25-
### Gathering Feedback Before Submitting
26+
### 2. Closing a Discussion
2627

27-
Please gather community input before opening a PR. Collecting such feedback helps to refine your concept. This step is required.
28+
When a discussion has produced a well-refined standard, authors should post a comment to the discussion noting that the discussion will be closed in a few days. This allows time (for those engaged with the discussion) to submit final commentary.
2829

29-
Start a [Discussion](https://github.com/XRPLF/XRPL-Standards/discussions) under this repo.
30+
Once this waiting period has elapsed, the standard's author may close the discussion from further comment, and then move the discussion to a [**specification pull request**](#3-specification-pull-requests) to add the standard into the repository as a markdown file (see below for specification formats).
3031

31-
The title should follow the naming convention `XLS-0000d {Title}`, where `0000` is a unique number for the XLS, `d` indicates that the document is a Draft (in progress), and `{Title}` is a descriptive title for the proposed document.
32+
Next, the discussion author should edit the discussion to include a link to the PR. The last comment on the discussion should also be a link to the PR.
3233

33-
Use the next number that has not yet been used. If a conflict occurs, it will be fixed by a maintainer or editor. Maintainers or editors also reserve the right to remove or re-number proposals as necessary.
34+
The intention of this workflow is that the discussion be closed from further comments, with further comments instead being posted on the PR for fine-tuning and alignment with implementation or adoption, as appropriate.
3435

35-
The number is important, as it will be used to reference features and ideas throughout the community.
36+
### 3. Specification Pull Requests
3637

37-
Discussions are suitable for early work-in-progress: ask, suggest, add, and make sweeping changes.
38+
When opening a specification PR, there are two document types: _Drafts_ and _Candidate Specifications_. The type and status of any particular document has no bearing on the priority of that document. Typically, the further along in the process, the more likely it is that any particular XLS will be implemented or adopted.
3839

39-
When a discussion has produced a well-refined standard, authors should post a comment to the discussion noting that it will be closed in a few days. This allows time (for those engaged with the discussion) to submit any final commentary.
40-
41-
When the fair notice time has elapsed, the author should move from discussion to Draft by opening a PULL REQUEST.
42-
43-
44-
The standard's author must edit and replace the post with a summary and a link to the PR.
45-
46-
The last comment on the discussion should also be a link to the PR.
47-
48-
Finally, the discussion should be closed from further comments, with further comments instead being posted on the PR for fine-tuning and alignment with implementation or adoption (as appropriate).
49-
50-
When opening a PR, there are two document types: *Drafts* and *Candidate Specifications*. The type and status of any particular document has no bearing on the priority of that document. Typically, the further along in the process, the more likely it is that any particular XLS will be implemented or adopted.
51-
52-
### Drafts
40+
#### Drafts
5341

5442
A _Draft_ is a document that proposes some new feature, protocol or idea related to the XRP Ledger. The criteria for getting the document merged is minimal: project maintainers will review the document to ensure style conformance and applicability, but will otherwise not require editorial fixes before allowing it to be published.
5543

56-
A document does not need to have an implementation in order to become a Draft. A Draft may or may not have implementation(s) available; no code is required prior to the Draft being published.
44+
A document does not need to have an implementation in order to become a Draft. A Draft may or may not have implementation(s) available and no code is required prior to the Draft being published.
45+
5746
A Draft is often stable enough for people to experiment with, but has not necessarily been endorsed by the entire community. When there are competing Drafts that address the same problem in different ways, all such Drafts can continue to be refined, promoted, and used independently, without any blocking. Implementors can create software to implement this type of standard into their codebase to explore how it works in a real world setting.
5847

59-
Any, or all, competing Drafts may graduate into a Candidate Specification.
48+
Any, or all, competing Drafts _may_ graduate into a Candidate Specification.
6049

6150
Notice that a Draft is not a [rubber-stamp](https://idioms.thefreedictionary.com/rubber-stamp) of the content in any particular document. Documents can still undergo significant changes and potentially be discarded all together.
6251

63-
#### Publishing a Draft
52+
##### Publishing a Draft
53+
54+
To publish a new Draft, submit a Pull Request to this repo with a new folder and a new Markdown file. The folder MUST follow the naming convention `XLS-{0000}d-{title}` where `{0000}` is the unique number referencing the XLS, `d` indicates that the document is a Draft, and `{title}` is a lower case title with spaces replaced by hyphens (`-`). The submission should have front-matter (similar to GitHub pages rendered from Markdown) specifying at least a `title` and `type`. The `type` MUST have the value `draft`.
6455

65-
To publish a new Draft, submit a Pull Request to this repo with a new folder and a new Markdown file. The folder MUST follow the naming convention `XLS-0000d-{title}`, `0000` is the unique number referencing the XLS, `d` indicates that the document is a Draft, and `title` is a lower case title with spaces replaced by hyphens (`-`). The submission should have front-matter (similar to GitHub pages rendered from Markdown) specifying at least a `title` and `type`. The `type` MUST have the value `draft`.
56+
An example draft name is: `XLS-20d-non-fungible-token-support-native`
6657

6758
Use the following template when creating the Markdown file: [xls-template.md](./xls-template.md)
6859

6960
Assuming there is consensus to publish, one of the project maintainers will review the submission and confirm the document's XLS number, often making a follow-up commit to the PR which renames the file as appropriate.
7061

71-
### Candidate Specifications
62+
#### Candidate Specifications
7263

73-
A _Candidate Specification_ is a document that was previously a Draft that is considered stable enough by the community such that no further changes are required. Once an XLS becomes a Candidate Specification, no further substantive changes are allowed under the same XLS number.
64+
A _Candidate Specification_ is a document that was previously a Draft, but is considered stable enough by the community such that no further changes are required. Once an XLS becomes a Candidate Specification, no further substantive changes are allowed under the same XLS number.
7465

75-
#### Publishing a Candidate Specification
66+
Refinements in detail are still allowed and recommended. For example, you can clarify exact error cases and define the error codes and transaction result codes that occur in those cases.
7667

77-
When a Draft is considered stable, there is a call for review from the community to publish the document as a Candidate Specification by making a PR to remove the `d` from the document folder name and update the `type` to `candidate-specification`.
68+
##### Publishing a Candidate Specification
7869

70+
When a Draft is considered stable, there is a call for review from the community to publish the document as a Candidate Specification by making a PR to remove the `d` from the document folder name and update the `type` to `candidate-specification`.
7971

8072
Once published as a Candidate Specification, no further substantive changes are allowed under the same XLS number.
8173

‎README.md‎

Lines changed: 7 additions & 20 deletions
Original file line numberDiff line numberDiff line change
@@ -1,24 +1,11 @@
1-
# XRP Ledger Standards / Drafts
1+
# XRP Ledger Standards
22

3-
To ensure interoperability between XRP (Ledger) applications, tools, platforms, pursuing a great user experience, the community (developers, users, etc.) _should_ agree on certain specifications.
4-
5-
# [Contributing](./CONTRIBUTING.md)
6-
7-
Please see [CONTRIBUTING.md](./CONTRIBUTING.md)
8-
9-
# Directory
10-
11-
When a standard moves to a folder + file(s) in the Code section of this repository, it should be added to the `standards.toml` file:
12-
https://github.com/XRPLF/XRPL-Standards/blob/master/standards.toml
3+
XRP Ledger Standards (XLSs) describe standards and specifications relating to the XRP Ledger ecosystem that help achieve the following goals:
134

14-
# Numbering
5+
- Ensure interoperability and compatibility between XRP Ledger core protocol, ecosystem applications, tools, and platforms.
6+
- Maintain a continued, excellent user experience around every application or system.
7+
- Drive alignment and agreement in the XRPL community (i.e., developers, users, operators, etc).
158

16-
Standards must be numbered and referenced in the following format: XLS-# where # is a natural number (without left padded zeros), called the __Standard Number__.
17-
18-
# Revisions
19-
20-
If a standard requires a substantive revision and using the same number would result in confusion, a separator '.' may be added, e.g. `XLS-1.1`.
21-
22-
# Drafts
9+
# [Contributing](./CONTRIBUTING.md)
2310

24-
A standard which has not yet been adopted may 'hold' a Standard Number but must be referred to with a __d__ suffix until it becomes a full standard, e.g. `XLS-10d` or `XLS-1.2d`.
11+
The exact process for organizing and contributing to this repository is defined in [CONTRIBUTING.md](./CONTRIBUTING.md). If you would like to contribute, please read more there.

‎XLS-0002-destination-information/README.md‎

Lines changed: 37 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,37 @@
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:
37+
https://anotherapp.net/deposit-xrp?to=...&dt=1234&amount=10

0 commit comments

Comments
 (0)