Reputation and Voting Weight System

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.

• 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.

• 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. 

• Provide detailed documentation of the architecture, microservices, and UI design to enable future improvements and modifications. 

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”)

• 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

• Identity:
  • Explore how the outputs of microservices can be mapped to a single unique identifier (UID)

Won’t Have (Yet):

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