Agenda for dev call 12.5.

[chimp1984]

• Update of each devs work
• Atomic crosschain swaps: Maybe better to impl. Farcaster protocol instead of trying to use their project as external model: Less complexity, less dependency on their dev team, we cannot expect they will add other chains beside XMR/BTC.
• Which namespace / project name should we use? misq or bisq2 ? I think its better to keep name space separate from current bisq to avoid unintended code re-use.
• Should we create a repo in the Bisq GH repo already or is it too early? If so who would be maintainer, reviewers?
• How to bring code bases of devs together? Keeping it separate for too long comes with risk of duplicates in utils etc... but as long its mainly poc/prototype its probably too much overhead...
• Message format, binary format in network layer. Type-Length-Value Format is considered to be used: https://github.com/lightningnetwork/lightning-rfc/blob/master/01-messaging.md#type-length-value-format
• Graph for network, how to test, how to simulate. Anyone has experience?
• Persistence model
• Testing strategies
• Which Java version to use
• Protobuf separated in each module or global (if we use PB)

[chimp1984]

Here a quick minutes from the dev call.

• Update of each devs work

• @chimp1984: Work on peer exchange, a bit stuck with network simulation and representation of graph atm.

• @jmacxx: Works on multiple wallet rpc interfaces. Looked into XMR java lib and started to look into https://bitcoindevkit.org/ / https://lightningdevkit.org/

• @ghubstan: Works on a project infrastructure for java modules and dynamic loading

• @stejbac: Works on protocol execution prototype. Trying to formulate the LN based protocol but as its a 3 party protocol and its not defined in detail yet its a bit challenging. We should keep that > 2 party protocol use case in mind for the overall architecture but maybe too early to get too deep into that concrete one yet.

• Atomic crosschain swaps: Maybe better to impl. Farcaster protocol instead of trying to use their project as external model: Less complexity, less dependency on their dev team, we cannot expect they will add other chains beside XMR/BTC.

We will consider it less complex to implement the protocol in java. Maybe the zero knowledge proof part can be used as external dependency if porting it to java is too difficult or too slow.

• Which namespace / project name should we use? misq or bisq2 ? I think its better to keep name space separate from current bisq to avoid unintended code re-use.

No clear decidion but seem we stick with misq so far as project name. Branding name will be more likely stick to Bisq.

• Should we create a repo in the Bisq GH repo already or is it too early? If so who would be maintainer, reviewers?

Too early yet.

• How to bring code bases of devs together? Keeping it separate for too long comes with risk of duplicates in utils etc... but as long its mainly poc/prototype its probably too much overhead...

Not discussed, but related to above.

• Message format, binary format in network layer. Type-Length-Value Format is considered to be used: https://github.com/lightningnetwork/lightning-rfc/blob/master/01-messaging.md#type-length-value-format

For p2p network its likely to not use protobuf, but at application level it is kept open. GRPC might be one reason to stick with PB.
We might try to use more modular structure of PB definitions to avoid one global file like in current Bisq. ghubstan will look into that.

• Graph for network, how to test, how to simulate. Anyone has experience?

No feedback.

• Persistence model

Might be a investigation project for later. Should be very lightweight and current Bisq use case is read at startup only and then only write. Some use case would require read at runtime like load on demand trade statistics and unloading it from ram afterwards. But most data is kept and needed in ram.

• Testing strategies

Delegated to other calls

• Which Java version to use

Delegated to other calls

• Protobuf separated in each module or global (if we use PB)

Answered above.

We decided to go on with the voice call format as its seems to be more productive. We move schedule to monday 17:00 CET.