Database Development Guidelines for Canuckduck

1. Purpose

This document establishes best practices for database development, integration, and security within Canuckduck. It ensures that backend systems maintain strict data separation, enforce privacy protections, and prevent identity compromise while enabling seamless platform interactions.

2. Core Data Architecture Principles

  • Separation of Identity Components – Wisdom, Solidarity, and Stature must be stored in separate databases to prevent user identification linkage.
  • Minimal Data Retention – Only essential data is stored, and personally identifiable information (PII) is minimized.
  • Controlled Data Interactions – Systems can interact but only through strict API-based access with role-based permissions.
  • Zero Trust Model – Backend services authenticate and authorize every request rather than assuming trust between internal systems.
  • Encryption by Default – All stored and transmitted data must be encrypted using industry-standard protocols.

3. Data Separation: Wisdom, Solidarity, and Stature

To prevent identity compromise, Canuckduck separates user data into three isolated systems:

3.1 Wisdom (Public Contributions & Discussions)

  • Stored in a content database separate from user identity.
  • Includes discussions in Pond, issue proposals in Flightplan, and general comments.
  • Indexed by non-identifiable user keys, ensuring that discussion data cannot be linked to real identities.
  • Readable by the public, but user tracking is disallowed.

3.2 Solidarity (User Authentication & Access Control)

  • Stored in a secured authentication database.
  • Contains user credentials, login sessions, and access roles.
  • Not linked to Wisdom or Stature records in any query or backend process.
  • Access is strictly limited to authentication services only (e.g., OpenLDAP).

3.3 Stature (Geospatial & Issue Participation Data)

  • Stored in a regional issue database, separate from Wisdom and Solidarity.
  • Contains anonymized user engagement data for local governance relevance.
  • Restricted access ensures that location-based trends can be analyzed without exposing individual user locations.
  • No direct joins between Stature and Solidarity to prevent identity correlation.

4. Data Access & Interaction Rules

  • No Cross-Database Queries – Wisdom, Solidarity, and Stature databases must never be queried together.
  • APIs as the Only Interaction Layer – Data must be exchanged only through secured API endpoints, enforcing strict role-based permissions.
  • One-Way Information Flow:
    • Solidarity can authenticate users but cannot request Wisdom or Stature data.
    • Wisdom can retrieve discussion history but cannot request authentication data.
    • Stature can provide regional trends but cannot retrieve user identities.
  • Tokenized Access Controls – All user-related requests must pass through OpenLDAP token-based authentication, ensuring secure, traceable access.

5. Database Security & Compliance

  • Encryption:
    • Data at rest is encrypted using AES-256.
    • Data in transit is encrypted with TLS 1.3.
  • Access Control:
    • Only API services can interact with databases directly.
    • Direct database access is restricted to designated system administrators.
  • Logging & Auditing:
    • All data access events are logged for auditability.
    • Logs are retained for 12 months and reviewed periodically for anomalies.
  • Compliance:
    • Adheres to PIPEDA (Canada’s Privacy Law) and GDPR best practices.
    • Users can request data access and deletion under the Right to be Forgotten policies.

6. API & Data Query Guidelines

  • Read Operations:
    • Publicly available data (e.g., Wisdom) is accessed via read-only API endpoints.
    • User-related access requires authentication tokens with least-privilege access.
  • Write Operations:
    • Only allowed through verified user sessions.
    • No cross-system writes are permitted—each system updates only its own database.
  • Batch Processing & Rate Limits:
    • Large-scale queries (e.g., analytics) require asynchronous batch jobs to prevent excessive load.
    • API rate limits ensure fair use and prevent abuse.

7. Future Enhancements & Considerations

  • Federated Authentication Support – Allow integration with government or educational login systems.
  • Blockchain for Vote Integrity – Exploring the use of blockchain technology for immutable voting records in Consensus.
  • Machine Learning for Anomaly Detection – AI-driven threat detection for detecting suspicious login patterns or data access attempts.

8. Conclusion

Canuckduck’s database architecture ensures strong privacy protections, enforced data separation, and controlled interactions between systems. By following these guidelines, Canuckduck maintains user anonymity while enabling seamless engagement in governance processes.