Under the SOVRINTown banner, TK and others are working hard to bring Transparency and Honesty to Voting on IOTAs Tangle via eVoter validation using IOTA Access, where such validated eVoters also vote on and approve IOTA Smart Contracts controlling future eVoting and eGovernance management of public service budget spend and control to multi-sig wallets.
This post is a sneak peak of the SOVRINTown concept centred around the "Bingo Card" Method of Voting, that is the validated eVoter is placing issued colored coins into fields on the Bingo Card via their Browser, Mobile App, or if they have no device, do the same via a Low cost Polling Station Booth (Raspberry Pi/FPGA Combo running IOTA Hornet, summarily described at the end of this post).
The post primarily lays out for the investor and developer, the 'framework' in which SOVRINTown development and test efforts operate, hi-lighting key information in each section to help create a better understanding of the time and effort required to actually built an eVoting Solution with complete transparency and honesty to avoid future Voting Schmozzles. (Multi-Schmoozing gone way wrong.)
(like the 2020 election in the US is in, right now and, yes I spell Schmozzle with a 'c' like Schmooze ;) .)
All reader comments and ideas as usual are welcome in the common section below. :)
To Stay on Top of SOVRINTown project check into our Discord Server here
In the spirit of sharing with other Open Source types, here is how we are going about "it":
Client Requirements: Must/Should/Could (Mandatory/Optional/Nice to Have)
First we need a set of Requirements for SOVRINTown eVoting Module , so here goes... an Outline of what's up next
Targeted Goals & Stated Benefits: The SOVRINTown eVoter 'Stakeholder' Set
For the eVoter: Fast, Convenient, Secure with Privacy Protection, Fast Immediate Progress & Final Results
Mobile and Desktop Access
Polling Booth Access
For the Public Service
Observation
Summary Result Certification
Multi Sig Support (Appointed versus elected Public Servants)
For the Political Service
Observation
Reporting
For the eVoter Service Operators
From the Cloud
From the Colo
For the Legislative Branch
Smart Contract Creation
Collaborative
eVoting Epoch
Licensing: 100% Open Source Terms of Use , Modification under the BSD License
Dispute Settlement Mechanism: Common Law Only
Between Human Authors & Users, Developers, Supporters of the SOVRINTown Evoting System Code
Human Juror Decisions presiding under a Human Judge referencing Common Law Precedents in Canada
General Requirements: Those Things you just have to pay attentions to....
Operating:
Developer Experimental Network
Development Test & Release Management Platform:
Development Reference Platform- Bug Validation, NFR & CR Trials
Cloud Services (AMZ , G, Azure)
In Cloud operation of Modified PermaNodes
Cloud Access from a DC or Colo by Hornet Nodes to PermaNodes in Colo and/or Cloud
Dedicated Distributed Colo hosting: Rack Mount Linux Modified Hornet & Permanodes
Deployment Via Kubernetes or Docker using Terraform BluePrint
Node status monitoring
Node End User wwallet Access Load Balancing to Smart Contract Instances from the Public Internet
Citizen Distributed Private hosting: Virtual Linux VM Container Desktop, Server, LapTop using Modified Hornet Node
Citizen Access:
Private Devices
Polling Stations
IOTA Specific Node Form Factors:
Modified Hornet Node Hosting
Polling Station Booths
Modified PermaNode Hosting
Roll-up Reporting Nodes
Non Operating:
eVoting Requirements:
IOTA Specific:
SOCIETY2 Specific:
OpenSource Specific:
Acceptance Plan Test Cases: The Only way to Drive Development and Test Success to a Quality MVP
Now that we have Requirements, what do the Test Cases look like for each Requirements, the pass/fail metrics, which make up the Acceptance Plan?
Ok, now we have an Acceptance Plan, Now we can Write up the Use Cases which Match those Test Cases
Primary Use Cases
Secondary Use Cases
Exception Use Cases
Software Architecture- Covering all the bases...
With the Use Cases in Place, we can now start to Detail the Software Architecture, first predicated on Technology choices which best meet the general requirements around RAASSPS
Reliability
Availability
Accounting
Scalability
Security
Performance
Safety (Chain of Custody/Audit, )
Software Tools: How we work
Architectural Design : Archimate
Design Principles : TOGAF
Programming Languages:
Smart Contracts : IOTA Specific- WIP
Software as a Service Template: MEAN Micro-Services Software Architecture
Open Source Software Project Use:
IOTA Specific- TANGLE both Bee and Hornet Nodes, SecureID
SOCIETY2 Toolkit - its WIP, but SECRETS is out
SOVRINTown "Special Sauce" : Milspec C2 Chain of Custody Data and Action Logging- SF.net Sherlock
3rd Party- Non Domain Expertise which gets plugged in
Cloud Service Specific:
Maybe DO, Who Knows.. it's still early
Definitely KVM, Containers with eith K or Docker Deployment using YAML and Terraform
Development & Test Resourcing Roles: Domain Expertise and Experience, Track Record- "The Hire"
Solutions Architect
Software Architect
Service Architect
Senior Developer
Programmers
Senior Test Engineer
Test Engineers
Test Certification Services
Data Integrity/Chain of Custody
Performance
Malicious Attack Immunity
eVoter Validation Integrity
Reporting Integrity
Communications Integrity
Documentation Writer/Manager
Code Repository Manager
Design, Development and Test Methods and Processes
- Gucky "Machinery" Stuff, will cover it on another post someday
It's a journey, down a road well worth taking.
TK Over and Out
*****
