← Citizens Internet Portal | Log viewer | Prototype code and spec
Try the proposal flow
Walk a test proposal through the steps the CIP paper proposes in section 4.4.1: someone files it, people sign it until it has enough signatures, a comment period runs, and the proposer may amend it. Every step is written to a test log, which you can download and check again in the log viewer. This page plays every part: the operator, who keeps the log, stamps the time and signs checkpoints, and each test identity.
Read this first
This is a test, on made-up data. It is advisory: nothing on this page decides anything, and no one has to act on it.
It shows what a few made-up test identities did. Anyone can work out their keys from their names, so a signature here does not show that a real, unique person signed. Nothing here shows what any group, or the public, thinks. CIP is a research proposal, not a live voting system.
The rules are written in prototype/SPEC.md, draft v0.1. They are proposals, and they have not all been checked. The test plan says what has been checked and what has not.
Everything happens in your browser. The page makes no network requests and stores nothing: when you close or reload it, the test log is gone unless you downloaded it.
This notice follows the draft wording in docs/advisory-notice.md (v0.1), adapted for a test with no vote. It has not been reviewed.
1. Start a test log
Tiny numbers, so you can see every step in a few minutes. The paper's examples are 1,000 signatures and a comment period of 30 to 90 days (section 4.4.1). Those are an accepted starting point and may change.
2. Test clock
The clock starts with the log.
The operator stamps every entry with the time on this clock. It only moves forward, and only when you move it. Who checks the operator's clock is an open question (SPEC section 9, question 2).
3. Register test identities
Each person registers their own key before they can propose, sign or comment.
Test identities only: each key is worked out from its name, so anyone can sign as test-alice. A real system would have to check that each key belongs to one real person. That is not built (gate G5 in the test plan).
4. File a proposal
One proposal per test log. Start a new log to try again.
5. Sign, comment and amend
Sign
A signature covers one exact version of the text.
Comment
Amend
Only the proposer may amend. An amendment clears every signature, so nobody stays signed to text they did not see. Whether that is the right rule is an open question (SPEC section 9, question 1).
6. Checkpoint and download
A checkpoint is the operator's signed summary of the whole log so far. Anyone who keeps a copy can later tell if the part it covers was changed, even by the operator.
Then open the log viewer and choose the log file, and the checkpoint as the saved checkpoint if you like. The viewer checks the log again with the same rules.
Where things stand
Test data, advisory: this decides nothing, and no one has to act on it. The signers are made-up test identities, not real people, so it shows nothing about what any group thinks. Rules: prototype/SPEC.md, draft v0.1, proposals that have not all been checked.
No test log yet. Choose the settings and start one.
Test data, advisory: this decides nothing, and no one has to act on it. The signers are made-up test identities, not real people, so it shows nothing about what any group thinks. Rules: prototype/SPEC.md, draft v0.1, proposals that have not all been checked.
The log so far
No entries yet.
Illustrative prototype on test data. The page plays the operator as well as every person, so it shows how the record works, not who would run it. Before writing an entry, the operator checks the log with that entry added, using the same code as the log viewer, and refuses an entry that breaks a rule. Entry numbers start at 0, as in the spec.