Use cases for bisq2 Web API

[salokiam]

Use cases for bisq2 Web API

We are creating a web API for bisq2. This enables further use cases which enhance bisq or enable greater scenarios.
In the first run we will probably target the use case of trading bots. However I wanted to create a list to capture all ideas
of uses cases which might be interesting for a web API. Please feel free to suggest new use cases or comment existing ones.

Also let me know if you are interested in one of the use cases, so I know where we have the most interest.
Finally this is a community based project, so let me know your thoughts.

1. Trade bot, either for arbitrage or just trading on bisq. In this use case trades can be made by yoour program/script.

2. Homebanking Integrations with homebanking softwae. users could see and relate the money coming
   from bisq. Fiat payment could be transfered to the homebanking software and easily being processed
   there (without copy&paste bank accounts)

3. Bank Integration. When an sell-offer is being accepted your script could be triggered
   and checks if the payment is already received on your bank account. For SEPA this could be automated
   with libraries like Hibiscus and Revolut and Wise have a web API as well. Automated sending of funds could
   be implemented as well, but needs more security.

4. Notification. Users might get notified about Trades being completed or new chat messages arriving.
   The nofications could be on slack, matrix or any push notification service out there.

[unbeaten69]

Not sure what do you mean by "Web API" here, but I would highly recommend targeting trading bots first. Exactly the way you are suggesting it.

Even though the architecture of Bisq is completely different when compared to centralized exchanges, algorithmic trading or market making on it should still be comparable in terms of integration complexity/difficulty (with the exception of deposit handling and trade settlement maybe). But from a newcomer point of view I can say that this isn't really the case.

I tried implementing a very simple trading strategy myself, mostly as an experiment to get to know Bisq better, but even with the very nice examples here https://github.com/bisq-network/bisq-api-reference/tree/main/python-examples it seemed way too difficult compared to the current industry standards. With protobuf being the most annoying aspect of it.

I totally understand that protobuf is convenient in the P2P protocol layer as it lets you handle backwards compatibility conveniently. Having said I strongly believe that in 2024 there is just no place anymore for an API that requires its users to generate any client code, even though it may be automated by a plugin etc. The grpcio/protoc stack works by downloading a binary (!) from the Internet and then running it, which not only feels insecure but is also problematic on certain platforms and despite being automated it still forces you to use hacks like this one https://github.com/bisq-network/bisq-api-reference/blob/ed9eec152e1b8f1d76db90eb1e4b91a3e5171e0a/python-examples/generate-python-protos.sh#L20. Whereas most modern exchanges can be easily integrated with using just curl.

I mean you can tell from all of it that the project has quite a long heritage, which is great itself! But I believe that Bisq would benefit noticeably from entirely abandoning protobuf in the API layer. It will be way easier for people to build their own integrations this way.