Define Data Schema for Custom Stamps (e.g., GitHub Stamp, Allowlist Stamp)

User Story:

As the Passport team, I want to establish a flexible and standardized data schema for custom Stamps like a GitHub Stamp or Allowlist Stamp, So that we can push these Stamps on-chain and make them easily readable and usable by integrators.

Acceptance Criteria

GIVEN the need to expand the variety of Stamps available within the Passport ecosystem, WHEN defining the data schema, THEN we should ensure it supports customization, on-chain storage, and integrator readability, while maintaining consistency and security across all Stamps.

Exploration Goals

Data Schema Design: Define a flexible data schema that can accommodate various custom Stamps, such as GitHub and Allowlist Stamps, ensuring it can be standardized for on-chain storage.
On-Chain Considerations: Investigate how the data schema can be optimized for on-chain deployment, including gas efficiency and compatibility with existing blockchain standards.
Integrator Compatibility: Ensure that the schema is easily interpretable by integrators, facilitating seamless integration and use across different platforms.
Customization Flexibility: Explore how the schema can support different types of custom Stamps, allowing for easy addition of new Stamp types in the future without major schema overhauls.
Security and Privacy: Assess the security implications of pushing Stamps on-chain, particularly regarding data exposure and user privacy, and incorporate necessary safeguards into the schema.

Product & Design Links:

N/A

Tech Details:

Current Schema Review: Review existing Stamp schemas within Passport to identify gaps and areas for expansion.
Schema Components: Define the core components of the schema, such as metadata fields, verification methods, and on-chain identifiers.
Blockchain Standards: Research relevant blockchain standards (e.g., Ethereum Attestation Service, Verax) to ensure compatibility and ease of integration with existing blockchain ecosystems.
Gas Efficiency: Consider the gas costs associated with pushing Stamps on-chain and optimize the schema to minimize these costs while maintaining functionality.

Open Questions:

[ ] What are the essential metadata fields required for each type of custom Stamp (e.g., GitHub, Allowlist)?
[ ] How do we ensure that the schema remains flexible enough to support future Stamp types without major refactoring?
[ ] What are the privacy implications of pushing custom Stamp data on-chain, and how can we mitigate potential risks?
[ ] How can we ensure that integrators can easily read and utilize these Stamps once they are on-chain?

Notes/Assumptions:

Assumption: The schema needs to be backward compatible with existing Stamps to avoid breaking current implementations.
Note: Consideration should be given to the potential need for versioning the schema to accommodate future updates without disrupting existing data.

passportxyz / passport