Aggregate open work items

[KendallWeihe]

We've been in execution mode these past couple of months, and so it's time to do a bit of project management. Use this ticket to aggregate a list of work items, whereafter, open tickets for the respective work items.

[KendallWeihe]

Epics

The two "Epics" (as in, multifaceted and overarching umbrella of work items) which need near term attention are as such:

1. A major iteration of web5-rs to bring it up to speed, because it has been left behind in recent weeks for the purposes of priorities. This work will be tracked in the web5-rs repo. However, once that work is completed, that work will need to be integrated with here. The largest priority item w/ the Web5 work, with respect to this repo (tbDEX), is usage of the actual Web5 Maven artifact inside of the tbdex-kt (that is, the bound/kt project), as opposed to the current state which is a highly constrained feature set.
2. Test vectors. We have an existing suite of test vectors, but we should conduct a comprehensive audit and seek to make improvements in lacking areas. IMO we should think of the APID and the test vector suite as the same thing, but for difference audiences, and therefore the two should live adjacent to one another.

---

TODO: consider opening an RFC for each work item?

Key: using ⭐ to highlight high priority items

From prior notes:

• Add version to debug logs
• Add debug log w/ warning during JSON deserialization w/ superfluous fields
• Handle mismatch of protocol version -- debug logs, errors, etc?
• ⭐ Use Web5 Maven artifact in tbdex-kt (dependent upon a lot of web5-rs work)
• CI/CD for crates.io
• Make use of josekit decode_header instead of esoteric create_selector function
• Add CLI
• Write README's (monorepo, and then + each subproject)

Reviewing code base:

• ⭐ Align all major & minor versions (APID = rust crate = maven artifact) (will have to start-off-of Maven artifact)
• Cross byte code calling from the tbdex byte code to the web5 byte code, as opposed to the current state which bundles both into a single tbdex byte code file
• Determine if UniFFI proc macros, instead of UDL, is a more maintainable approach; weigh the possibility of removing UniFFI altogether and building a custom FFI solution
• WASM!
• APID
  • Casing consistency (snake case, camel case)
  • JsonNode type in the Custom DSL
  • FUNCTION keyword in the Custom DSL
  • Add links to Web5 dependencies
  • Add full set of error cases; consider creating singular TbdexError enum (like in tbdex_uniffi)
• Use std lib lazy_static instead of open source crate
• ⭐ Add Windows as a build target
• Add enum Resource to rust crate
• Add Message.fromJsonString() and Resource.fromJsonString() to kt lib
• Add balances to examples/hosted-wallet-kt

[KendallWeihe]

Another one: we need to add a changelog

[KendallWeihe]

Another one: we should consider pruning the git history of the byte code files we temporarily checked in -- the primary concern is initial git clone may be substantial, use your best judgement if it's excessive then let's prune.

[KendallWeihe]

Another one: right now the Justfile assumes development on an Apple Silicon Mac, but we should add generalized OS/arch support

Edit: also we should consider moving the UniFFI.kt codegen to the pipeline or if we keep it local (relevant)

[KendallWeihe]

We need to remove the possibility of ring being introduced whatsoever (to prevent accidental usage)

[KendallWeihe]

We need to consider the use case wherein a DID Doc contains multiple PFI services

[KendallWeihe]

we should beef up the acceptance test -- like a full happy-path exchange

[KendallWeihe]

also we should try to find a way to interal-ize the entirety of the tbdex.sdk.rust code, but not in a way such that we have to edit the entirety of the UniFFI codegen'd file

[KendallWeihe]

We need doc comments

[KendallWeihe]

We need to set the MSRV to 1.70.0 like here TBD54566975/web5-rs#298 (comment)