Bisq Developer, 9 Sep 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Bisq Developer Session 09.09.2019 - How to Proceed with the API, Part 1

Description

See written agenda and minutes here:
https://github.com/bisq-network/events/issues/30

A

Okay, so welcome everyone to today's DEFCON about the API, and how do we proceed with the API I'd like to first discuss a little bit or give a bit of an overview? What the story was so far when the API had the idea of an API started and the work that has been done already, then I want to talk about some some doubts and issues and why API is still not in the end.

A

The basic project, especially we had some discussion about authentication of there- might be a bigger attack surface to bisque with the web accessible API. We had two discussion about about the dependencies and so on.

A

Then I would shortly discuss the side effects of having the API in the project in terms of testing and last but not least, and the most important and large large part of the car how to proceed with getting the API into bisque or something like this.

A

So for starters, the story so far. The initial motivation for giving an API is I, saw and beat up issues. It has been 2016. There is a bounty raised for the feature in December 2017. There is some API related stuff as well, and even there's talking about a trading pot with the API work done. I think Mike did first some work in in 2017 two parts getting the API to work, and then there is some stuff. Manfred did already that could be ported somewhere else.

A

Manfred himself did some work in January this year and Bernard started I believe it was early, 2018 working on the API and since then there have been a couple of pull requests.

A

Most of them work low have been closed. Some of them are still open, so I don't know Mike Manfred panade. Would you maybe lose some words about the history of the API and how we got here. Is there something that is interesting to all of us.

B

It's it's long time, it's long time, but there so I think in the beginning.

B

We all agree that it will be good to have an API for certainly to market-making side of of this, so it was first started as a separate project, so so will its own repository and in the beginning a lot of workarounds were needed because, as you know, the the US state and and and the data model state are quite closely tied, or at least at the time so that took some work and then I think somewhere in 2018 I started to work together with Bernhardt, and then he took over and I think correct me if I'm wrong or not, but there are still some workarounds in the code.

B

So there are yeah I. Think, apart from the doubts and issues that you have such a felicitous there's there is an extra issue in order to keep the API as small as possible. There were probably also there also needs to be some if some refactoring in the decor to make it more API, friendly and I. Think for the rest of the history, probably by now, should take over now.

C

Yeah so, like a lot of effort was put in in research of various approaches that would take and refactoring of the core I, especially the startup sequence, to solve it, we could have like to make the only the core startup without the desktop and Manfred actually did this work, because it was like too hard, at least for me to do it. But now it's done and we can easily start.

C

C

Then a lot of work went into.

C

Moving some stuff from the UI layer into the core, especially when, when we create the offer or take the trade there's, a lot of validation happening in the UI. So I think that that part is still to be done. But.

C

But for the minimal version we were ok with with the current state of the core.

D

Yeah, maybe I get a little bit of feedback from my side yeah as folks I've mentioned I have to yeah. We needed to do some refactoring I mean the basic concept in this was that when code was only used in the UI layer- and it was usually in the presentation classes there and now we have basically a second cloud with client with the API. So we moved already lot of this part to the core module to make it reusable for other applications.

D

That's mostly I would say: 90% is pure technical refactoring, it's very difficult. Some parts were more complicated, which I did mostly like this, especially the startup stuff, and so on. So from my view, I think most of the difficult work is done. There's probably still ongoing approaches to reflect the more code from their desktop module code, core and I. Think over the last half year or a year, their security aspects became more in the became yeah more clear that we had to take a lot of care.

D

One part was the authentication and so on and I think there's still it's still open discussion. How safe the current solution is? We had a few months ago we had already some discussions about this and that look we said pointed out that the current token based identification has some vulnerabilities and here's a lot of security or and cryptography background. So we should take it very serious.

D

What he's finding out there and the other part is when we assume the API could run as a pure headless version, and it also could be enabled in the desktop so that the desktop application, what you start is also accessible with the API, which is somehow useful, at least for the user, but when we would deliver our desktop application by default, we state the I, then, if we would basically open some some vulnerability surface to all bisque users, so I think when we deploy it someday, we should deploy it into different binaries.

D

One desktop like it is without any dependency to the API and one which is a neighbor which has the dependency and where is enabled, and then only a small subset of users who really want this feature, would be yeah would have this extra risk. Expulsion I think we just have to be super super careful with security, which is already quite big, and when we could would get a text in that there it could be a complete disaster for the project, so we shouldn't take this lightly at all.

D

Another big thing is that, as soon as the API is in production, with every code change, what we have to do, we have a larger set for testing and for therefore supporting this features like at the moment, there's quite a lot of stuff going on with the mediation feature, with the protection cool feature very soon we have a new trade protocol and all this efforts have to be always here. We made sure that the API is discovering this as well, so that will make everything a little bit more complicated.

D

Just want to point out that we have to be aware as soon the API is out. Life is not easier in that area, and it's a little bit the question: what's the best rather cheap, how we how we should deploy it, I mean when we merge it. The maintenance of bisque take some responsibility when there get money stolen or whatever and specially with API its automated code. There's higher risks like yeah when it depends on the button click from a user.

D

It's not so easy to to explore it like when it's some automated code and yeah. It's it's it's a little bit of difficult trade-off, so we need, we need I, think we shouldn't, even if it's already such a very frustrating process for IANA, then Mike after so long time, and it doesn't still it's not out, and so but I think we should. We shouldn't forget that we are yeah. We are taking we're dealing with high risks here and we need to have the resources to make it really proper.

D

I mean I, alternate leaf approaches like what is already in place that some people are think are using the branch from cannot and it's it's open source project. Anybody can do anyway, with whatever they want, but as long it's not merchants bisque, the bisque, maintaining us and the contributors are not exposed to the risks. Basically, when somebody is 14, bisque ends get exploited there yeah it's at our business at the end, so that might be another approach which add some flexibility.

D

When basically burnout is releasing this on its own and some people are using it and all the security risks assume he has to take. Basically when people are using his French what's already happening in some extent, I think and then there is less friction that yeah, it's always dependent on the resources on bisque that people are really able to review it, to make security, audit and everything and to get consensus that we really want to ship. This, which is frustrating I, understand completely for bein up, but on the other side, I think, Canada and Mike.

D

You have to be aware that yeah we cannot, we cannot add more risk, as bisque has already, and we are always short on resources since I mean it's getting better but yeah in the past, I was basically the only one who could really refute this code and could merge it and I'm, basically not active in bisque anymore.

D

So at the moment, I'm not sure, if actually when, when the whole great protocol and the more complex part would get merged, if at the moment, I think nobody has really the competence to to review and merge this, because nobody really knows all the details about the trade of the coal and it's a little bit a difficult situation and I would suggest to think about this solution to make a kind like a step in between where some users who really want to use the API or using this branch, it becomes a little bit more.

D

Production-Ready like it is already I mean I. Think some people are using it. Maybe you can give some update about this ballot and then yeah it's it reduces frustrations because it gets really been used and it reduces the pressure on bisque developers. I mean. If this we have a lot of very high priorities like the new trade protocol and actually there's another which I would like to mention, because I think that changes quite a lot.

D

The total risk exposure and visca mean the biggest risk in bisque, is when somebody would manage to get access to the wallets and steal the the Bitcoin from from all the bisque users who are online and to reduce this risk. The best would be that to get rid of the wallet that that sounds a little bit crazy at the moment. But it's not when you sink in context after off chain trade protocol, whether the trade is basically happening. The trade itself doesn't require it kind of anything anymore, completely off chain.

D

So you could use any external wallet like the Bitcoin core or your tracer, for sending your Bitcoin and the only part wallet related, pardon bisque, which would remain, would be data out park, and usually this yeah traders don't have so much money in bsq on their application and even that money is then mostly bonded.

D

So that's kind of like locked and much more safe in a beef stone and when we get to this to this, when we get this feature implemented, which is not completely unrealistic to get it out in the next half year, I would say then the whole risk situation for risk is much much better because they're the worst thing- and what can happen is that people are stealing your psq from your vsq wallet, but you don't have any different any more directly in bisque, so yeah I just want to give a little bit broader perspective that we are probably in them at the moment in a very vulnerable state, because we don't have enough developers, we don't have enough security audits and yeah.

D

It's me lacking a lot of stuff in many areas and we should really be terrible. Conservative out with dependency, adding any dependencies with increasing our vulnerabilities and API for sure is an area where we would increase quite a lot more abilities. So yeah, that's a little bit my point of view about the whole topic. Okay,.

B

So let's say if we, if you keep this fork off of this, for the API, the big drawback for a banana and for Mike would be that it's not much into master and based on the current policy.

B

It wouldn't be up for compensation, but we do have kind of a similar situation, not similar situation, but something that is kind of similar with the the mobile client, which also got compensated, but still on a separate repository as far as I remember, so one one way way would yes.

D

Which mobile client you recurring notification, yeah I, think on later their iOS and Android repos are. We should actually work it and have it in our control, basically about yeah I, think that was never done. Yeah.

B

So if we let's say if you're not matching, either Anna and Mike gets compensated by consensus, even if it's not merged into master or we use stuff like we discussed something in the past. We have this referral IT property, which is also available in the in the trades statistics, so if it would be hard-coded in the fourth version of bisque set to specific identifier and based on how much trading activity happiness with this referral each month, compensation could take place so.

D

Yeah actually I think that's very good. At the end, I mean this policy that own I mean it's. The broader policy is that, where you added to biscuit compensated and when there are real users using the API, even if it's not merged in disk and it's a separate project controlled by the another I think it's still valuable, to make a compensation request and to get compensated for this, and even better and I seem to measure it yeah.

D

This referral flag, where property, which we can support, already, can be used for seeing how much trade volume has really actually happened, and that would make we have the compensation request more strong. At the end, when we see you, 20% of the trade volume comes from the API and we have increased great volume, then it's completely clear. It has added value, even if it's not official disk project, basically and I, think the competition requests topic.

D

We probably should separate this and not try to yeah to make a decision which might add to really to hire vulnerability and risk in bisque, just because we we need to solve this problem that, of course, the developers who worked so long on this should get compensated someday.

B

Because if you don't match it, it will be really hard to keep up to date. Maybe we can can be moving to it like contrib package, some market. This is part of biscuits, not really yet officially part of bisque, but and it's not not filled in the default desk and you have to run a different build to get the API, but but still just a master. When we do refactorings, we move stuff around. But it's not.

D

Yeah Christoph watching it any any some anybody who is working, bisque, ok, yeah, he can always rebate back, merge back the stuff from Moscow, so it is responsibility to always keep staying. Sync, it would be actually than additional work for a maintainer and it's the responsibility. I mean when a maintainer is merging code and this code gets exploited and people are losing money. There are certain risk and would not underestimate this risk.

D

Even on the legal side, I mean you never know what people who lost money, what become very creative to try to to make your troubles and yeah at the moment.

D

That said, when the trade part is really implemented in the trade public, all I would not yeah I, don't see anybody at the moment in the current dev team, who has the competence and the skills to review it and on the level that to be really sure that this works and has no risks and I'm the only one at the moment, then we have to, unlike and I'm, not willing to take more risk like I have already and and I think the other maintain us probably also don't like to do this and you christophe room when you would be one time on thinner.

D

You also should think very carefully if you are willing to take the risk that maybe tens of millions get stolen by something what you merged and maybe overlooked, some some risk and vulnerabilities. That's we are we playing with application where a lot of money is already going through that that's a difficult situation and we understaffed.

A

Well, we are, we will always be understand to some to some update the work done well. The forty minute limit is back again. Okay, if we, if you sum up to the work done as it is, there is an API in bisque, but it is in a separate repository. I believe is this correct.

C

Yes, this is correct and the problem is that, since it is not on a fork, then core team never cares about the compatibility with the API and I've been rebasing, and that's just in this. Over and over again, it took me so much time, and this is it's completely not the way to go. I I've, because then new logic will be added into the core and it will be like too tightly coupled and nobody will take care of it so to make it like really accessible from from the API yeah and oh.

C

So you've got the core part just a second month, so I've got this minimal part or even up to creating offer. So this is rebased against, like current master and about that King offer and completing the trade. It's still not it's using some old code, because I didn't manage I didn't have time to rebase it like fifth time again, and this is going like to continue over and over again so I don't see like if we are. If we're not managing this work, then I don't see like anybody doing.

C

This I bet that anybody who would take on maintaining API on a separate branch or separate fork they're going to dump it within like a few months, because it's like impossible to people that way.

D

In any way when the API is merged into master, then this extra load of work is on every contributor, who is doing any change that they have to take care, that it also works with API and tested with API, and so on and I mean yeah. Well, it's like with any project when you are working Bitcoin and you do something extra. You have to take care with every release, at least in Bitcoin.

D

You have to merge it back and you have to adopt your work that it's still compatible and works and when it's the other way around there than the main project have to take care of this and and that's another thing, I mean we need to be sure to have.

D

Basically one owner of this codebase like you are basically the owner currently and when, when they're yeah, like with a new trait from the code with mediation in April and so on, there will be bigger changes, and this will require bigger changes in the API as well, probably also I'll from those an API code. So well, but it will be for sure some change is required.

D

So when it would be already pardon master, we had this effort for implementing the new trade protocol will have been I, don't know 10 or 20% more effort, and so that's it's a trait of anyway, that either they're every developer has additional effort and specially than the testing effort or it's an external project and then yeah you basically all the time. Of course, you have to be sure to be in sync with I, mean I, think you don't need to do it on every commit pace, but on every release phase that with every release.

D

Maybe you needed a few days to get the stuff into that. It works with the API again and when you see okay, people are still not taking care to make our code more reusable and in core. Of course, you can think that developers can say hey, please, here's a functionality which is required to be reused from API, so please don't do it in the best of module. Do it in core and I think that's just a little bit of extra communication, and it's usually it's that's, usually really not big problems.

D

I mean to have some validation in from desktop and move it to court. It's done in one minute, basically, that's usually technically, with rectangular you're moving a class, so you wear your move metric to 95 percent I would say so. I yeah I thought I agreed basically a long time. Of course we should get it into biscuit, so it's just at the moment. Yeah I said I.

D

Don't have the time to to review it and to give my OK on it, especially I'm, not very experienced with uh not on the authentication photon in that area and when somebody like pedal, if we serve raise serious concerns, I take it very serious and even if I wouldn't have known this- and it would have maybe accepted the previous solution, I would not accept it anymore. When security specialists raise concerns.

D

So it's a it's a difficult situation at the moment, because when we have five more developers and some developers can take full I have the full competence about this and it's willing to merge it fine at the moment. We are not in this situation.

A

Just just a quick interruption: Munford I myself have been I worked on the under University in the topic of data security, on the cutting edge and we with it. We did a lot of stuff and we knew things will happen before before we knew things happened before us. Snowden said it that it really did happen so I'm a security specialist too, and if you, if you say well, it might be a chance that there is a security risk. Then you get stuck. There is no no moving forward because security is always fight against windmills.

A

There is no. No winning do here. You are always behind must happen, and that's that's a that. If you, if you don't like the the risk of bisque, then we we have to shut down bisque. It's that's! It's simple as that.

D

Nothing is I, just I mean it's yeah I think we just have to be very, very careful and very conservative, and if we have Arabians way too much, there's so much or on the to-do list regarding I mean the security manager would never implement it that we are restricting the application as far as possible, ask battle of wizard to work on this and many many more things.

D

So we have such a long to-do list of stuff what we need to improve and to add more risks to a project which have already a lot of known risks and probably ten times more unknown risks is just hundred here is comfortable. In my opinion, at least I will not take the responsibility for this.

A

Yeah, of course, the topic of responsibility is there, but it is also there if you say well, we don't want to test something. We don't want to test you and it's a risk in my eyes, it's a risk as well, and we decided to start doing tests now and we maybe it should have been done years ago, but that's another topic, but the argumentation is. The argument is the same one anyhow.

A

So this is the work done there. Let's move on to the tool, adapter dots and issues, I believe one one big thing was the authentication.

A

Given the situation we have, we have my key s, want to save us something.

B

Yes, my role it's time to do tells initiative called, but my idea is that maybe maybe we should look specifically at the security other issues and try to limit the impact of them, such as for the authentication it might be. Okay, to only accept other localhost calls for the dependencies as long as the dead not included main risk it.

B

It also elements the two securities for maybe we should try to see how we can to a limit to security impact without yeah without without you are losing too much on the API sites. That's all I wanted to say.

A

Yeah, basically, that's where I wanted to go. First, I want to discuss the authentication issues and and what people think about it and how we can mitigate this stuff and then go to this to the bigger attic surface and tend to the dependencies, and that is exactly what we can we can do. We can just make an own app that uses the dependency.

D

D

The way how to do this correctly, if.

B

The desktop app could create a cow inside still s certificate, and you always have to use the client-side certificate. If you want to talk to the API.

A

B

Also have to create the server-side certificate for the NSO any, and because, because it's it's a kind side episode, every user will have to means. It will need a way to create TLS if you get from a server and if you also create them for the client. That would be pretty secure.

A

That is first of our TLS is only is it's. The common use of TLS we see in everyday web browsing is that you can make sure that you are talking to the correct web server in. In this case it would be the API. There is no authentication nothing. There is just that you can say well, yes, this is the the server I want to talk to.

B

A

Of course, the server needs a certificate and the certificate is whether it is somewhere on a public key server or it is a paid one. You have to have the certificate and have to go through a procedure to do this and to to actually to to verify if the certificate is the correct one.

A

If you, the client, a less authentication is, is on the same level as the as the password authentication. You have the connection with you have the TLS connection, it's a secure connection to have one-time tokens. There is no, you cannot replay you cannot.

A

You cannot see if you, if you cracked, the key from two years ago, you cannot decrypt current communication. That is TLS, if you, if you then to in the easiest part password authentication or do the client-side certificate thing. It's it's the same thing and you have some authorization that the client authenticates to the server- and this is this is something we can of course use.

A

The the issue is, if you, if you have let's say the situation with with the local host API only and you require TLS to be I, don't know to do to go there and then, if someone places in a malicious website linked to local host, something and tries to to exploit your API, then TLS doesn't help you. Then you have to require some authentication authorization so that the user has to do something, provide some knowledge that the API can be sure that you actually want to do stuff.

A

That is TLS keep in mind. We also have poor and I believe that the end goal is to use a tor hidden service as a service for the API, so that mobile phones, for example, can can exist, the API and toward us pretty much the same thing, except that you the same thing as TLS, except that you do not have to keep the you do not have to do two stuff with a certificate for has: has you don't have you don't have to use a directory for certificate store?

A

Has this onion address and the onion address is, is basically the fingerprint of the certificate, and so, if you, if you reach this onion address, you basically have the verification that the service is the service. You, you have, it's basically the same thing, but it doesn't help us with localhost only and authentication.

A

That is, that is the thing I would I. Would let's say what we can? We can do first of all limited to local host and well if there is no malicious website- and you are, you are good and then we must maybe add some basic authentication, a password. Something like this that you have to provide every time you want to use the API, maybe use TLS, but it's much more complicated.

B

Bitcoin core is to you just an RPC I, usually port for TRP c-axis on localhost.

A

Yes and I: don't I'm not familiar that familiar with the RPC? Is there? Is there some session thing implemented or have you do you have to provide the passwords every time.

C

D

Totally depending if you have encrypted your wallet, you need to pass with any time every time and when it's not encrypted, we shall be see when it I mean by default. It's only localhost. So when you want to have obviously enable, then you have to set it extra and I think it doesn't come with any security production. So you have to yeah.

A

D

C

Tariffs with Bitcoin you've got this cookie file, which is stored, like in one place on your hard drive and, if you're accessing it from your the node from the local host and with the standard client. Then this client, now both server and client, use the same file from the same disk location. So that's how they should yeah.

A

Is pretty much the same stuff as taught us with if you want to control your hidden service from from the command line, there's also a cookie file share cookie file, and that is basically the session and, and it is not replay safe. If you have the cookie file or if you have your that they request then replay is possible, simple, as that, but I think it's it's a it's. A nice-nice is the wrong word.

A

If Bitcoin uses this kind of authentication without the replay protection, maybe it is at first enough for for bisque as well, just just just saying I.

D

Just we have to make it very explicit that basically, we are not providing any additional security here, and people who want to use it in such circumstances have to know how what to do I think. That's we how Bitcoin is doing it. We are not providing you anything because it's difficult and it's complex and they're telling you yeah, don't enable a PC when you have money on your wallet and when you're, not exactly knowing what you're doing yeah that.

A

Is basically the way to go for almost everything, if you, if you don't, if you cannot create something that is perfectly safe and you can not create something that is specifically say if you have to create some non technical limitations, okay, so for authentication, I believe we have some stuff now we can, we can think about in the any future.

A

Is there is just something, but not yes,.

C

So currently, what we've got implemented is with. There is a password and we store sha-512 digest of this password or inside the big data directory and when user needs to sign in using this password and then they are granted session token, and then the subsequent requests are being done. With this token,.

A

Who are technologists is the session token. Is this? Is this a some kind of cookie? Is this part of the URL? You have.

C

To know you have to put it as a header, so just like you've got it with I know out, or you just include ahead.

B

C

Yeah it's safe, because if anybody is trying to send you a link or an image but points to like locos or even over tor, then your browser will not automatically include because it would include the cookie right. And so that's why I put it in the header yeah.

A

Basically, well to be exact, the if you use a cookie or a part of the URI or the header, it's basically the same thing: it's it's a request and the data is there and you send it every time.

A

The only thing that is different from from TLS, for example, for replay protection is that the server has to know yeah. Well, there is no replay detection protection, cactus.

C

Well, I think I think that in future, if we want to do a replay protection, we could all could add like GPG keys, and we could sign the body, the payload and put the signature into e to the header yeah.

A

But you have to replay it for replay protection. You have to implement something with rolling ons or something like this, because even if you sign something, then you can replay it as well. But that is another topic. We can't discuss this. If you want to.

C

Take it but apparently I think that what we've got right now is it's compatible with what we have agreed and we also have the support for tor, so the we never currently, there is a possibility to by the flag, startup parameter to specify a port or the or even the hostname, by default, so co-host we could disable this. So what users who couldn't started on non localhost with Matt I think we should give them flexibility to do that and yeah.

C

If you want to expose it over toward, then you just expose the local socket and you proxy it over tor, and that's also done right.

A

Okay, so for the attic surface, I believe we, we already had some contributions in this car. Targeting this this very point, we can just recite what we already had. We can create the separate app so that everyone, every user that uses Biscayne, starts bisque up. There is no API in a bird. If you want to use the API, you have to use a non binary, for example, I have to compile it something like this, and so there is. There is much less additional attic surface to bisque, because the API is not enabled by default.

A

We can. We can do some strengthening of more resilience for bisque, as Manfred said, we can remove the wallet, for example, and have to wallet externally somewhere.

A

D

May it hit something we stay API, we would become Ultima Wilner able by intentional and by non-intentional attacks to the peer-to-peer network. So currently, for instance, you cannot create 1 million offers, you have to click 1 million times, so nobody will do this. We state the I when some script kiddies playing around and make some mistakes and get an endless loop and here's enough Bitcoin. He could spend the network with 1 million dollars or something like this.

D

Of course we need to protect on the field of your network site anyway, against all kind of stuff in that direction, but with API enabled we get, we have. We got pretty big exposure and it becomes easier that something like this happens and I think probably more there I'm intentional, that there are some script. Kiddies are making mystics and doing some stupid things which is possible waste api and which is basically not possible in the current test of that.

D

I think that's the bigger risk, because any attacker can do it anyway with modified code, and so, but I think we yeah. We have to be aware of this as well. Yeah.

A

That's why I meant with arrays to resilience. There is another option. We can't just use a password derivation function. For example, the only cryptographic use of a password derivation function is that it takes time, that's it and if you can implement it in the API as well, if you say well create an offer, then it takes some time to create this very offer and that's where there is a limit to denial of service or proof.

D

Of work, what was the trouble is using about not familiar with this? It's.

E

D

Work that you had some proof of work for ISO deters protection. Basically, a.

A

Password derivation function was I believe it was the term yes well, if you s been out said before it's currently implemented with some standard hash, sha-256 or something like this derivation of the of the database entry sha is is created to is designed to be fast. You can use a password. Derivation function basically does the same thing, but is designed to be slow so that you cannot. It takes some time to create a result, and- and you cannot do it faster on no hardware, and that is basically a break yeah.

A

Well, it takes longer for one job to be done, and then you cannot do that many jobs in a short time.

A

Okay, so and last but not least, I believe it's the dependencies topic dependencies and I believe we already had this discussed as well. If we have, if we have the, for example, now every one of us starts the bisque desktop application.

A

If we have a bisque API application, there would be a whole other set of dependencies necessary for the API application. That is not in the desktop application. Yeah. That is a I believe it's a good separation of concerns.

A

The end there has been a discussion whether you'd want to try to create an HTTP API. It died early from scratch. Well, I believe not because you are bound to make errors and yeah is there yeah? Maybe they stopped? um Do you have any any thoughts on this and you experience building.

B

Http, if you have from scratch, without leverage yeah.

A

Or maybe more generally, building something that is already present in a well-tested library and doing it by yourself? Is it better or is it more secure? Is it less effort? Is it I, don't know, I mean.

B

I I think it's probably clear to everybody that it's not a good idea to build something from from scratch and even I. Think HTTP API is like really complex and I mean what I would do is I would maybe use the smallest library possible that works and maybe decide what features do we need, but yeah.

D

Yeah sync, with dependencies we really so first I really would suggest that we start now that no dependency get adding any more. Any dependency requires a proposal and the discussion first before anything got added and no maintainer should merge any change which adds dependencies. Removing is great updating to other versions.

D

Also, should we discuss before we do it, because we are every time we're taking some risk with this, and when we I mean, from my opinion, with API, there are a few big libraries where which are probably not so well tested, and especially not security, wise like smoker and whatever I, don't know exactly what they are doing.

D

I would have a better feeling when it would be a library like G RPC from Google I mean, of course, there can be also vulnerabilities, but I mean there are thousand times more eyes on Google library like on Thomas, More and I would I would argue against that. But Christopher don't just said. The best is to use a small API, there's a usually small project from one or two developers, which are much easier to exploit, like like a big library from Google or I, mean big library. I mean from a more trusted provider like okay,.

B

But but that's the Assumption, the bigger companies make bigger than raise and smaller teams makes more leverage. That's just not true. I mean no.

D

No right, no, no I just want to say also the the primary focus should be. Is this provider more trustworthy or less like do it? Do you trust us Walker more or do you trust, Google more for not having security for a change.

B

D

It's a big library, but I would prefer a big library from Google over a small library from a nobody sure.

A

B

Mean so basically I think for me, the HTTP library, server library that I like most is under Tao and it's from reddit and ok, it's not Bui, but it's yeah and it's it's a really like it, because it's small and it has no no dependencies. I mean Shetty. Shetty is probably also good, but it's like it's a huge labyrinth.

B

I also, don't think that there is exploited code in chappie, I mean I, don't.

A

Know I believe it's it's it's more. The topic of. Let's say you have a very big library and it's easier to overlook something big library than it is in a small library, but well it's software and we all know every piece of software is buggy.

A

It's just the chance that a small library that does exactly what you need is in the toy in there in the in the area. You need less buggy, then a really big Larry that does a hundred thousands of things at once and or perfectly safe yeah. Well, it's same old same old.

A

D

Just have to beware: we own the group to space. There are different incentives when a normal, like this exploit, wastes one notes, library which were used in one or can't remember, which exchange it was, and tickets hexton cuts down a lot.

D

A few millions and millions of other approaches used is node library and there was no incentive to hack them because there was no money, but when there is Bitcoin, applications are using this library, and there is just some small team or developer, and it was just some other people dependency which got exploited and it's the way to get in to take over the application, and that's said, I mean midterm. I.

D

Think we really should push her off in trade protocol because at the end I mean another topic, and maybe we can discuss it in in one or two weeks, but I think when there are big problems. Where are no good solutions? The best solution is to get rid of it by removing the thing like when you cannot make an application. Very lot of money sits on it safe and you never can make it safe.

D

Basic able to Bitcoin can be hacked theoretically when somebody finds an exploit and yeah, then just move it out and delegate it I mean when basic users don't have the Bitcoin I'm, basically more about on Bitcoin, core and Bitcoin. Take a look at that. It's not our responsibility anymore.

A

Yes, okay, do we have any more contributions to the doubts and issues part of today staff car.

C

Yeah, but are we going to have the summary and what we're going to do with those.

D

Ask you again what is your main concern about this idea because for me that's the most practical approach that basically you are making the API production-ready on your repository, you yeah it becomes used and so on and it's yeah it's completely out of scope of bisque. You are responsible that you're keeping track after changes and be aware that midterm, I would say half a year. We have a completely different trade protocol or maybe two applications that not decide how it will look like. But often trade protocol has nothing to do with the current rate protocol.

D

It's a completely different beast. So instead.

A

Is there there? Is there a change in the API in the corner? There I mean.

D

So it's a completely different trade protocol different system. There is no more teaching anymore and it's everything much much easier at the end, because yeah I don't want to get into the in this topic. We can have a call, maybe in one or two weeks, I said from it's very clear that we have to go in this direction, because that's the solution for many many problems for usability for speed for security for privacy. It just solve so many problems at once that it shows that it's so superior.

D

We have to go there, and so at the moment there, the current rate protocol is much more more complex because it's with the Maltese again with the blockchain conformation and everything that makes everything much harder when it's when we don't have this anymore. That will become much easier. Also, so just wanted to give you a little bit the background to keep this in mind that not in far future the current break protocol will fade out. It might coexist for a while, but it doesn't have a long-term future and not only.

E

D

Of our plans, also because of the transaction fees at some point, transaction fees will become too expensive that the current rate protocol is feasible. Yeah.

B

But that's the question: if there is enough value to keep the current API alive within the of change rate protocol is there and then it tends to be re-implemented completely or just say the value for the project to keeping something alive. They will be then just not not use useful anymore. In six months time, yeah.

D

That's a good point: I mean it's maybe too short to make an estimation. Yeah.

B

Because people, not only it, has to be maintained, but also it has to be used enough, that it creates enough value. So it's justified to keep it around until the end. I would.

D

I would like to also with trusting Carter, maybe working on this already on the conceptual side, finalize the concept and think more about it and I have not talked with him over the last day. So I don't know how if he made any progress and if he got in too deep into it, we need basically one or two dedicated developers at the moment, yeah trusting Carter was only one.

D

A

Me rephrase the question: will the the GUI to change everything.

D

Will change it? Maybe it's a completely different application, which run in parallel with a different network. It's not honest. Questions I mean they're. In short, the this option trade protocol will separate the trade with the security model at the moment. It's in one because it's the multisig it's in the trade protocol. The more disagrees basically giving you the switch the main security in the oven, tray protocol.

D

You can send euro to dollar, you don't need any Bitcoin and the security is based on peers coupons when you scan the other, your risk that you lose your bond and with that it's a little bit like with lightning. You only need to set up one time account, and then you can trade basically infinitely up to the limit of the bond and the pound is managed in the peer-to-peer network and and with the Dow.

D

But the trade protocol itself is just sending one currency and receiving another and making the confirmation and have some sort of arbitration or mediation with basic at the same like mediation, they don't have any executed and execute. If power, they only can make a suggestion that one of the peers were basically this camera and he should be confiscated and then the Dow is to execute the who will do the confiscation of the bond. So that's in shorter or with you and that then you can do the trade.

D

When you make a lightning bit country, lightning, litecoin, where the trade can be done in five seconds when both online as well. It can be automated in the code as well, so we get there completely there all the requirements, the difficult requirements. What we have at the moment that you need to wait for the blockchain confirmation and the other user need to be online and many things are gone then, so it will be a huge usability, improvement and I said.

D

The trade protocol itself will become very trivial and the complexity will be only in the management of the bond in the peer-to-peer network and in the towel. And, of course, the the risks for bisque will move much more Tudor to dead areas than the peer-to-peer network and the Tao are the critical infrastructure, because when they would not work, then nobody could trade so, but no nothing can be sewn. So that's much much better, but yeah.

D

We can discuss this, maybe in one or two weeks, because I know that nearly nobody is really aware of of it and I think we need to focus to get this done, because it's just so much better like the current stuff. What we this.

A

Would changed so? What you're saying is if it changes the application, as it is now the GUI, it would change the API, it will change. Basically everything you have in you yeah. It is not competitive. The old one.

D

That's open question to discuss it's too early to say now how we do it and integrate foes or separate it or make a transition yeah. We have not thought about this yet, but it, the trade protocol part, is a completely different thing. The rest that you have the Tao. Basically only a remaining stuff is the Tao and that you have the mediation or something all they are. The features which are related to the trade protocol and the wallet are not required anymore.

D

So yeah, it's the question how it will be deployed if it's.

D

But yeah I think with everything what we are doing now and maybe we can have a tech session in the next one or two innocence, because there are many other things. There are quite a few ideas worth taking. Nobody knows and also from priorities. There are some important priorities which are not really. People are not really aware of them and I. Think.

D

Of course people have different opinions about varieties, but at least everybody should be aware: what's what's already, which ideas are already out and which are which ideas are already there most are documented, partly at least in the proposals repository about so many proposals that nobody's reading the stuff anymore there so I think would be good to have a def call to go where all the varieties and all these ideas and projects, and together kind of like a common that everybody is on the same page.

A

But the the list of offers will be there in the future as well.

D

Yeah there will be an offer book, yeah the book and, of course, some new form of execution of the author yeah, but.

A

There is a there is an offer. Pumpkin, you can say well, I will take that offer yeah.

D

You see an offer somebody, it will be automatically check their dilation of point. You need to have enough point that you can take the offer and you get in touch with them to exchanging the other yeah. You change both okay.

A

What is it's not all different, it is, it is still do ever with an API yeah.

D

Actually, that will be Alton API thought the current API, which is tailored to the current rate protocol yeah that will have no value. Any minor infrastructure of API will have value, of course, but not the current methods like creating an offer, taking an offer waiting for the confirmations. All that will be different, Oregon and and that's yeah. That's a complex atom based I mean the whole trade protocol is not really.

A

Meeting again I'd like to restart a meeting once more one. Last time, then we talk about how to proceed with the API, so so any any any suggestions of how we, how we should we should do this.

A

What is the goal? Is the goal still to have it in in basic or not that ultimate goal? I.

D

Think long term, it's probably a cold, makes it more clear and people I mean when there would be RPC API for Bitcoin core from some search party yeah. You wouldn't probably trust it as much when it's from Bitcoin, develop and I think we at some point. We should get to the point where we can take the responsibility, but is at the moment I'm just not sure if we have the resources to complete it, I mean from my point of view.

D

I would like to have a security specialist order for the access path for their authentication and all this and and then there's somebody need to be able to review it, and then we have to be sure that we have basically code owner.

D

That banner is still then all the time doing, helping to maintain the API when it's, because there will be additional work and tests that what I think more realistic and easier, and maybe the other approach that be another, is basically keeping it in hiss and taking care that it's in and I said you can.

D

You can point out to developers who are not taking care to to make new code easier to be reused by the API I think the stuff in the core, but the main work that, like now with the mediation and with the trader chat I, don't know if that affects much the API, but the mediation will affect ap idea from change within the crate protocol. So you have to implement it anyway. Excite them and yeah.

D

You have to broaden on the developer when API would be part, I would have to add an object's Twitter to the value objects on the API side and as well so I need I need to know much more about the API need to test it. I need to maintain the code so can.

A

We somehow can we somehow strictly create a create. A strict separation of concerns. Api is nothing else, there's another form of a GUI.

A

Can we can we separate things and also if there is a new trade party corner somewhere in the future, can we can we try to to create Java API that a web application can use and a Web API can use the GUI API I can use GUI application can use without having to redefine stuffs. There is a the easiest thing is there is a method it says well create offer, and then you call the method and say well this much of this and this much of this and that's it.

A

It can't be used by it can be used by every means of API. Can we can we? Can we use that.

D

After is most of these cool methods are a Java API, which you can directly use from any and until to 80%, that's in place already a courses missing some refactoring for some validation and whatever stuff, but the core methods. All in that, when you create an offer, there is the open off the manager manager, which has some API methods. What is.

A

Is there is there I believe in the testing to F curve, but not said something about? There is some business logic still in the end, a GUI part that he had to reconstruct in the in his API is there? Is there a chance that we can remove this? This part of the business logic to core yeah.

D

That's for sure all the small stuff missing I'm, not aware if anything, critical and anything difficult is missing, but there might be small likely are some validations, some small methods which are in the create offer presentation classes and they can be reflected to move to core, but I think that's not a big challenge. I think that's what the showstopper that should be doable by any developer. Yeah.

A

But but it is something I can to and reduce to reduce the gap between the API and the core and also reduce the efforts not has to maintain if some business logic in the GUI changes he has to reconstruct it and if it's in the core that is not necessary, anymore yeah.

D

And I think that would be the best candidate because he knows exactly which stuff is still missing and I. Think the missing stuff is all I. Don't think when there is some really complicate. You can ping me that I can help that I am NOT the world thing which should be to complicate to move and.

C

When you don't have this, when nothing is forcing you to do some thing to design the solution in like stateless way, why nobody will do care about it, nobody will try to do stateless managers and I.

D

Mean that's not the big problem when I'm yeah, when people are aware that there is a second application is using this, then you yeah, you have to take care and when they don't doing, you can tell them and then the second time they will take care. So I think that should be not.

D

There was no reason to use to make something reusable when it was only one one client, basically yeah.

B

What I wanted to mention I think that's something not something that needs to be communicated to all developers who are contributing. There is something that just has to become communicated to the maintenance of the best repository, and if we do have this kind of as a much requirement, then nothing gets much that doesn't fulfill the requirements yeah, and so there won't be any communication effort on that side. I think, if that's clear, but.

C

It will make it much easier for everybody if the API code is inside the main repository and because it will break the build if.

D

It makes it on the other side much much harder for anything, any change, because you have to do the change on the API side and you have to understand the API to be able to do this. So that's a little bit the trade-off, but I mean is, for you is less work for all the other developers more work. That's.

C

Yes, but it is, it serves other developers as a guidance to keep things in certain way, keep them status and really the way that people don't have to be aware of API. They just see that their code in core is consumed in certain way, but.

D

Looks beyond that, it doesn't matter if we would agree that this is good or bad code can only be merged to bisque when it's really well reviewed and well tested and specially critical code, which is touching the trade protocol, and that is what API is doing at the end. No.

A

It does not Eddy sorry, no, it does not. If.

D

You are a wedge.

A

D

Mean that's the content where you can do automated trades and create offers at the.

A

Moment it does not.

D

A

The trade protocol yeah.

D

But it's using it I mean.

A

D

Without really properly and really proper.

A

And the bisque code by moving their business logic to the core, and then we have less of a distance, and there is easier to maintain so I believe we can agree on that. Doing these refactorings that are still missing is a way to go forward and.

B

Another thing for me: that would be a good idea to do now until we have a good idea how long the option trade protocol will take is to add this referral. I did to the existing repository just to see how many people are using and building from source the current API already, if no one is using it yeah. That's also something that we have to take into consideration how to move forward as soon as we have to know how long the object rate for the cottage and.

A

After you have any numbers.

C

I'm not aware of anyone using the API right now, because it's scattered across so many like my my fork, Mike's fork, and we had also like two versions, because bisque meanwhile was split into different modules, then implement a rifle and yeah. So we we didn't manage to keep up with with all those dangers, though I don't think that anybody is using it I'm.

B

Sorry, but could it to them just at this referral a tea or a different reality, isn't different repositories so that we just have until we have the the remaining business logic in the core. Probably already have have some numbers or we don't have any members, then that's also a finding that we are a Hanabusa sure that no one is using it at least not for real trading.

B

You know what I mean, even while.

D

That we are setting our ID when it's an almost application. No know that.

B

There is that the referral ID is set manually in the code for in the fork of this either in the API Forks.

D

Official API for work is not production, ready and I. Think nobody's using this question. I think! Yes, alright, it's it's not maintained since half years. It doesn't that's the tower, you cannot use it. Actually you get disconnected or you cannot trade at least.

B

D

Two questions: okay,.

B

So so people are using the the pull request or the producer when.

D

When people are using it, but they are not set, probably awesome nobody's using his repo, but I thought that in the past, when people were playing around with it, but another complexity like now with I mean a big complexity in discs- is always how to state backward-compatible and that sometimes very challenging.

D

When you have bigger changes like now with the mediation feature, and it would it's already very challenging to do it with only one basic application when they would be late, they are out already, it would have been even much harder and the testing effort as well testing effort is already astronomers busy. You cannot test all the case because they are nearly unlimited.

D

We say API, it would be double because if a second application with the same amount of variations and so on, I just want to point out we as soon we have two API fully in disk and that's for sure, a long-term goal. We just have to be aware. It has some costs and the costs are not considerable. They are not trivial and not small for developing for testing and the way how to deploy it. For instance, with yes, yes,.

A

But already does the stuff and he will do it then, as well so I believe the efforts for for the some four of us. It may be a bit lower, so I, don't believe the effort is a is a topic free. We can decide, we can use to decide them better to not implement the API.

A

Okay referral ID. Isn't there some Stern? Isn't there a version? Id a version field somewhere in the protocol. I believe.

D

We only use for the the trake protocol version, which hasn't changed since the last hard work. We said we could. Basically, in course everybody update to be on the same trace, but the call and only people with the same trade protocol can trade together and we don't use the deployment version, because I think the capabilities are more flexible. You are not interested if people when we now make sure 1.16 release, and maybe that has not fixed with 1.17. You don't want to have logic, to check the versions and so on with capability.

D

We know the capability, which is irrelevant starfish mediation. So we can use that data difficut, okay,.

A

ah But I created some some graph on on the monitor to he chose how many what's the percentage of which version in the offers we talked about getting this on a per application based, so that you can monitor which versions are out there and I. Believe that's a good thing, because we don't know what versions are out there and we could add to the version number, let's say suffix of a bi or something like this, and then you know well, okay, and that much API applications are out there.

D

Yes, Orion first.

E

A

We can find a picture of a picture of Friday's for.

D

Monitoring reasons we could add a version at those data which are where it makes more sense. We it's just it's also with office. You cannot add and change any data because it will break the hash. So when you get an offer from a user, it's not updated. You will reject it because with your application, you have a version field, it's not set, so it's a different hash and you will reject it. Yeah.

A

At the moment, I extract the data from the offer IDE, which has as a suffix the.

D

Only went off has been created, that's not where, yes, that doesn't mean that the user is using this version, so maybe I suppose.

A

The version of the offer, and if we do something with price notes, for example, we can maybe get more. We.

D

Can discuss this separately because I said there are other data fields where it's easier, which are not used for which are not verified, but I have like the offer is very fast, but I actually cannot change anything when we put it in other messages, then it's much easier to X values.

D

A

We can. We can add this to that today, how to proceed points that we create some metric and see how much used API gets and well. We can maybe do it for the whole bisque Network, because it's quite interesting for governing the bisque in steering bisque, so I believe that getting getting an idea how many usages such a an API, for example, has is quite a point. We can add to the to the list.

A

A

How do we, how to be what what what can we do for a slow start.

B

Quite interesting because of course, you can call.

B

Separately, but if you already have the essential method calls among close, it becomes just the wrapper around it to be in security, and it becomes a lot lighter.

B

That might be interesting. Anything.

D

That exists, I mean open off the manifest API for OpenOffice and maybe could make it facade to have it a little bit more high level dropped and I did this when I made the example with the Qi RPC for the balances, for instance, you have them a balance.

D

Facade where you only get stuff, which is interesting for the API and more low-level stuff is in other domains, but mostly I. Think we are. We shouldn't have one class API facade, which rest and 5,000 lines of code with and doing everything.

D

No, that's not a good idea to keep it in different domains that therefore the trade and for the office, and for that now you have their API methods that the main domain objects which are providing the API classes, methods I, think that's basically in place of course, as we didn't have other clients that might be ahead, there might be room for improvements and refactorings when we have really a separate client using it, and then we see okay.

D

It should be changed in that in that way, but architectural, a I think it's basically in place as I mean that perfect yeah.

A

And we have on the list that we move the remaining 100 percent.

D

We have to be careful, also I mean there in the UI. You need a lot of small stuff like formatting some string, and you want to show, for instance, how much we it is in euro and dollar and whatever and it's a question if you really want to have the same functionality in the API when you want it yet and you move it otherwise, you don't want to move this to core because it will get three months. Yes,.

A

D

A

A

Be concerned, it's its course yeah.

D

And you will have many things done differently because for the UI yeah you want to have it I mean there was some reason we have this UI presentation model classes, and so because that's what really their UI wants usually and some stuff is not want to be reused, specially validation and more business logic. But some not because we are when there's no other use case, that no no reason to move it. So their course.

E

Yeah Kim, this is exactly it's. Finally, the two classes you mentioned the open off the manager and the doll facade. It was exactly two classes I stumbled on and when, when looking around and I was thinking exactly the same thing, that the open office manager is a quite a mess and it needs some kind of higher level wrapper. But then I saw dau facade, oh okay. This pattern already exists, but if you look exactly at how the dau facade interacts from from the GUI, then it isn't the methods and don't all the business logic.

E

As you said, some things need to be handled in the in the GUI that aren't yeah I, don't know that aren't easy to be put behind the method, because the one use case flow requires multiple steps and their confirmations in between stuff another option. That I was thinking.

E

Oh we're having, instead of like facade kind of class that offers individual methods you have even smaller use case classes that can like bundle the the main entry point to use case plus possible continuations, and if you call it from the GUI, then there can be logic in between the continue raishin calls and if you call it from API, then whatever method is calling into the use case can just call all the methods in a row whatever.

E

If you don't need a some kind of confirmation and I also noticed that the presentation was in the in the core and when I saw this I was really really confused like oh, this really needs to be in the desktop, but now I understand you're moving it over to facilitate the API use case as well, but I really think that we need to be careful not to reuse too much. I, don't know. Maybe this was already talked about, but, like I, think it's really really useful to separate the model. The domain model that's happening.

E

That's used in core from from the data model that is being used to present the the things to the UI and even also from the day--if model, necessarily but potentially, that is being persisted and and broadcast on a network. I think these are. These are different things on a cube. If you bunch them together, you get a lot of coupling.

E

It's really really hard to take, because those concerns are so are so different, and if you have logic that concerns all those different things and you try to put it into one kind of object just because it handles similar data, then then you get a lot of my.

D

Yes, I mean this tower. Facade was actually a failed experiment that tried for us to have this count like file level and at the end it was just pointless delegation and it's later in the Tao development I moved back to use under domain classes directly and in the few domains, because at the end, eeeh and I never had the time to really clean it up and to get rid of the Tao facade again, because at the end it didn't make sense, and it was for me an example yeah.

D

It I mean to have this kind of like high-level yeah, it's it's nicer, but then it grows too big and it does a lot of stupid publication or it's it's. It's maybe not yeah. It's not always really easy to find the right. It's not optimal, I know, but it's also not really easy to make it a functional but its own going process. We need to improve all this and there's much Headroom. The.

E

Thing as soon as we want more than one client like the GUI and the API, you have to have some kind of high level entry point or you're testing load. What yeah explode you only want to want to have to test one entry point yeah.

D

A

Yeah well, okay, so basically, we agreed on moving stuff to the two recorded. Is that belongs to Corinth? Don't move stacks to court? It does not belong to core, and maybe we can. We can use this as a as a entry point to end-to-end testing, because I believe panel has some pretty impressive tests already for end-to-end testing. However, he uses the his API. If we have a core functionality, the decor API that we can use it without any further business logic.

A

We can do the testing with the core API and maybe can reuse the staff burnout it on testing there as well. So we can close the gap between the API and the bisque even more. This is a way to go. You think.

A

Well, I take that as a yes.

A

Here well and then.

A

Authentication I, don't know any suggestions.

C

Pretty keen you guys yeah.

A

C

Because I was speaking and I think it wasn't sending my voice okay, so you were asking. If reusing my testing approach, would people well? The API gives you the programmatic access and it it is really doing it like end-to-end right because and II.

C

If you would like, do it on the core level without any.

C

Possibility to communicate from the outside, then you would have to start, like both clients, like this, like Alice and Bob, from the same Java in machine right, I.

A

Have not thought about it in such detail.

C

Yeah, if you want to have like the separation or we've talked early on to having different clients on different docker containers, then I think you need to have API of this or other flavor, but there needs to be some possibility to steer to derive the bisque from the outside. Otherwise, you you, you just have to run it on the same machine and there's less separation. Yeah.

D

It's not possible to run Ellison pop on the same machine and I would be limiting basically to add to test functionality, but not to make a full trade and yeah.

E

If it's a docker container you just you're talking about because if it's bound to localhost, then it will be only in the container and nothing can hit it from the outside. Is that problem.

B

So I think that the issue is that when you run Alice in the container there is, there is just nothing listening. There is no API at the moment inside the of as well, so there is no. There is no way to talk to the bisque application.

E

There's no way to talk to the application and when it's running in a container.

D

Now I think it's basic. My new would like to test yeah, you make a trade and you want to check if, basically, if the stuff happened on the other application, you cannot test it. When you run Alice yeah your test can never tell you if the message arrives on Bob side and I. Think integration test would be an.

D

It is basically testing as far as I understood the full process that when you take an offer that is really taking off from get straight from both application and combines it and find out if the protocol has been executed correctly, it.

C

Is correct? Yeah, yes, exactly and those condos. Two machines are really separate, separate file systems separate networking, so they really have to connect through the seed node to meet each other. So there is the whole peer-to-peer network being tested. So this those are really end-to-end tests and I.

A

C

Yeah and the same with completely different, like data directories,.

A

Okay, then I would I would say we can how about that? We, if we, if we have this the business logic, moved and- and maybe we are successful in testing some on the core level, we can think about creating a risk API, for example, application that is not supported by by the peace community. It's just there. You can play with it but jeffer and make you small, makes more steps towards using it for trading, maybe start by just getting a list of all of us.

A

Is this feasible.

C

Yes, it is feasible, but the main problem is that, like in a guarantee you that, within like one month, the core will be completely different than it is right now, and this will be like constant chase from the API maintainer to go back to core fix stuff in core.

C

Why ended then ported back to the API, while if it would be inside the main repository, then those people who introduced the changes would now would do it in a way that would be compatible with API. I know that this is the cost, but Manfred wants to get rid of, but that puts like enormous cost on the API maintainer and you know I would have to know and whoever would maintain the API.

C

We would have to know exactly all the aspects of the of the main application of the core bits and every change, but anybody introduces we would have to be able to deal with this and probably then chase chase back, because that change would be incompatible. We would have to like do the job that somebody else was introducing to change they would they should be supposed to do that.

C

A

We, maybe just a is it, is it think about that we integrate the API as is, but only enable it in debug mode? Is there? Is there some? There is some command-line arguments, I believe where you can say: well, it's only debug mode and it's not for productive use. Can we do this? Is this? Is this a way we can? We can address.

C

Course, that's how it will work right now. Do you have too much explicitly start the application with very specific flags, and even we've got another flag that some endpoints that we consider like to risk your experimental? They are not available unless you explicitly put this enable experimental, endpoints or features yeah, but.

D

Here I want to step in, there might be people who say I, don't care I'm taking this risk, but it's not only terrorists. They are creating risks for a whole network and for the other trader, because can be that he starts a trade and he yeah. It is a issue because it was not compatible and then the other trader gets in a dispute and lose time and in the worst case money. So it's not it's a little bit more complex and, as I said, you know you you made it to the point either.

D

It's like at the current I mean there's a lot of effort on this mediation and then soon the new trade protocols. The effort would be 20%, minimum or or even higher, when we would have already API code in place. So the effort has to be done by those people and it would take longer to get this important features out and on the other side, you have the effort. Of course, when is stuff that released, you have to update it and you have to make sure that your API is understanding this and it's compatible again.

D

So effort is on either one side or the other side and of course nobody want to take that natural, but I. Think at the current level in bisque that we are super short on development. We have very important stuff what should be out as soon as possible and should have got out already long time ago.

D

Yeah from my point of priority I think it's more important that we get the new trade protocol out as soon as possible, also their option trade protocols, my planet, where they like to have the API out, where it's initially anyway, not fully featured so people cannot use it basically for trading before it's not fully featured that they can do full trades and use it for automated trading and so on. It doesn't really add value when people only can play around and can see offers that have no real value for risk and to excuses.

D

So it will become only really valuable when it's fully there and that's a that's a big effort to get there and yeah.

A

But we have to find a way to get there if you want to get there.

E

A

I proposed this to the following: we have two minutes left on this DEFCON and I'd like to conclude the DEF core. Now we have some, we had some interesting points, interesting, interesting facts. I will sum them up. The video will be available on YouTube in a few hours or days, and each of us may think about it, and maybe we can. We can find new approaches to the whole thing. We have some agreement now and I like to repeat as a creative follow-up. They've got about the API.

A

Let's say in a week's time or something like this, and then we here we can start fresh and on a new basis where we can, we can discuss the things that are left open. Is this a way to go.

C

Yeah, okay I just want to mention, but the balance of networks is not the same, and it's always far less effort to do things right up front to design it properly than to do it in a way that you have to come back and rework the thing, because you didn't consider it. You should have some kind of clients, because it's like doubling the effort and yeah. That's my that's my big okay.

A

So thanks for joining guys, I will schedule a follow-up for next week or so see you there and have a nice day. Thank.

C

You everyone thank.

E

B