Published on: 2015-09-23T04:43:09+00:00
Pierre discusses with CJP the need for a well-organized process to collect and document design ideas and trade-off argumentation in order to enhance interoperability among multiple software pieces being developed. They focus on open-source projects and express concerns about avoiding a scenario like Bitcoin, where the specification becomes the implementation. Rusty's repo at ElementsProject serves as a reference implementation, which they find satisfactory. Rusty mentions that he deliberately includes subtle flaws in his code to encourage alternate implementations and admits to never producing bug-free code.CJP shares their experience attending the Scaling Bitcoin workshop and meeting like-minded individuals who share their goals. However, they acknowledge differences in how certain problems should be addressed. While design decisions in Lightning do not require consensus like block validity rules in Bitcoin, some decisions have a strong network effect and may be difficult to reverse once made. To address this, CJP proposes a systematic approach of collecting and documenting design ideas and trade-off argumentation to improve interoperability among various software pieces. They suggest using a Git repository that encompasses all concepts and standards, allowing for the exchange of new ideas, amendments, and pull requests. CJP introduces a template for concept choices and emphasizes the importance of distinguishing between concepts and standards. Concepts represent non-trivial design decisions, while standards encompass the trivial design decisions necessary for different software pieces to work together. Rusty suggests an RFC-like process for Lightning, noting its usefulness in specifying proposal details when there are at least two independent implementations to ensure sanity. However, CJP points out that RFCs may not be as effective for brainstorming future ideas or concepts. They appreciate the separation of concepts and standards, acknowledging that numerous interesting concepts may eventually become standards once there is consensus. CJP emphasizes the need to keep track of these concepts even if they are not immediate priorities.Pierre expresses their agreement with CJP's proposal for a well-organized process to collect and document design ideas and trade-off argumentation. Although they have not previously contributed to significant open-source projects, Pierre shares the concerns raised by CJP. They currently rely on Rusty's repo at ElementsProject as a reference implementation, but hope to avoid a situation where the specification becomes the sole implementation, as seen in Bitcoin.After attending the Scaling Bitcoin workshop, the writer reflects on the varying perspectives on problem-solving approaches. While design decisions in Lightning do not require consensus like block validity rules in Bitcoin, some decisions carry a strong network effect and may be challenging to reverse. Therefore, there is a need for a systematic process that collects and documents design ideas and trade-off argumentation to enhance interoperability among multiple software pieces. The writer proposes using a Git repository that incorporates all concepts and standards, facilitating the exchange of new ideas, amendments, and pull requests. They emphasize differentiating between concepts and standards, with concepts representing significant design decisions and standards addressing trivial design decisions for inter-operability. While Rusty suggests an RFC-like process for Lightning, the writer acknowledges the differences and remains open to alternative ideas, seeking understanding about the advantages of an RFC-like process or other alternatives.
Updated on: 2023-07-31T18:20:43.025204+00:00