Split into two libs: client and wallet

[kirillzh]

Today the lib does two things: talks to a mint following NUT specs and manages local wallet storage and proof management.

All apps will probably want to hit the APIs in the same way, while have more flexibility over proof management, persistence, etc.

Wondering if it would make sense to split the lib into:

• client: provides stateless APIs for talking to a mint
• wallet: does wallet management for you, uses the client lib under the hood
• types: provides primitives defined in NUTs, used by client and wallet. maybe it's optional but here, otherwise client could expose those types.

During our hackweek at Block we ran an issue where we wanted more flexibility over how proofs are managed under the hood.

@thunderbiscuit, curious if you have thoughts on this?

[thunderbiscuit]

I think this is a fantastic idea on the journey to more production-quality software. The wallet being coupled with the client was always just for convenience, but really they don't belong together.

I'm concerned about over-optimization before it's actually needed however (this is still sort of a cool-but-side-project-software quality), so breaking this me.tb package into 3 libraries that all need to be maintained and published separately could be a good "in the long run" objective but is probably out of scope at the moment? (at least until the lib catches up with the spec 🤣🤣) . How do you feel about sort of "setting this up" by breaking the client away from the wallet and re-factoring the lib into different packages that would reflect this future move? Something like client, wallet, and types packages? This would help up stress-test the dependency graph between the 3 and help shape where it could go.

Let me know what you think.