Differentiate between (Ecosystem) Proposals & network specific (Implementation) Standards #160
Replies: 2 comments 5 replies
-
|
Agree and it how I have viewed all of this, think most of us were here already. XES Is a great way to facilitate the basic idea and then specific implementation refinement. While allowing all to collaborate, issues with spec can be caught below and solutions bubbled up. Keeping all this in one repo is a big win vs having them fragmented. |
Beta Was this translation helpful? Give feedback.
-
|
I like this approach, but at the same time I can't help but think Occam's Razor applies here as well. in a year or two, what if there's 10+ different sidechain and/or forks, the discussion section of the repo becomes extremely cluttered and harder to navigate. I don't really see much downside in just having separate repos altogether as a separation of concerns. |
Beta Was this translation helpful? Give feedback.
-
|
Having looked into this recently there is no clear path from Proposal to Amendment, nor is there a requirement for an an amendment to be formalized before it is used in a test environment. There are currently features not formalized as amendments live in testing environments. Looking across the various networks running (compared 7), there is a mix of amendments across all networks. Given that XLS is an identifier that is not relative to any one blockchain and, for the most part, all amendments are able to be used in all XRPL based chains, that commonality should remain. Currently
As a thought, If you had a register where every proposal was given a UID, even if it never went beyond a proposal, it would maintain its uniqueness, so that in the future if it was revisited it would still have its uniqueness it started with when it first registered. If it moves to a Standard then it is allocated the next available Standard ID and Amendment ID if it moves to an amendment. All amendments, even if fixes, should be allocated an XLS-ID Status is relative to Deleted, Obsolete or Deprecated The register could be something like this:
At any given time you can link a proposal or a standard or an amendment to each other without effort. So, for example. Clawback would be: or, perhaps
|
Beta Was this translation helpful? Give feedback.
-
|
All commits/PR are uniquely identified already and referenced in builds. XLS used for all forks of the XRPL seems not really good idea. Amendments are not plug and play, just because chains have the same origin doesn't mean they are interoperable. Stellar is the best example for this. |
Beta Was this translation helpful? Give feedback.
-
|
They may not be plug and play, but you can certainly see how they're used that way. Now try and associate Standards with Proposals and Amendments. https://docs.google.com/spreadsheets/d/1G0dGSazEoRHwClyUqWAQHBVHO2z4Z_kmfrWCFHlW3g4/edit?usp=sharing |
Beta Was this translation helpful? Give feedback.
-
|
@rippleitinnz Can you clarify the problem you're trying to solve? It's unclear to me if you are proposing just a tracking system so we can connect XLS's to Amendments and networks, or if you are instead proposing an adjustment to the XLS process (and maybe even to the Amendment process) that seeks to create a strong tie between the two.
At the moment, this is somewhat intentional (although I would probably restate what I mean there by saying, "we purposefully didn't add anything on this topic into CONTRIBUTING.md when we drafted it"). The reason for that omission is: the XLS process is meant to be somewhat orthogonal to, and independent from, the Amendment process. There are a variety of reasons for this, but one big reason is that the XLS process involves different people/entities, has slightly different goals, and shouldn't assert itself into the Amendment process. For example, some goals of XLS are (a) good design; (b) interoperability; (c) formalizing protocols. Alternatively, entities voting
If you're meaning, "tracking system", then this seems like a fine idea; it's good community (and even protocol) hygiene. But in this case, why not just make a website, or even use your google doc (which I actually found pretty helpful) for this kind of tracking? Everything is already identified, so we just need a place that connects things together, as you've done. However, if you're proposing some stronger connection between XLS and Amendment -- like, "it can't become an Amendment without having gone through the XLS process" or conversely, "enabled Amendments aren't valid if they don't have an XLS", then I would object because these two mechanisms are very different, with different decision-making structures and authority boundaries. |
Beta Was this translation helpful? Give feedback.
-
|
Primarily a simple mechanism to understand all proposals, what XLS- standard they relate to, if one exists and what amendment it relates to, if one exists. This then becomes backwards compatible in that an amendment or a Standard can identify all discussions or information around it. Numerous proposals may end up in one amendment for example. Or one XLS May end up in numerous Amendments. As you can see from my sheet, naming of proposals, standards and amendments differ greatly and it's actually really difficult to understand all relevant docs/discussions/standards that result in the features we have. |
Beta Was this translation helpful? Give feedback.
-
Following a discussion on X, it is proposed to revise the approach to the 'XLS' (XRPL Standards) system within the ecosystem and among developers. Originally designed to function like RFPs, facilitating high-level standard discussions about protocol, implementations, and features, the XLS system has predominantly published alpha/beta "Standards". These often closely resemble final standards after edits and usually include pre-coded implementations, leading to the use of XLS primarily for comments on implemented features / proposed changes.
The expanding ecosystem, including multi-chain, EVM side chain, Xahau, etc., and diverse features across different chains, suggests the need for changes in the handling of XLS. A unified repository for ideas and high-level standards across different chains/protocols is seen as highly valuable for fostering growth and synergy within the ecosystem.
A distinction is recommended between high(er) level standard discussions and implementations. For instance, in the context of NFTs, the high-level discussion should encompass ecosystem-wide considerations like minting and transferability, while implementations may vary (e.g., RippleX's XLS20, EVM Sidechain's ERC20, Xahau/Hooks' URIToken).
Similarly, for multi-asset transactions and asset transfers between networks, high-level discussions should focus on universal requirements and concerns, followed by network-specific implementation discussions.
The proposal entails separating universal, high-level ecosystem proposals/suggestions from network-specific implementations. High-level proposals should ideally precede network-specific discussions, but reverse processes are also acceptable if they contribute to the broader ecosystem perspective.
Regarding naming conventions, it is proposed to retain
XLSfor XRPL mainnet specifications, introduceXASfor Hooks enabled/specific networks, and??Sfor EVM side chains, withXES(XRP Ledger Ecosystem Suggestions) for high-level ecosystem proposals, resembling RFCs.An example is provided with Liquidity Pools, suggesting a layered approach to standards development, beginning with ecosystem-wide considerations (XES) and then delving into network-specific implementations (XLS, ??S, XAS).
This approach, though more labor-intensive, is believed to effectively balance ecosystem-wide progress with network-specific advancements. A centralized repository with structured discussions and a well-maintained README is suggested for efficient collaboration and information dissemination.
Looping in @Silkjaer @lathanbritz @dangell7 @RichardAH @alloynetworks @jscottbranson @mvadari @aanchal4 @wojake
Beta Was this translation helpful? Give feedback.
All reactions