How it changes
Last updated
Weald Protocol governance defines three change classes and a mechanical test for whether a change breaks an existing implementation. Breaking changes take a version, carry a thirty day public comment period, and are announced before they ship. The document states that one person maintains it and names the trigger for changing that.
The three classes
| Class | Test | What it costs |
|---|---|---|
| Editorial | No conforming implementation behaves differently | Nothing, and it ships when written |
| Compatible | An old implementation still interoperates with a new one | A release note |
| Breaking | An old implementation stops interoperating | A version, thirty days notice, and an announcement |
The test is mechanical, so nobody in a hurry can reclassify a breaking change as compatible.
What counts as breaking
Four changes are breaking. They are changing the pinned ciphersuite, removing a field a conforming implementation reads, tightening a validation rule so that previously accepted frames are refused, and changing the meaning of an existing error code.
Adding an optional field, adding an error code, and relaxing a rule are compatible. Renaming anything is breaking, even when the bytes are identical, because a name is part of the contract an implementer coded against.
Deprecation
A ciphersuite change carries a five stage calendar over eighteen months, with two named emergency exceptions. Each emergency exception is a real cryptographic break, and the document names each one.
Nothing is removed without having first been deprecated for the length of that calendar.
Version negotiation
A client offers its maximum version in its connect frame; its minimum is a build constant on both sides. The relay selects the lower of the two ceilings and states the selection, and a selection outside the client's own range aborts the connection. The selection is signed into the challenge the client answers, so a downgrade breaks the signature.
Version 4 is current, and version 1 is still served.
Version 1 against version 2
| Change | Class |
|---|---|
The LIVE frame, tag 21, for presence and typing | Compatible |
The KEYS frame, tag 22, for MLS key packages | Compatible |
Kind 0x0022 dm.welcome | Compatible |
Kind 0x00F0 ephemeral retired to reserved, unused | Editorial, since it was never implemented |
| Nothing about the envelope |
Every row is compatible under the mechanical test above, so a version 1 client keeps working against a version 2 relay. The relay filters the two new frames on the negotiated version, so the client is never sent a frame it does not know. An unknown tag would cause a decode failure and a closed socket.
A version 2 client against a version 1 relay learns the selection from the acknowledgement and reports presence and private messaging as unavailable. Unavailable differs from everybody being offline, and the client reports unavailable.
Who maintains it
One person maintains the protocol, and the document says so. It names a second independent implementation as the trigger for changing that. From then on, the change process stops being a policy one party can revise.
The document
Governance, the change classes and the comment period are published in the conformance document set.