From cjp at ultimatestunts.nl Mon Sep 21 17:43:48 2015 From: cjp at ultimatestunts.nl (CJP) Date: Mon, 21 Sep 2015 19:43:48 +0200 Subject: [Lightning-dev] Standardization In-Reply-To: <87twrd1i1r.fsf@rustcorp.com.au> References: <87si7eiehg.fsf@rustcorp.com.au> <87h9ntifwf.fsf@rustcorp.com.au> <877fopi4un.fsf@rustcorp.com.au> <20150829074239.GA15643@navy> <874mjgqne2.fsf@rustcorp.com.au> <87si6ybnmm.fsf@rustcorp.com.au> <87twrd1i1r.fsf@rustcorp.com.au> Message-ID: <1442857428.4657.35.camel@hppg6.kloosterkade> On returning home from the Scaling Bitcoin workshop, I thought it was great meeting some people in real life and discovering we basically all want to achieve the same things. Still, I think there are some differences in how we think certain problems should be addressed. Design decisions in Lightning don't suffer from the same "consensus" necessity as the block validity rules in Bitcoin, but still, some decisions carry a strong network effect, and might be hard to reverse once made. The people I talked to felt the need to make no mistakes on these design decisions, but at the same time I feel the need to make them ASAP, so we can quickly launch a prototype and convince the world of how great this is. Because of this, I'd like to have a well-organized process of collecting and documenting design ideas and trade-off argumentation, and hopefully reach some consensus on what are good and bad ideas. This should also serve to increase interoperability between the several pieces of software that are being developed. Some of my ideas on how to shape this: We could have a Git repository, containing all concepts and standards. New ideas, amendments & so on can be exchanged like pull requests. We may / may not also need a process to make actual design decisions, but assigning one Git clone to be the "true" one might be too simplistic (I don't want to have a dictator). As long as the Lightning dev community is small, a "100% consensus" rule might still be workable though. I'd like to make a distinction between concepts and standards. The idea is that a concept is a non-trivial design decision; typically people can have strong preference between different alternative, mutually incompatible concepts. Standards are based on concepts, and fill in all the trivial design decisions that have to be made to make different pieces of software inter-operable. For concept choices, I made the following template: https://gist.github.com/anonymous/51631fe56f1f83e4af0a What do you think? CJP PS. Rusty suggested something like an RFC-like process for Lightning. I'm not an expert on RFCs, and my proposal is probably a bit different from the RFC process. I'm open to other ideas and I'd like to be informed about why we should use an RFC-like process or something else.