Agenda for dev call 17.5

[chimp1984]

• Update of all devs
• TLV vs protobuf
• Crypto libs, small footprint pubkeys. Maybe use some lib which provides what we need (hybrid encryption). https://github.com/google/tink seems to do that. Have not looked closer into it. We should also look into performance differences. Maybe native binding to Bitcoins crypto lib would make sense? But I fear native bindings comes with deployment complexity (multiple binaries, management of binaries,...).

[chimp1984]

Meeting minutes:

Update @chimp1984:
Reported whats written up here: https://github.com/chimp1984/misq/discussions/5#discussioncomment-748405
Next steps: data storage layer

Update @jmacxx:
Reported whats written up here: https://github.com/chimp1984/misq/discussions/5#discussioncomment-748405
He was focussed on BitcoinJ usage. @chimp1984 mentioned all the issues with BitcoinJ and that it might be not the prime candidate for a light wallet. Electrum should be considered as prime candidate. Research about state of Neutrino would be good as well.
Main goal is to have stucture for multiple wallets as binaries which are connected to Misq via RPC interface or the like. Wallets should provide already a interface, if not we should prefer other wallets. One wallet for one blockchain is enough, reference implementation is preferred. In case full node is too heavy a light version should be provided as well.
Often wallets combine key management and blockchain data aspects but we should keep it as separate interfaces even there is only one implementation for boths aspects (like bitcoind). Hardware wallet and mobile use case shouldbe kept in mind where that separation is required.

We likely will need a framework how to deal with loading and verifying binaries. The way how it is done with Tor might server as tamplate, but the maven based approach might not be flexible enough.

Update @ghubstan
Reported whats written up here: https://github.com/chimp1984/misq/discussions/5#discussioncomment-748273
JPMS is not feasible. Best we can do is to optimize dependency matches. @chimp1984 suggested to postpone further investigation into that topic as he does not consider it high prio at current early stage of development and many potential requirements are not clear yet (e.g. mobile, webapp).

Update @stejbac:
His current stage of development: https://github.com/stejbac/misq
Report posted on keybase: "I've added a preliminary annotation-based framework for managing a shared trade state between multiple parties, pushed to https://github.com/stejbac/misq. It's still a work in progress (and so far it just processes the annotations but doesn't do all that much with them) and I'm not certain the approach will ultimately prove fruitful. I used the annotations to mark up a shared trade state for a Lightning escrow-based protocol based on bisq-network/proposals#312 and am hoping to develop the framework so that is can auto-derive or check the validity of a given sequence of messages and actions that each party should exchange/take as part of a concrete protocol. Later, I plan to try annotating a shared trade state for the Farcaster protocol in the same way, to see if it is useful for that."

We discussed the goals and benefits of that approach. Verifiability of a protocol seems to be a main benefit. Parallel execution paths need to be supported (like in atomic swap protocols or dispute resolution paths). Not clear yet if that approach is the best way forward. Implementing a simple protocol like 2of2 MAD based Multisig might help to get a better pricture.

I hope I covered all important, otherwise feel free to add it!

Next meeting 24.5. 17:00 CET.