Design the public API of the Aries Mobile SDK

[TimoGlastra]

Context

We want the SDK to be as easy as possible to use. This means also taking a good look at the current API of AFJ and see if we can make improvements. Especially the addition of all new protocols requires taking a good look at the API.

Example from the proposal (we definitely don't want to use this, but to get the conversation started)

TODO

• Determine what modules the public API will consist of
  • connections
  • credentials
  • proofs
  • routing
  • did
  • wallet (import/export)
  • ledger? (maybe belongs more as part of another module)
  • ...
• Design the public API for all modules
• Make sure the API is consistent across modules
• Design abstraction layer for multi-version protocols #20
  • What does this mean for the public API
• Design abstraction layer for supporting multiple attachments formats #22

[jakubkoci]

Example from the proposal (we definitely don't want to use this, but to get the conversation started)

@TimoGlastra Do you mean that we don't want to use exactly this or that we want to use something different? I kind of assumed that we maybe won't use exactly this but something like that :)

[TimoGlastra]

I mean't we don't want to use exactly this :)

This is just something we threw together really quickly for the proposal (and is largely based on the current implementation). I just don't want to take it as a starting point, preventing better or simpler API designs.

We've already made a start in #20 and #37

[jakubkoci]

Regarding my other ideas I have related to API:

• Improve agent configuration openwallet-foundation/credo-ts#486
• Agent builder
• Each part of config/step in initialization should be possible to handle directly by developer
• API by feature/role?
  • Currently, the API is defined by modules, which is good. But when I work with an agent, I usually use the agent in just one role at a given place of the codebase. Then it could be convenient to call agent.holder.acceptCredential, or, with module agent.holder.credentials.acceptCredential. This idea is based on the idea of feature-driven API rather than domain-driven API.
• JSON API
  • As a Developer, I want to use just JSON objects when I'm calling an agent's public API and not use exported classes from the framework so that I minimize dependencies to the framework in my code and don't need to understand the framework's classes structures and APIs.
  • I don't see using exported classes from the framework as a critical problem. It was just one of my initial goals to use just JSON because of simplicity, so I'm adding it here.

I also wanted to add links to other project I think can be good source of inspiration:

• GitHub - iotaledger/identity.rs
• GitHub - uport-project/veramo
• GitHub - affinityproject/affinidi-core-sdk
• GitHub - docknetwork/sdk