Forks and independent implementations

The code is released under MIT and the law texts are open to all. Forks are welcome, and so are implementations in any language. There is one request: keep differences visible.

Licence

Code and documents are under the MIT licence: you may use, modify, redistribute and sell them, keeping the licence text. The registry contract’s source is under CC0, the embedded fonts are each under SIL OFL 1.1, and third-party crates are each under their own licence, listed in the THIRD-PARTY-LICENSES.txt in every package.

An implementation of your own

The law text is self-contained: every judgment verification needs is stated in it. Write an implementation from the text in the language you choose, then validate it with the conformance suite; with zero divergences against the frozen core it is a conforming implementation, on the same footing as the one in this repository.

The more independent implementations, the sturdier the law: each one written from the text alone is one more chance to find an ambiguity in it. When you find two implementations diverging outside the corpus, open an issue.

Forking the app

Changing the interface, adding features and changing defaults all belong to the tooling layer, and you are free to do them. Please attend to three points:

Take another name

So that users can tell the two programs apart.

Take another machine folder

So that the two programs keep their key stores and data apart: on macOS and Linux, change the names ~/.zikaron-desk and ~/.zikaron-desk.d/; on Windows, change the ZIKARON folder name under %LOCALAPPDATA%. The literals to change are all registered in crates/app/family-literals.json, such as the format literals of local encrypted files, the local channel’s name, the link name “Enable the zikaron command” places, the User-Agent, the pointer file’s name, the extensions of record kits and handoff files (zkit, zkhand), the name of a handoff’s note file and the handoff list’s file name, the encrypted record package’s format mark and key schedule string (zikaron-kit-addressed, zikaron-kit-addressed/1); left unchanged, the two programs’ local channels and command-line links collide.

Stay conforming to the law

The original can read ledgers your fork writes, and your fork can read ledgers the original writes.

Changing the rules

A change to the rules has to be visible to every reader: start a new spec name and a new signing-domain literal. Signatures under the two sets of rules are then independent, and a reader sees at a glance which set an entry belongs to.

• Choose a spec name and domain literal wholly distinct from the existing ones; the literal zikaron/1 always means the present law.
• Publish your law text and core, and state the digest.
• Write ledgers under the new rules with a new key.

The registry contract

The contract is shared by everyone. Anyone can deploy the same bytes on any EVM chain that has passed the Shanghai upgrade and get the same code hash. A verifier states in its scan range which addresses it accepts; a contract you deploy and one someone else deploys stand equal before the law. ZIKARON Desk accepts the one pinned code hash alone, checking it before reading a read-only network and when the main network’s chain settings are saved, so everything in it runs on that one pinned code.

Who decides

The law

The frozen core decides. Maintainers, like everyone else, can only start a new version.

The contract

The deployed bytes decide.

This repository

The maintainers decide which pull requests to merge. When you disagree with a choice, forking is a legitimate way out.

Users’ data and keys

The users decide; the project holds source code alone.

The weight of evidence

The reader of the evidence decides.

Stating it plainly

When you present your fork or implementation, state which version of the law it conforms to, which registry contract it uses and which nodes it connects to by default. Users rely on these to judge whether records written by the two programs can verify each other.