[solana]: schema authorities and resolvers as CPI

[koolamusic]

The implementation for authorities and resolvers should be cross program invocation -- This would mean that the model for authorities will exist as an abstraction. An abstraction that can be backward compatible with existing standards like EAS.

Having them within the resolvers means that our attestation service would by default require a resolver for CPI and we can have ours as the fallback resolver implementation.

Our own custom resolver that implements an authority model means, we are dogfooding our own infrastructure from the get go. since we also want other developers to be able to delegate attestations or bring their own resolvers which integrate their own logic / core operations.

[koolamusic]

1. Separate Schema Registry Program

• Reusability: A standalone schema registry can be utilized by multiple programs or external services, promoting interoperability.
• Isolation: Changes to schema logic won't directly impact attestation or resolver functionalities.
• Upgradability: The registry can be updated independently without affecting other components. Considerations:

Cross-Program Interaction: Attestation and resolver programs will need to interact with the schema registry via cross-program invocations (CPIs), which should be optimized for performance.

2. Attestation and Resolver Combined into One Program with Modules

• Performance Optimization: Combining attestation and resolver logic reduces the need for CPIs between these functionalities, enhancing performance.
• Simplified Error Handling: Keeping related logic within the same program simplifies debugging and error management.
• Modularity Within the Program: Organizing attestation and resolver as separate modules maintains code clarity and separation of concerns.

Considerations: We need to ensure that the combined program doesn't become too large, which could complicate maintenance or exceed Solana's program size limits. Internal Interfaces: Clearly define interfaces between attestation and resolver modules to maintain modularity and ease future potential separations.

3. Separate Authority Program as a Custom Resolver

Treating the authority program as a custom resolver prevents circular dependencies between authority verification and attestation logic. The authority program can handle authority-specific logic and maintain its own state independently.

• Modularity and Upgradability: Allows for independent development and updates to the authority logic without impacting the main attestation program.

Considerations: Ensure that the authority program conforms to the resolver interface expected by the attestation program. We might also have to come to terms that some data may be duplicated within our Authority program to maintain independence and avoid tight coupling with other part of the attestation service. i.e "attestation & schema registry"

[koolamusic]

@pauleke65 this might interest you

[pauleke65]

@pauleke65 this might interest you

Oh, I see. Makes sense now