Dev Call "How to proceed with the API"

[freimair]

• the story so far
  • initial motivation
    • seems like a good idea back then
    • 07-2016, 12-2017, 12-2017
    • seems like a good idea now
  • work done
    • @mrosseel: 10-2017, 10-2017, 09-2018
    • @ManfredKarrer: 01-2019, 01-2019, 01-2019
    • @blabno: 05.2018, 12-2018, 01-2019, 01-2019, 02-2019, 03-2019, 06-2019, 07-2019
  • status quo
    • there is an api right now, in its own repository
    • there are 2 forks with distinct work on the API: blabno, mrosseel
    • some code has been already moved to core in order to pave the way for an HTTP API
    • there is no clean Java bisq-core API, so keeping the forks up to date is quite time consuming
• doubts and issues
  • authentication
    • localhost only is not secure, as every website can trick you on clicking on a localhost link
    • HTTP Basic authentication is what banks use with some sort of session tokens, however,
      • banks can be sued if anything goes wrong, the opensource Bisq might instead just vanish
      • EU banks have been forced to deploy 2FA to be used from mid of September 2019 onwards
    • TLS Client Certificates authenticate users just as HTTP Basic does, also does not prevent replay
  • bigger attack surface due to a web-accessible API
    • as Bisq gets successful, it raises more interest in being attacked
    • it can be done by a machine! thus, an attack might have bigger impact
    • denial of service attacks more feasible, because infrastructure is provided. Although that is nothing the API itself can be concerned with
    • denial of service attacks have to be mitigated on Bisq level (as literally everyone can get the code and attack)
    • maintainers have to take responsibility if something goes wrong - e.g. if Bisq dies
  • dependencies
    • a consensus existed on that it is most probably a bad idea to create stuff from scratch, especially with such complex stuff as http and authentication involved
    • a fruitless discussion on big library of renowned company vs. small suitable library from renowned company vs. small lib from small group. Basically, every library has errors and flaws, there is no "right", there is "more or less wrong" at most.
    • agreement on including as little libraries as possible
• side effects
  • would allow for kind of end-to-end testing, as @blabno already created such tests (Testing Bisq proposals#105)
• brainstorming on countermeasures to the issues and doubts above
  • strengthen resilience of the Bisq network
    • use KDFs to limit number of offers created in a certain timespan
  • separation of concerns
    • leave the API in its own project, just as it is now. Leave the responsibility to the developer doing the API, leave the efforts to the developer as well (NOTE: this does neither reduce the attack surface nor the chance of Bisq falling victim to a targeted attack)
    • create a separate app "bisq-api" just as "bisq-seednode" and "bisq-desktop" is
    • only allow bisq-api to use test networks
      • so we can profit from the existing tests
      • we can use the api for simulating attacks with far less effort
  • bitcoin core offers an RPC API to be used at your own risk, can (shall?) we do the same?
• compensation or "How to keep the code owners engaged"
  • compensate even if not integrated into Bisq? (similar to the mobile client notification apps)
  • compensate based on usage numbers
• how to proceed
  • there is a clear consensus, that an HTTP API is something that Bisq offers, eventually
  • however, the priority seems to stay too low (in prospect of a new trade protocol) to actually become a reality
  • is the API even used?: append "-api" to the version number for example. (the infrastructure around that is still to be build)
  • find the remainder of business logic that belongs behind the bisq-core API and clean that up - thus, maintaining becomes less effort and Bisq profits as well
  • use the testing framework, but instread of using the HTTP API, we might use one bisq-core API as device under test. No true end-to-end testing, but tests can show whether Bisqs P2P network works in certain time limits

*time is up, a followup call is scheduled: #32 *

Video

coming soon

[blabno]

If we decide to prioritize on getting the API into Bisq, it will require some core refactoring here and there. Can I count on other developers' help?
Manual testing would be needed as well.
It would be nice to have somebody review existing e2e tests to see if there are any missing scenarios.

[blabno]

What's the satisfying scope of the API? Currently I've got sufficient stuff to allow creating offers, browsing them and conducting the trade.
There is no arbitration or dao support.

[freimair]

I say keep it small and simple. Creating and taking offers is good.

[freimair]

Recording is published here:
https://youtu.be/fj34pYDD3B0