Web5 API Design

# Web5 API Design ## Cryptography ### Should we implement a `KeyManager` interface that can be implemented by `InMemoryKeyManager`, `AwsKeyManager`, `HsmKeyManager`, `AndroidKeyManager`, etc.? --- ### Should we implement a `OnDiskKeyManager` or `LocalKeyManager` so that its possible to develop locally without the keys being wiped every time a process restarts? --- ### Should the `Dsa.generate()` function be called `Dsa.generate_key()`? --- ### Should we call the Digital Signature Algorithms interface `Dsa` or `SignatureAlgorithm` to minimize the cognitive load for developers new to the library? --- ### Although tbDEX does not currently use any other JOSE Signing/Encryption algorithms besides Compact JWS and JWT, should we structure the library to make it easy to introduce other JWS or JWE algorithms in the future? For example, `Jws.sign()` and `Jws.verify()` are for Compact JWS. In the future we could introduce `GeneralJws.sign()` and `GeneralJws.verify()`. :::info FWIW, General JWS is used in DWNs because there can be multiple signatures, which is not supported by Compact JWS. ::: --- ### Should it be possible to export keys from a key manager? --- ### How are JWT's handled? --- ### Is there any public API for `decode()` of JWS and/or. JWT? --- ### How are JWS Header values specified when creating a JWT or JWS? --- ## DIDs ### What is the benefit to renaming `Did` to `Identifier`? Are there developer experience issues we should consider? --- ### Should we consider how to drive adoption & usage of DID DHT? **Context** While tbDEX could, in theory, use any DID method it is likely beneficial to TBD's objectives if DID DHT is widely adopted and there are many entities operating DHT gateways. In particular, TBD's objective to foster an ecosystem of consumer FinTech apps, PFIs, and other service providers that integrate and use tbDEX. If we can make it easier for developers to build apps and services using DID DHT, that should lower the barrier of entry and encourage adoption. **Hypothesis** It would be easier for developers to build apps and services using DID DHT if there were libraries available in the most widely used languages. TBD should take on the responsibility providing a "one stop shop" for developers to find a library in the language of their choosing. **Questions** 1. Should we provide these libraries in multiple languages via Rust bindings? 2. Should we maintain two sets of implementations or maintain a single Rust Core implementation plus bindings? 3. If we choose to maintain a single Rust Core implementation, should this implementation fully conform to the DID DHT specification? If yes, then we need to support [multiple key types](https://did-dht.com/registry/#key-type-index). --- ### Should the `DidWeb` implementation include the `create()` operation? **Context** It been useful to have a `create()` operation for DID Web even if you still have to host that document on a web server. The alternative is that a person needs to hand craft the DID Web document which seems like something we can easily make less cumbersome/prone to error. :::info The TBD PFI uses this to create the DID for the PFI. ::: --- ### The current design should include the `dereference` function ## Credentials ### Why doesn't the `VerifiableCredential.sign()` function take a DID? ## General ### How do we approach enabling using the Web5 Core SDK from JS runtimes including Node/Bun, Web Browser, and React Native?