PeaceFounderBB: a static website serving as a public bulletin board and cast verification

[JanisErdmanis]

A small democratic community often faces the challenge of limited resources, particularly when it comes to hosting bulletin board data or maintaining a comprehensive website for public record access. However, a recent trend offers a practical solution with static website hosting platforms. These platforms allow the creation of a static website directly from source code stored in a git repository without the hassle of setting up and managing certificates. A popular example is GitHub Pages, which simplifies deployment using action scripts to compile websites from sources.

Integrating a GitHub workflow to compile a webpage makes it an ideal platform for hosting a bulletin board interface. This setup has a dual advantage. The GitHub repository can serve as an authentic storage space for bulletin board records. Secondly, these records are easily accessible to the public via a web interface. Continuous integration further enhances this with build scripts, ensuring the integrity and verification of the bulletin board's contents. Those interested in verifying the bulletin board's integrity independently can either fork the repository and run the action script or clone the data locally.

Additionally, the use of the Zenodo repository enriches this system. Zenodo provides excellent archival workflows and the capability to generate a DOI link. This link serves a similar purpose to dataset references in scientific research, offering a reliable and citable record.

UX Concept

The public bulletin board closely mirrors that of the admin panel, with a few key adjustments tailored for voters. On accessing the bulletin page, voters are presented with a list of proposals organised by their opening time. Selecting a proposal takes them directly to its ballot box view.

Unlike the admin panel, where votes are always visible, the voter's view is designed to uphold fairness and receipt-freeness. Voters can see all votes only after their official release. Until then, the ballotbox view displays a notification detailing when the votes will become available. Additionally, voters are provided with a verification form to ensure that each vote is cast as intended. This form must be used within a 15-minute expiration window after casting the vote.

Once the votes are released, voters can confirm their individual votes within the ballot box. They can locate their vote using either the cast index, a pseudonym alias, or a timestamp. This step is crucial for voters to verify that their vote has been accurately counted and is free from external interference, such as malware or compromised key. It also allows them to ensure their vote has not been erroneously marked as coerced or overridden with a subsequent vote.

Implementation Details

To greatly simplify the implementation of the bulletin board facade and minimise the number of HTTP requests to the server, we store the bulletin board records within the git repository alongside the HTML page sources. These records are then displayed from a generated cache. This cache simplifies the information by flattening it, removing signatures, and substituting pseudonyms with their corresponding aliases. Initially, this caching system can be pretty straightforward. Managing one cache object for each record is feasible while allowing the JavaScript to load them dynamically.

Another essential feature is the notification system alerting users when the bulletin board content becomes outdated. This is particularly crucial in two scenarios: the addition of new proposals and the release of votes that are not yet available. For the braidchain ledger, which might become outdated, a manual trigger can be initiated through an HTTP request to the server. This request would involve comparing the latest proposal index on the server with the one stored locally. However, in most cases, this synchronisation would be handled more efficiently through regularly scheduled GitHub action scripts.

On the other hand, the absence of available votes would be flagged by comparing the scheduled release date and time of the votes, as listed in the proposal, with the current time. From the server's perspective, it is critical to ensure the git repository is updated promptly with new records, whether due to recent proposals being added or votes being released. Implementing this process should be straightforward, thus guaranteeing timely updates and keeping users well-informed.

The following list of tasks needs to be done to implement a public bulletin board facade:

• Serialize Bulletin Board Records on Disk. In particular implement serialisation and deserialisation of BraidReceipt objects.

• Create a Cache Generation Code. Develop code capable of generating a cache from locally stored bulletin board records.

• Implement JavaScript for Displaying Local Records. Write JavaScript code to read local records and display them in the braid chain, ballot box, and proposal list.

• Implement Outdated BraidChain Alert List all proposals and add a code to check the latest proposal index. Add the latest proposal index to the braid chain state commit and show an error if a newer proposal exists. Create a GitHub actions script that regularly checks if the more recent proposal is available, which is recorded in the cache.

• Develop JavaScript for Vote Verification. Add functionality to verify and display votes using a unique token number provided for voters after the vote.

• Integrate JavaScript for Ballot Box View and Information Messages. Implement switching between ballot box views when votes are released and display messages when the records are unavailable in the repo.

• Create a PeaceFounderBB. A package intended to initialise the repository which contains HTML interface and action scripts for continious integration.