[dlc-dev] Breaking Changes Discussion
nadavk25 at gmail.com
Sat Sep 18 18:52:13 CEST 2021
So at the last spec meeting we began a general discussion about making
breaking changes to the DLC specs and it didn't really reach a conclusion
so I'd like to continue that conversation here.
Here is my attempt to summarize the state of things:
- There has functionally been a freeze on breaking changes to the
dlcspecs repo for many months now.
- It appears that this is largely due to wanting to be cautious about
making breaking changes to existing, user-facing applications.
- On the other hand, the specs are not done and furthermore, none of the
existing applications are (fully) spec-compliant.
- Most implementations currently agree on enumerated outcomes and
oracle messages, but little else.
- There are a good number of breaking changes in the pipeline including
(but probably not limited to)
- P2P message serialization
- Oracle messages and key infrastructure
- Event order specification
- Roughly, the stances I've heard so far is that
- Specification changes should continue and it should be on
implementations to decide how spec compliant (and to which spec
be compliant with the goal that someday everyone is compliant to the same
thing (noting no one is currently at that state anyway)
- Specification changes shouldn't be made very often and there should
be some mechanism to group a bunch of changes together (e.g. all four of
the above as one protocol update with a new version)
I won't put my personal opinions in this discussion starter email (I will
likely do this later in the thread), but here are the questions I think
need to be discussed:
1. The DLC specification and improvements to it are not done and it
appears that (partial, non-compliant) implementations have become
user-facing, what mechanisms are available to us that are the least painful
for these applications that will allow DLC specification work to continue?
2. Are there explicit benefits to be gained by freezing development or
else tagging a version? It is currently unclear (at least to me) what falls
in the realm of specification-level concerns and what is
3. Explicitly, what are the purported/desired benefits from having a
unified specification for DLC development and how do these affect the above
4. What is our path forward towards cross-implementation compatibility?
There are likely other considerations I'm missing here so please feel free
to respond on this thread with other things you think are important. Also
people should feel free to respond to any number (including just one) of
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dlc-dev