Functional Requirements

Must have:

• Architecture:
  • Modular Design: Must support the integration of future microservices seamlessly.
  • Independent Microservices: Each microservice must handle its logic and data processing independently, utilizing stateless APIs wherever possible, with clear protocols for data collection, processing, and handling to ensure modularity and scalability. Allowing addition or removal without impacting others. 
  • Standardized APIs: Ensure compatibility between microservices and with other tools in the voting and reputation system through standardized input/output formats.
  • ZKP-Ready Design: The architecture must anticipate future Zero-Knowledge Proof (ZKP) integration, enabling privacy-preserving computations without revealing individual user data. The API and data structures should support cryptographic validation methods like ZKP-based attestations or Multi-Party Computation (MPC).
  • User-Controlled Data Permissions: The system must implement explicit consent mechanisms, allowing users to approve or deny the use of their data in reputation calculations for specific events.

• Microservices:
  • An initial suite of microservices (Deep Funding proposal portal, Deep Funding voting portal) that can be used to test the system and demonstrate functionality.
  • A new Blockchain Explorer Microservice. A recommendation is Flipside Crypto, as it supports SQL, which simplifies querying and data manipulation.
  • Privacy-Preserving Data Handling: The system must anonymize or pseudonymize identity mapping when integrating with WaLT or other DID solutions, ensuring minimal data exposure.

• User Interface:
  • Configuration Capabilities: Allow users to select desired microservice outputs and assign weights for reputation score calculations.
  • Results Display: Enable users to view reputation score calculations based on their configurations.
  • Blacklist Functionality: Allow users to blacklist specific users. 
  • Transparency & Auditability: The UI must allow users to track which data sources contributed to their reputation score while maintaining privacy protections.
  • Future ZKP Integration: The system must be structured in a way that allows adding ZKP-based verification without requiring a full redesign.
  • Consent Management Dashboard: A user-controlled permissions system must be implemented, allowing individuals to grant, revoke, or modify access to their data used in reputation scoring.

• Provide detailed documentation of the architecture, microservices, and UI design to enable future improvements and modifications. 
• Future ZKP Integration: The system must be structured in a way that allows adding ZKP-based verification without requiring a full redesign.

Should Have:

• Microservices:
  • Microservices that pull data from external sources for use in reputation score calculations
  • Microservices provided should enable internal configurations that allow parameters and thresholds to be adjusted
  • Microservices that can scale to allow additional service capacity as needed
  • Details of algorithms used within the microservices provided
  • Data outputs from microservices. Reputation scores display a score from 0 to 100. Other outputs, such as token balance, do not have a predefined range as a score from 0-100
  • Mechanisms for each microservice to handle errors to minimize downtime
  • Mechanisms for fault isolation between microservices to avoid system downtime

• User Interface:
  • Functionality to search through microservices provided
  • Ability to select a subset of available microservices to be used to calculate reputation scores
  • The ability for users to assign weights to selected microservices used in reputation score calculations
  • The ability for users to save configurations and weights of selected microservices with names
  • The ability for users to export outputs from the UI (JSON, CSV, PDF), with optional API access to results to support automation and integration with external systems, leveraging the solution’s multi-API architecture.

Could Have:

• Microservices:
  • Keep all algorithmic calculations at the microservice layer to simplify the middle layer (main UI).
  • Allow microservices to provide their own configuration UI for customizing outputs (e.g., setting snapshot dates, filtering data).
  • Allow users to switch seamlessly between microservice-specific UIs and the main UI for adjustments and visualizations in a user-friendly manner.
  • For more complex algorithmic calculations (e.g., requiring interactions between multiple microservice outputs), these could be implemented as a new microservice. 
  • Allow direct interaction with microservice outputs on a mathematical level, providing advanced tools to modify and combine outputs. For more expert users.
  • Define ownership and access control mechanisms for microservice outputs:
    • Specify who can access, modify, and reuse specific data.
    • Provide a unified system for managing access rights across microservices and the main UI.

• User Interface:
  • Capability to configure microservices and weights using user-provided algorithms. Allow users to view and manage the algorithms (e.g. calculations performed on data to output specific scores or values) used by microservices:
    • Display metadata describing the calculations (e.g., mathematical formulas or configurations).
    • Optionally store actual calculation code (e.g., scripts, functions) for reruns or customization.
  • Clarify how outputs from microservices can be shared across users while maintaining integrity and security (e.g., unified data access permissions).
  • Visualization tools in UI (charts, tables, etc.) within a Reporting Section for comparing results from different configurations or approaches
  • Sample data sets and test cases that were used to validate service outputs and demonstrate system compatibility (functionality required in “must haves”)
  • The deliverables should include a mockup or interactive design of the main UI screen(s)/flow to demonstrate your understanding and unique vision on the solution.

• Machine Learning Integration: 
  • Incorporating a Large Language Model (LLM) to automatically generate SQL queries for use with Flipside Crypto could be a powerful addition. This would streamline usability and reduce the complexity of crafting queries manually

Won’t Have (Yet):

• Testing to validate compatibility with a knowledge graph or database (beyond standardized API)