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: CONTRIBUTING.md
+7-5Lines changed: 7 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,9 +1,10 @@
1
1
# CONTRIBUTING
2
2
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.
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.
4
4
5
5
## Licensing
6
-
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:
6
+
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:
7
8
8
9
- Copyright: a royalty-free license to anyone to use any contributions submitted to this repository.
9
10
- Patent: a commitment to license on a royalty-free basis any essential patent claims relating to any contributions in this repository.
@@ -15,14 +16,16 @@ Any XRPL Standards document can be referred to interchangeably as an "XLS", "XRP
15
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.
16
17
17
18
#### Discussion Title
19
+
18
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.
19
21
20
22
#### Specification Number
23
+
21
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.
22
25
23
26
### 2. Closing a Discussion
24
27
25
-
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.
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.
26
29
27
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).
28
31
@@ -32,7 +35,7 @@ The intention of this workflow is that the discussion be closed from further com
32
35
33
36
### 3. Specification Pull Requests
34
37
35
-
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.
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.
36
39
37
40
#### Drafts
38
41
@@ -66,7 +69,6 @@ Refinements in detail are still allowed and recommended. For example, you can cl
66
69
67
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`.
68
71
69
-
70
72
Once published as a Candidate Specification, no further substantive changes are allowed under the same XLS number.
71
73
72
74
For Specifications that require changes or implementation in the XRP Ledger server software and protocol, the Candidate Specification cannot be published until the relevant change has been merged into [the software's `master` branch](https://github.com/XRPLF/rippled/tree/master).
Copy file name to clipboardExpand all lines: README.md
+5-5Lines changed: 5 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,10 +2,10 @@
2
2
3
3
XRP Ledger Standards (XLSs) describe standards and specifications relating to the XRP Ledger ecosystem that help achieve the following goals:
4
4
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).
8
-
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).
8
+
9
9
# [Contributing](./CONTRIBUTING.md)
10
10
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.
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.
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:
0 commit comments