►
Description
See written agenda and minutes here:
https://github.com/bisq-network/events/issues/32
A
To
stuff
welcome
to
another
deaf
car,
we
had
a
deaf
girl
about
the
HTTP
API
I
think
a
week
ago,
something
like
this
and
well.
It
exceeded
its
one
hour
and
30
minute
time
back
then,
and
we
decided
to
do
a
follow-up
call,
and
this
is
not
a
follow
up-
call
welcome
everyone
I'd
like
to
just
go
briefly
over
the
results
we
had
last
week,
so
that
we
can
start
doing.
A
Great
stuff
and
going
going
forward,
and
then
we
try
to
well
Christophe
seems
to
be
churning
yeah
Christophe
is
here
nice
hi
Christopher
the
story.
So
far
we
discussed
last
week.
The
story
has
been.
The
initial
motivation
has
been
that
an
ABI,
an
HTTP
API,
some
some
API
at
least
seems
like
a
good
idea
back
then,
and
there
has
been
some
work
and
some
issues
with
I
believe
bounties,
even
bounties
attached
to
them.
Yes
and
well.
Having
an
API
seems
to
be
a
good
idea.
A
Right
now
there
has
been
some
work
done
by
Mike
by
Manfred
Bernard,
starting
in
2017,
going
up
to
the
latest
pull
requests
a
nod
made
just
a
couple
of
months
ago,
which
is
still
pending.
Of
course,
the
status
quo
is
there
is
an
API
right
now
it's
in
its
own
repository.
In
fact,
there
are
maybe
more
or
less
two
AP
is.
One
is
managed
by
Bernard.
One
is
managed
by
Mike.
A
A
A
The
topic
at
hand
is
how
can
we
protect,
keep
the
ethics
surface
very
low
so
that
a
release
of
the
API
doesn't
invite
strip
kiddies
and
more
professionals
to
attack
risk
on
a
on
a
let's
say,
easier
basis,
because
some
code
is
already
there
which
they
had
to
do
by
themselves
before
the
API
has
been
released.
We
talked
about
the
HTTP
basic
authentication.
We
talked
about
perfect
forward
secrecy,
so.
A
Well,
of
course,
bisque
is
getting
successful
and
it's
more
likely
to
be
a
target
so
yeah
well
with
API.
It
can
be
done
by
a
machine
and
you
don't
have
to
click
the
GUI
anymore.
If
you
are,
if
you
are
not
really
committed
to
attacking
bisque,
if
you
are
you
of
course,
code,
your
own
stuff,
denial
of
service
is
more
feasible
because
the
infrastructure
is
already
provided
yeah.
A
Proven
libraries
can
do
it.
Yes,
then
we
had
some
some
discussion
about
countermeasures,
how
we
can
counter
the
odds
and
issues
just
mentioned.
One
big
point
is
we
have
to
strengthen
the
resilience
of
the
Pisgah
network,
not
only
api
level,
but
the
resilience
of
the
basic
network
itself,
because
even
now
someone
can
fork
to
the
physical
process
orient,
do
something
evil
with
it
and
maybe
destroy
bisque.
A
Then
we
said
well.
If
we
can
manage
some
separation
of
concerns,
it
would
be
really
nice
to
have
to
have
a
core
project,
and
then
we
can
maybe
develop
different
API
is
one
being
the
GUI,
of
course,
another
one,
maybe
being
in
the
HTTP
API,
so
that
we
can
do
this
stuff
in
separate,
maybe
separate
projects
or
someone
can
implement
some
trading,
but
let's
say
for
himself
and
use
the
basic
API
provided
to
do
this.
A
Yes,
how
we
then
already
we
have
to
we
have
to?
We
are
at
the
point
how
how
to
proceed,
and
this
is
where
we
we
started.
There
is
a
clear
consensus
that
an
HTTP
API
is
something
that
bisque
offers.
Eventually,
we
had
a
consensus
on
that.
However,
the
priority
is
still
low
and
maybe
if
we
don't
do
anything,
it
will
stay
too
low
to
actually
become
a
thing
someday.
A
Then
we
had
the
discussion
about.
Is
the
API
even
used,
so
we
decided?
Maybe
we
can
get
an
idea
how
the
risk
infrastructure
looks
like
in
terms
of
versions
out
there
and
versions
used,
and
if
we,
if
we
mark
the
API,
if
someone
uses
the
API
to
use
the
biskits
network,
then
we
can
derive
some
numbers.
A
If
the
ABI
is
even
used,
then
we
decided
to
find
a
remainder
of
the
business
logic
that
is
needed
for
proper
working
of
the
the
bisque
GUI
and
HTTP
API
together
and
move
it
to
the
core
so
that
the
API
is
to
not
have
to
do
the
checks
and
the
business
logic
that
is
still
there.
There
has
been
some
cleanup,
but
it's
maybe
it's
the
last
20%
that
needs
80
percent
of
time
to
do
to
move
to
stuff.
A
Yes,
and
last
about
the
list,
we
decided
to
use
the
testing
framework
that
Bernard
somehow
did
with
its
with
his
HTTP
API,
but
maybe
if
we
managed
to
be
successful
in
moving
business
logic
that
doesn't
belong
into
the
API,
but
it
belongs
to
core.
We
maybe
use
the
same
testing
framework,
but
don't
use
the
HTTP
API
but
use
the
core
API
to
do
actual
tests.
There
is
no
true
end-to-end
testing,
then
of
course,
but
we
can
at
least
get
some
green
lights.
A
A
We
did
some
stuff
to
prepare
to
have
an
HTTP
API,
but
we
never
got
to
the
to
the
point
where
we
at
least
have
have
an
idea
how
we
actually
integrate
user
web
api
that
someone
can
use
with
his
let's
say:
mobile
phone
and
control
the
big
application
that
is
running
at
his
home.
So
guys,
yes,
miss!
Please
go
ahead.
B
C
My
idea
was
to
expose
it
over
tor.
So,
first
of
all,
you
need
to
know
the
address
of
this
hidden
service,
but
it's
not
sufficient
at
all.
Well,
at
least
this
will
provide
the
security
when,
when
the
data
is
in,
transmit,
isn't
transit,
but
it
doesn't
secure
the
access.
So
I
would
keep
this
token
or
password
authentication.
C
C
C
B
C
B
C
Of
all,
what's
your
concern?
Do
you
do
you
want
to
out?
Do
you
know
to
make
the
server
able
to
identify
the
client,
how
to
authorize
the
client
or
the
other
way
around?
Are
you
afraid
of
some
man
in
the
middle
attack
as
a
client,
and
you
because,
like
SSL
certificates,
are
meant
to
authenticate
the
server
so
that
the
client
is
sure
who?
What
is
who
is
he
talking
to
I?
C
B
A
The
real
issue
here
is
to
keep
it
perfect
forward.
Secrecy
and
also
keep
it
from
having
the
possibility
of
replay
attacks
and
TLS
doesn't
serve,
doesn't
provide
at
least
not
every
every
there
are
cases
the
TLS
doesn't
provide
this
replay
protection.
It
does,
however,
have
the
perfect
forward
secrecy.
If
you,
if
you
have
the
right
set
of
cryptographic,
back-end.
C
C
A
With
you,
but
not
if
you
have,
if
you
manage
to
do
a
replay
attack
you
and
you
have
to
intercept,
you-
have
to
many
the
middle
tor
and
you
have
to
remain
in
the
middle
tour
before
you
actually
go
into
the
onion
network.
So
if
you
have
your
mobile
phone
up
and
running
it,
and
there
has
to
be
some
malware
on
your
mobile
phone
intercepting
requests
before
they
actually
go
into
the
tor.
B
C
D
B
So
I
think
the
ideal
use
case
would
be
if
I
can
connect
directly
to
my
Raspberry
Pi
at
home,
running
bisk
over
the
clear
net
internet
so
that
I
have
very
low
latency
connection
if
I
have
to
go
through
tor
for
every
single
API
request.
I
think
that
would
make
the
user
experience
suffer
quite
a
bit
on
the
mobile
application
side.
C
B
A
Exactly
and
I
believe
that
is
what
what
we
discussed
last
time.
We
did
not
go
into
the
into
it,
but
we
have
mentioned
to
do
something
like
Bitcoin
core
does,
with
its
RPC,
API
and
I
believe
if
we
can,
if
we
take
this
idea
and
then
combine
it
with,
maybe
the
idea
krispies
just
post
it
below
that
we
have
that
we
have
an
API,
let's
say
an
RPC
API
or
another
API.
Whatever
API
you
want,
there
is
one
HTTP
API
that
it's
only
accessible
via
tor.
There
is
a
command-line
interface.
A
There
is
RPC,
there
is
a
GUI.
There
is
stuff
like
this,
then
we
can
provide
for
their
respective
use
case,
the
best,
let's
say
the
best
security
and
privacy
features.
That
is
the
use
case
for
the
HTTP
API
would
be
maybe
to
use
your
mobile
phone
on
the
road
control,
your
risk
that
is
running
on
your
always
on
Raspberry
Pi
computer
at
home.
If
you
are
at
home,
maybe
you
can
and
you
want
to
use
it.
Why
are
you
a
mobile
phone
then?
Well,
it's
it's
the
same
use
case.
C
You
look,
but
there
is
no
difference
between
having
this
RPC
IP
I
and
client,
and
because
we
can
have
a
client
for
a
REST
API,
and
that
would
be
also
a
shout
script
that
would
be
able
to
connect
that
API.
The
problem
is
because
both
the
RPC
and
rest
clients
would
still
require
network
connection,
so
doesn't
matter
if
you
connect
to
local
hosts.
In
the
end,
you
just
connect
to
some
socket.
C
A
E
Going
further
on
Chris
beams
proposal,
I
think
so
so
if
we
look
at
all
those
things
like
the
the
GUI,
the
the
command
line
right,
HTTP,
client
I
think
it's
important
to
note
the
differences
between
them,
because
I
suppose
that
that's
a
GUI,
it
always
used
it.
The
Java
integration,
so
it
will
just
be
built
in
the
same
char
and
all
the
others
will
probably
be
be
outside
of
the
juror
I.
Think.
That's
probably
so,
I
don't
know.
If
you
agree
with
this
or
if
you
think
that
occur,
we
should
also
communicate
over
the
RPC.
E
E
E
How
to
expose
the
core
Java
cause
of
API
and
then
so
after
that,
to
have
and
eat
all
the
products,
all
the
clients
who
use
that,
but
from
a
dependency
point
of
view,
we
will
have
to
to
add
at
least
one
dependency
to
expose
the
Java,
API
and
I.
Think
the
the
discussion
should
go
around
which
dependency
to
includes
to
expose
the
Java
API
and
then
to
enable
the
other
clients
that
can
use
it.
D
D
It's
maybe
a
little
bit
different
and
a
little
bit
like
well
definitely
reduced
in
scope.
Then
some
of
what
we've
done
already
and
so
I
will
just
try
to
lay
it
out
a
little
bit
I
as
I
wrote
in
this
little
blurb
that
I
just
posted
I'm,
really
thinking
at
every
step
about
emulating
the
existing,
not
just
players
in
the
larger
Bitcoin
space
like
you,
know,
Bitcoin,
but
claim
being
LMDC
lighting,
but
the
larger
sort
of
set
of
UNIX
idioms
here
that
are
just
tried-and-true
over
decades.
D
So
the
idea
that
there's
this
you
know
application
bisk
of
exposes
that
can
be
run,
headless,
Lee,
right
and
communicated
with
as
a
daemon
there's
a
very
well
understood,
idiom
and
being
able
to
do
that
very
conveniently
via
command
line
with
a
July
that
exercises
whatever
API
is
being
exposed
is
again
just
kind
of,
like
seems
to
me,
like
the
default
thing
to
do
it's
it's
just
a
common
common
set
of
idioms
right
as
far
as
what's
getting
exposed
again.
If
we
look
at
Bitcoin
itself
right,
that
is
a
use
at
your
own
risk.
D
Api,
it's
just
JSON
RPC
under
the
hood,
so
they're
definitely
exposing
an
HTTP
endpoint
you're,
connecting
to
the
by
a
basic
off
at
the
end
of
the
day,
and
you
know,
and
just
posting
commands
with
arguments
right.
So
this
could
be
a
RESTful
API
is
could
be
JSON,
RPC
style.
It
could
be
T
RPC.
But
what
what
I've
been
having
in
mind
here,
at
least
as
a
start?
Is
this
reduced
scope?
D
Very
conservative
approach
just
like
bit
claim
that
says:
hey
here's,
an
art,
here's
an
API
that
you
can
script
Bitcoin
core
with
or
in
our
case
disk
with
you
know,
right
of
trading
bots,
you
know
set
yourself
up
with
alerts
on
new
offers.
You're
interested
in
I
mean
we
have
the
mobile
app
for
that.
But
you
get
my
idea
and
I'm
thinking
of
a
code
that
runs
on
local
host.
D
All-Dancing
completes,
HTTP
api
over
clear
net
or
tour,
but
like
a
fully
fleshed
mobile
app,
would
be
able
to
emulate
that
all
the
GUI
functionality
of
this
proper
with
I
don't
think
it
excludes
that
possibility,
but
I
think
it
can
help
us
get
off
the
ground
by
you
know,
as
I
mentioned,
and
that
blurred
like
really
just
implementing
one
or
two
use
cases
in
the
first
release,
like
here's
get
balanced
I
just
see
how
much
you
know.
Funds
are
in
you're,
disqualified.
D
D
Do
it
just
like
Bitcoin
does
and
say
this
is
by
defaulting
on
the
RPC
allow
IP
parameter
here.
It's
a
Bitcoin
D
is
by
default.
Local
owes
one
seven
zero
one.
You
can
set
that
to
some
other
IP,
but
they're
strongly
communicating.
This
is
not
for
the
public
Internet.
You
can
give
it
a
cider,
you
know
so
it's
some
range
of
IPs,
but
it's
not
like
you
know,
connect
your
local
coffee,
shop,
unsecured,
Wi-Fi
and
and
communicate.
D
You
know
completely
with
your
bist
node
or
your
Bitcoin
node.
They
never
intended
to
be
that
way
and
it's
been
possible
to
keep
things
pretty
simple
and
pretty
lightweight
I.
Think
in
bitcoins
our
PC
API.
That
way
so
they're
definitely
dependent
on
some
libraries.
They
didn't
implement
HTTP
themselves,
they're
using
I,
don't
know
boost
or
whatever
right
to
to
do.
You
know
they
should
HTTP
stuff
and
I.
Don't
know
if
they're,
also
using
a
JSON
library
I
think
they
are.
D
You
know,
there's
there's
compact
JSON
libraries
out
there
for
Java
that
know
under
the
hood
depend
on
either
java's
own
HTTP
API
or
you
know
like
squares,
which
okay
HTTP,
these
are
like
minimal.
You
know.
Dependency
is
really
reasonable
dependencies,
but
it's,
but
it's
a
bit
of
a
different
at
least
initial
vision,
for
what
the
API
even
was
for
the
set
of
use
cases
that
it's
for
and
and
I
guess.
D
A
D
D
I
meant
to
address
that
thanks
for
asking
so
so
yeah
the
idea-
and
you
know,
I'm
totally
open
to
whatever
counter
feedback
here
or
something
like
that.
I
mean
maybe
I'm
missing
something,
but
but
to
me
the
default
time
today
would
be
leave
the
GUI
exactly
as
it
is.
This
may
be
some
necessary
factoring
along
the
way,
but
leave
the
GUI
as
it
is
talking
to
the
core.
Java
API
is
clean,
those
up
a
little
bit
as
necessary.
Whatever
I
know,
that's
always
what
what
Madrid
intended
right
that
you
know
like.
D
Basically,
why
introduce
an
indirection
from
the
GUI
to
the
core
Java
guys
when
it's
all
sitting
there
in
Java?
And
can
you
know
perfectly
fine?
You
know
just
programmatically
call
the
Java
API
is
so
that
that
would
be
the
answer
to
that
question
from
my
perspective
and
then
also
what
Mike
was
mentioning
that
did
anything
you
know
HTTP
wise
would
be
implemented,
probably
outside
of
this
proper.
What
I'm
suggesting
is
that
this
is
most
minimal.
You
know.
D
Kind
of
API
approach
would
be
implemented
in
disk,
so
it's
just
all
there
out
of
the
box
exactly
like
Bitcoin
and
the
rest.
You
know
you
can
just
run
this
quick,
Dean
and
I
run
the
Biscay
binary
right
and
that's
you
know,
demons
by
default
and
voila.
You
know
you
can
programmatically
interact
with
this,
but
probably
from
localhost
or
from
a
very
specific
IP
address.
A
The
answer-
thank
you.
We
discussed
last
time
that
maybe
making
the
API
only
available
to
local
host
is
not
secure
enough
because
yeah.
Well,
if
you
browse
a
website,
it
can
maybe
trick
here
to
click
on
a
link
that
says
local
or
something.
So
there
has
to
be
maybe
some
additional
security
in
there
I'm
not
sure
this
is
there.
Is
there
you
have
some
yadi.
D
I
mean
we
would
still
do
all
right.
You
still
have
like
Bitcoin
as
your
excuse.
Emergency
pants
were
the
RPC
cookie
file
approach.
So
you
know
you
couldn't
just
I,
don't
know
throw
together.
You
know
like
if
it's
for
Jason
I
can
see
right.
Everything's
opposed
anyway,
so,
like
links
aren't
going
to
be
able
to
do
anything
since
those
always
get,
but
network
III
together,
form
that's
going
to
post.
You
know
something
very
you
know,
spend
all
your
money
or
whatever
you'd
still
have
to,
and
to
do
that
and.
A
D
Well
again,
I'm
just
defaulting
to
if
it's
good
enough
for
a
Bitcoin
proper,
it's
good
enough
for
us.
You
know
it
it
when
everything
is
so
couched
in
the
caveat,
this
is
not
for
the
public
Internet
things
become
easier
in
that
way
right,
but
you
know
they're
they're
doing
basic
off.
It
seems
to
be
just
fine.
There's
no
giant
exploits
that
I've
heard
of
for
bitcoins
RPC
again.
D
Why
not?
Why
not
start
there
right
and
then
see?
What's
see,
what's
required
and
be
very
careful
before
we
start?
Actually,
you
know
mutating
stuffing
this.
You
know.
Maybe
it's
I
guess
placing
an
offer
is
already
you're
changing
things,
but
but
this
coins,
API,
you
know,
allows
you
to
to
put
together
a
transaction
and
broadcast
it,
and
you
know,
sign
transactions
and
spend
your
money
right.
So
it
doesn't
seem
crazy
to
me
that
we
would
follow
suit.
There.
D
D
So
basically,
if
it's
all
running
on
localhost
it
climb
the
generates
this
RPC
cookie
file,
which
is
just
a
username
in
the
password
colon
delimited
in
an
unknown
location,
and
so,
if
you're
running
Bitcoin
CLI
on
the
same
machine,
Bitcoin
CLI
assumes
that
RPC
cookie
file,
location
and
just
reads
using
and
password
which
are
randomly
generated
right
and
then
send
it
along
to
the
server.
So
it's
all
very,
very
convenient.
But
if
you
were
in
fact
you
know
remotely
accessing
it.
A
A
So
maybe
to
sum
this
up
there,
please
please
respond
if
there's
something
wrong
with
it.
Just
summing
this
up,
if
we
create,
if
we,
if
we
creates
an
API,
an
HTTP
API
that
runs
on
localhost,
it
requires
username
and
password,
and
we
only
for
starters,
create
the
functionality
of
getting
an
offer
book.
Something
like
this,
so
we
have
it
in
bisque
and
we
can
see
how
it
is
used
and
how
we
can
manage
it.
If
you
decide
to
start
up
fire
up
tor
a
tor,
hidden
service
for
your
api,
then
there
is
basically
nothing
different.
A
You
still
have
to
use
authenticate
using
username
and
password.
You
can
use
it
from
your
mobile
phone
and
you
are
able
to
get
an
alpha
book
and
that's
it.
For
starters,
we
don't
have
any
security
risk
by
only
creating
the
of
a
book
functionality.
There
is
no
risk
that
some
attacker
can
script
a
trait
of
denial
of
service
attacks,
something
like
this
to
flood
the
network.
Something
like
this.
We
just
get
the
offer
book
and
that's
it
is
that
a
way
to
go
Mike?
Yes,
please!
Yes,.
E
I
think
that's
everything
did
correct,
but
I
think
that
we
had
the
big
well.
There
is
one
big
thing
that
we
have
to
resolve
and
that's
that
this
is
one,
namely
what
will
the
maintainer
merge,
Oswin
to
bisque
cook,
core
and
I'm,
noticing
that
the
HTTP
API
it
keeps
whoo
everything
that
c-beams
bombs
to
have
an
API?
That's
not
completely
correct,
but
it
also
brings
with
it.
The
palaces
that
we've
seen
at
me
are
not
really
happy
to
merge.
E
It
will
be
just
one
of
the
clients,
just
as
the
CLI
will
be
a
client,
I'm,
young,
so
and
so
mana.
So
but
I
think.
The
point
that
we
have
to
discuss
now
so
now
is
which
dependencies
are
appropriate,
merge
into
basic
core
and
and
if
it's
not
the
HTTP
API
dependencies
as
they
are
made
by
an
art
and
okay,
we
have
to
to
say
that
upfront
them.
A
Yes
agreed,
however,
to
sum
this
up:
do
you
guys
all
agree
that
we
start
with
having
the
offer
book
available
via
an
API
and
that's
it,
and
we
used
HTTP
basic
authentication,
so
username
and
password
for
starters,
so
that
we
can
agree
on
this
basic
set
the
functionality
and
for
the
next
step
we
see
how
we
can
make
that
happen?
Are
you
guys
do
you
guys
agree
with
with
this
functionality
to
make
a
first
step
to
actually
provide
some
API
for
bisque.
A
The
question
was:
if
everyone
is
okay
with
having
this
small
set
of
features,
namely
you
create,
you
can
get
an
offer
book
via
the
API
and
use
username
and
password
authentication
to
authenticate
against
your
installation,
and
that
is
the
basic.
That
is
the
set
of
features
we
want
for
the
first
API
to
be
merged
in
into
into
bisque,
and
that's
it
can
we
agree
on
on
this
future.
D
It
sounds
great
to
me,
I'm
not
sure
it
addresses
what
Michael
is
talking
about,
though,
and
which
is
really
relevant.
I
mean
whether
to
bring
in
these
dependencies-
and
you
know,
I
it's
out
of
my
mind
right
now,
exactly
what
those
dependencies
are
and
so
on,
but
sort
of
how
heavyweight
or
lightweight
the
thing
is,
and
so
on.
Definitely
matters
and
I'm
I'm
hesitant
to
just
kind
of
drop
suggestions
like
this
because
you
know
I
haven't
I,
haven't
been
participating
in
the
work
I
haven't
developed.
A
lot
of
work
has
gone
to
this
stuff.
D
D
What
our
sort
of
general
plan
is
that
we
don't
intend
to
have
this
in
all-singing,
all-dancing,
public,
internet
kind
of
API,
yes
at
least,
and
then
and
then
you
know,
get
that
feedback
right
actually
get
our
hands
dirty
with
that,
and
then
have
this
conversation
about
okay,
should
we
take
the
existing
stuff?
You
know
Bernard's
implementation,
Mike's
implementation,
all
dependencies
reduce
the
dependencies
whatever
it
is,
I
just
think
we
might
be
able
to
defer
that
decision
and
set
of
changes.
Mike,
honest
component
just
by
implementing
that
one
or
two
use
cases
from
scratch.
C
C
So
unless
there
is
some
other
library,
but
I
don't
know,
but
I
was
concerning
the
GRP
see
as
being
developed
by
Google
unless
there
is
any
other
library
that
would
be
small,
basically
in
number
of
artifacts
and
repose,
and
the
repositories
with
those
artifacts
are
built
from
because
I
think
that
would
be
our
main
concern.
But
we
will
have
dependencies
that
way
or
in
another.
D
Yeah
agreed
I'm,
not
sure
I
realized
that
you'd
implemented
those
bits
with
GRP
seen
so
I
I
think
I
think
personally,
the
very
simplest
thing
that
could
be
done
and
it
follows
suit.
With
you
know,
Bitcoin
and
Cohn
this
json-rpc
very
simple:
to
implement
lots
of
implementations
out
there.
It's
got
to
have
some
HTTP
implementation
underneath
it
clients,
implementation,
I've
done
some
research
on
that,
but
I'd
have
to
spin
it
back
up
and
see.
D
You
see
what
the
very
simplest
lightest
weight,
most
reliable,
trustworthy
sort
of
thing
is:
I
mean
I'm,
trying
to
defer
the
hard
decisions
in
this
approach
in
like
one
such
decision
I,
you
know,
I
was
the
one
advocating
GIP
see
a
way
back
right,
so
I'm
super
open
to
that.
But
I
just
I,
don't
know
what
it's
hard
for
me
to
like
predict.
What's
actually
gonna
serve
us
best
right?
Is
it
a
restful
api?
Is
it
a
G,
RPC
API?
Is
it
just
JSON
RPC,
you
know
cuz
the
G
RPC
promise
is
great
right.
D
You
know
just
generate
in
any
language
the
bindings
that
you
want
and
it's
all
just
there
and
it
all
just
works
right,
but
people
do
have
to
deal
with
generating
those
bindings
right
and
very
often
you
know
they
just
want
to
just
want
to
hack
on
some
JSON
I.
Don't
know
what
people
are
gonna
be
I,
don't
know
what
our
audience
is
like
here
right.
So
if
we
could
defer
that
a
little
bit,
you
know
making
that
kind
of
final
decision
and
really
building
everything
out.
C
They
are
dependent
on
this
decision,
not
sure
if
you
wants
to
go
ERP,
CEO
Jason,
but
this
way
or
another
I
see
that
the
direct
is
depends.
Yes,
they
are
small
about
transitive.
They
are
still
many
and
that's
because
those
really
well-funded
libraries
are
very
modular
eyes
and
they
use
other
well-known
libraries
to
not
to
repeat
the
code.
A
Because
what
I'm
thinking
is,
we
can
never
be
sure
of
any
library
to
be
perfect
and
there
will
be
no
perfect
library,
but
we
have
to
find
somehow
we
need
to
get
there
if
we,
if
you
trust
the
library
or,
if
you
trust
in
them
or
not,
and
if
we
do
not
trust
Allah,
we
can't
use
it.
However,
if
you,
if
we
don't
trust
any
library,
we
don't
have
Pisgah
anymore,
so
they
have
to
be.
There
has
to
be
some
middle
ground.
E
We
just
have
to
find
the
concept
consensus
on
which
dependency
people
to
merge
in
core.
So
maybe
we
have
to
present
alternatives
for
json-rpc
for
a
TR
pc
and
maybe
something
else
yeah.
Of
course
you
can
also
build
just
to
soak
it
and
then
talk
through
to
refer
to
it
like
we
do
with
the
peer-to-peer
network,
but
maybe
then
the
that
becomes
too
much
of
an
engineering
effort
again.
So
no.
C
E
Another
issue,
but
yet
there
also,
as
Chris
said,
we
don't
know
the
audience,
it's
possible
that
consume
core
correctly
I
directly
or
it's
possible.
That
y'all
could
go
to
the
this.
The
CLI
and
the
HTTP,
as
is
provided
by
a
bisque,
but
that's
to
be
seen.
But
my
my
point
is:
maybe
we
should
just
released
a
few
dependency
alternatives
and
then
and
then
just
to
ask
the
question
to
the
tool
to
the
maintainer
and
to
everyone
which
of
these
two
are
acceptable
or
the
most
acceptable
to
add
to
core.
A
A
D
Yeah
the
way
does
the
way
those
all
work
is
they're,
just
they're,
ultimately,
shell
scripts,
that
are
generated
by
Gradle
that
cobble
together
the
class
path
necessary
to
run
things
which
is
the
same
for
everyone
right,
bisque
seed,
node,
miss
desktop.
These
are
all
you
know
coming
from
core
and
they
all
have
the
exact
same
class
by
a
set
of
jars
on
the
classpath.
The
only
thing
that's
really
different
between
any
of
them
is
the
main
class.
D
D
We'd,
probably
have
you
know
the
HTTP,
while
we
certainly
have
the
HTTP
libraries
that
spring
brings
I
mean
if
it's
you
know,
kind
of
rest,
support
and
so
on
already
in
the
class,
but
we
have
a
lot
of
stuff
on
bisques
class
class
path
and
I'm
not
I
mean
to
me
it's
not
the
biggest
concern
right
like
it's
a
concern,
and
we
should,
from
this
point
forward,
always
be
skeptical
about
adding
new
stuff
right
totally
agreed
about
that.
But
you
know
what
matters
the
most
is
to
me
at
least.
Is
you
know?
D
Is
this
going
to
serve
the
need
of
the
users
here?
Is
it
lightweight
in
the
sense
not
necessarily
of
the
dependencies
of
the
dads,
though
that's
important
but
lightweight
in
the
sense
of
can
people
get
in
here
and
make
changes
and
understand
this
and
so
on?
If
I
did
it
again,
today,
I
probably
would
not
introduce
spring
for
the
price
node,
not
because
it
doesn't
work.
What
works
very
well
right,
but
if
you
look
all
through
the
rest
of
this,
you
know
bisque
is
not
an
enterprise
java
application,
it's
very
different.
D
Obviously
am
you
know
you
want
to
ask
like
what
are
the
kind
of
set
of
expectations
norms
idioms,
that
people
are
following
in
the
rest
of
the
codebase
and
for
me,
that's
the
concern
when
I
think
about
heavyweight,
and
so
on
is
like
what
frameworks
are
being
introduced.
How
much
overhead
is
there
and
just
understanding
how
this
damn
thing
works
and
when
we
talk
about
something
like
JSON
RPC?
It's
you
know,
even
if
you
know
nothing
about
JSON
RPC,
you
go
read
a
one-page
website
and
you
get
it
right.
Json,
RPC,
org!
D
So
you
know
this
is
like
super
minimal
overhead,
and
my
you
know
the
idea
of
hopefully
is
that
we're
really
attracting
contribution,
I
think
I,
think
people
contributing
to
the
API
if
we
can
set
it
out
if
we
can
set
out
the
set
of
patterns
right
that
you
know
like
this
is
how
you
add
a
new
command.
This
is
you
know
the
set
of
things
that
typically
change
when
a
new
call
is
introduced
or
a
call
has
changed.
D
That's
the
kind
of
thing:
that's
like
really
fun
for
people
to
come
along
and
propose
a
new
change
and
implement
that
call,
and
you
know,
just
see
the
fruits
of
their
work,
and
you
know
maybe
we
can
actually
spread
out
this
effort
a
little
bit
right.
So
I'm
thinking
a
lot
here
about
the
sort
of
usability
or
develop
ability,
I
guess
of
the
whole
thing
you
know
when
you're,
when
you're
close
team
building
an
enterprise
app,
you
can
make
all
these
decisions
about
frameworks,
and
you
know
the
way
things
are
done
and
just
tell
everybody.
D
This
is
the
way
it
is
learn
it
right
go
to
a
training
or
whatever,
and
here
we
want
to
be
like
you
know
in
my
book,
much
more
it
just
kind
of
lets
make
things
obvious
how
stuff
works,
and
you
know
stuff,
that's
already
widely
understood
and
not
necessarily
assuming
a
kind
of
enterprise
background
and
so
on.
So.
C
D
C
D
Yeah
so
good
points
right
and
thanks
for
the
correction,
and
so
that
would
be
viable.
That
would
be
a
viable
solution
if
the
problem,
the
principal
problem
that
we're
trying
to
solve,
is
just
not
adding
more
dependencies
like
if
we're
actually
comfortable
with
the
dependencies
and
they're,
no
reliable
libraries
and
stuff
like
that
like
and
it's
them
and
it's
otherwise
the
right
solution
like
it,
you
know
satisfies
users
needs
which
we
don't
necessarily
know
what
they
are
yet
and
it
and
it
for
me.
D
One
requirement:
is
this
kind
of
you
know
friendly,
develop
ability
right
if
it
checks
all
those
boxes,
then
you
know
I,
wouldn't
you
know
say
absolutely
not
because
it
has
17
megabytes
of
dependencies
necessarily
right.
So
I'm
not
sure
that,
like
yes,
that
be
a
solution
lets
you
know
factor
off
the
separate
binary.
You
know
different
class
back.
That
includes
the
API
stuff
that
we
don't
want
anywhere
else
totally
agree,
that's
possible,
but
I'm,
just
not
sure.
That's
the
the
most
important
problem
with
the
only
problem
to
solve.
D
A
C
A
A
If
we
know
that
this
is
possible,
it
would
be
a
way
to
go
because,
right
now
it
seems
to
the
biggest
question
the
biggest
the
Gateway
locked
gate
in
this
case
is
to
get
the
dependencies
into
the
core
piece
repository
and
everyone
is
saying
no
well
no,
no
more
dependencies
and
and
if
we
can
capsule
it
in
the
API
project.
If
this
is
possible,
then
we
at
least
have
this
tore
or
opened
more
or
less
to
be
able
to
move
forward.
A
C
A
A
C
Now,
absolutely
it's
just
a
matter
of
creating
one
class
with
with
a
method
or
you
use
existing
class
if
it
corresponds
to
any
of
those
resources
like,
for
example,
we
could
have
a
resource
with
to
list
the
offer
book,
so
it
will
be
slash
offers
and
we
want
to
add
a
new
end
point
post
offers
and
so
post
slash
offers.
Then
you
would
just
put
another
method
into
the
same
class,
but
the
cat
offers
is
and
that's
it
and
before
for
the
intermodal,
you
just
create
one
class
that
would
correspond
to
the
request
by
load.
E
A
C
A
We
agreed
on
having
an
API
added
for
starters,
having
an
API
that
just
only
just
serves
an
offer
book,
so
we
can
foreclose
any
coded
attacks
because
it's
only
get
offers
and
that's
it.
We
use.
We
want
to
use
user
name
and
password
authentication,
basically
HTTP
basic
authentication
for
now
we're
because
it's
it's
used
by
by
Bitcoin
core
as
well.
We
use
it's
good
enough,
a
Bitcoin
core
as
well.
We
state
clearly
that
the
API
is
not
for
the
big
wide
world.
It's
only
for
your
convenience.
A
A
C
E
A
E
C
E
C
D
A
A
D
Okay
from
a
usability
perspective
and
from
doing
what's
well-known
and
obvious
to
people
perspective,
so
think
about
that
coin.
Core
again,
if
you're
running
Bitcoin,
core
Bitcoin
QT,
like
the
UI
right,
the
double-click
on
you
can
parameterize
that
with
server
right
at
the
command
line
or
or
in
your
it
cleaned
up
on
file
and
that'll
light
us
sit
coins,
RPC
API,
which
is
definitely
a
use
case.
It
makes
sense,
like
you,
may
want
to
interact
with
the
GUI
talking
for
the
same
underlying
data
directory
that
the
RPC
API
communicates
with
right.
D
All
in
one
thing,
you
might
be
basically
a
user
of
both
interfaces
at
the
same
time,
so
you
want
to
be
able
to
enable
the
RPC
API
from
the
GUI.
But
if
this
is
just
a
you
know,
headless
Raspberry,
Pi
running
somewhere
or
some
cloud
instance,
you
don't
want
or
need
a
UI
at
all,
and
you
just
want
to
be
able
to
SSH
in,
and
you
know,
run
Bitcoin
D
or
run
it
as
a
as
a
service
or
whatever.
Anyone
totally
had.
D
Listen
just
write
a
log
file
and
be
able
to
communicate
with
its
RPC
API.
So
when
we
Bitcoin
DEA's
run,
you
know
it's
really
just
the
exact
same
thing
as
running
a
Bitcoin
core,
but
shuts
off
the
UI
and
implicitly
enables
the
server
option
and
I
think
we
would
want
to
do
the
same
thing
here
like
it's
all
in
one.
So
you
can.
You
can
interact
with
your
bisque
note.
However,
you
want
as
a
GUI
as
a
headless
demon
or
both
basically
and
if
there's
a
separate
app
that
people
have
to
run.
D
Okay,
well
can
I
run
my
bisque
UI
and
this
API
at
the
same
time,
talking
to
the
same
data
directory,
you
know
you'd
have
to
explain
whether
that's
possible
or
not,
and
why
and
and
it's
sort
of
just
out
of
the
norm
of
what
you
would
usually
do
in
a
situation
like
this,
so
this
all
kind
of
very
sorry
for
the
noise
of
construction,
but
this
all
kind
of
adds
up
for
me
to
making
the
argument
that
we
should
integrate
this
at
a
pretty
core
level.
Right.
D
There's
a
there
is
no
more
basic
way
of
interacting
with
Bitcoin
core
than
talking
the
Bitcoin
D
right.
That
is
a
less
complicated
thing
than
running
the
UI.
If
you
just
think
about,
like
the
number
of
cycles
involved
in
threads
and
blah
blah
blah
right
needing
a
display
or
whatever
same
thing
with
bisque,
but
the
most
rudimentary
most
fundamental
way
to
interact
with
it
would
be
run
it
as
a
daemon
talk
to
it
programmatically.
D
So
that
is
kind
of
a
case
for
putting
stuff
in
core
right
and
I.
Think
that's
where
we
get
back
to
like.
Okay
is
what
we're
introducing
there.
If
we
merge
it
into
core,
is
it
a
reasonable
thing
to
do?
Is
it
you
know
giant
and
heavyweight
and
complicated?
And
you
know
thousands
of
lines
of
code
or
something
like
that
or
is
it?
D
C
Great
crease
is
just
that
we
are
very
afraid
at
the
month
rate
and
some
other
developers
are
afraid,
but
about
the
risks.
But
on
the
other
hand,
we
want
to
get
this
thing
going
because
there
was
a
lot
of
effort.
So
this
is
like
a
temporary
measure.
I'd
say
to
have
it
as
a
separate
project
just
to
see
if
people
would
like
to
use
it
and
it
mostly
for
people
who
want
to
just
see
the
API
and
maybe
write
a
script
for
that
and
later
on,
I
agree
with
you.
C
But
I
have
what
I
see
in
the
UI
and
fruity
API
and
probably
on
my
mob,
but
that
would
be
like
the
ultimate
goal,
but
once
we
decide
that
libraries
are
fine
and
we
are
okay
with
the
dependencies,
maybe
we
would
like
to
change
the
dependencies
on
the
way,
but
just
to
gather
the
thing
into
the
official
bisque
project.
I.
Think
that's
a
really
good
idea
with
Florian
propose
to
have
it
as
just
like
a
seed
node,
a
separate
application
that
people
intentionally
have
to
start
and
we
don't
introduce
new
risks
for
people
over
there.
A
D
D
D
See
so
it's
a
superset
of
everything,
but
but
but
it
can
be
invoked
in
a
way
that
the
desktop
doesn't
come
up
right.
I
guess
I
would
best
emulate
what
we're
actually
going
for
right.
So
the
usage,
the
usage
model,
would
be
what
we
actually
want.
We're
saying
like
if
you
want
to
try
out
the
API
and
you
need
to
run
disk
in
a
different
way.
D
D
C
Don't
think
so
because
the
main
class
needs
to
start
the
anyway,
so
there
is
cold.
We
don't
have
modular
approach.
I
wanted
to
do
that,
but
mantra
did
not
agree
on
this
depending
on
the
jars,
so
inside
your
bisque
up
or
one
of
those
main
classes,
there
is
a
code
that
needs
to
see.
If,
on
the
on
the
command
line,
there
was
a
parameter
to
start
the
API
and
if
certain
instantiate
the
class
and
and
started.
A
D
A
Idea,
I
proposed
is
basically
you
start.
If
you,
you
have
two
binaries,
there
is
biscuit
desktop
that
is
same
old,
same
old
and
no
risk.
You
know
API
and
then
there
is
the
bisque
API.
If
you
want
to
use
the
API
both
bisque,
it's
an
experimental
feature,
it's
a
new
feature.
I,
don't
know.
If
you
want
to
use
it,
you
have
to
build
bisque
in
a
way
that
the
bisque
API
binary
is
let's
say
built
and
then
in
the
bisque
API
project.
Yours
ray
already.
A
You
also
start
up
the
base
desktop
app,
so
it
looks
like
bisque,
but
has
the
API,
but
you
have
to
do
built
the
whole
application,
some
somehow
different.
So
then
we
have
the
separations
of
concerns.
There
is
it
the
bisque
API
is
the
are
the
dependencies
that
are
maybe
risky
or
not
I
don't
know,
and
we
have
the
convenience
that
you
start
up.
A
C
I
think
that
you
could
have
some
additional
source
directory
that
could
be
cannot
relief
conditionally,
but
we
could
create
like
different
project,
no
actually
I'm
using
this.
But
I've
got
this
integration
test
task
in
Gradle
and
for
that
tasks
it
uses
classes
from
completely
different
directory,
it's
not
using
from
the
test
directory
but
from
integration
test.
D
So
so
I
proposed
the
simple
thing
is
possibly
work,
even
though
it
would
be
ugly
right.
Let's
say
we
create
this.
This
sub
module
escapee
I,
we
copy
the
main
method,
the
main
class
logic
from
disk
desktop
right.
Just
imagine
literally
copying
and
pasting
that
class,
calling
it
something
else
and
then
changing
one
line
that
it
looks
for
and
invokes
this
API,
if,
if
so
instructed
right,
so
basically
there's
some
programmatic
set
of
bits
that
need
to
invoke.
D
You
know
spin
up
the
desktop
aspect
of
this
and
there
needs
to
be
a
hook
to
spin
up
the
server
that
the
API
right.
So
why
not
just
do
this
in
the
sub-project
so
that
there's
this
total
superset
of
everything
again
just
to
get
the
ball
rolling.
We
can
make
this
much
better
I'm,
not
saying
if
it
has
to
do
any
sort
of
you
know,
source
directory,
hacks
or
anything
like
that.
It's
just
yes
replicate
good
behavior
from
desktop
and
then
add
the
API
switch
exactly.
A
D
Agree:
yeah
with
the
idea
that
this
is
what
we're
doing
to
get
a
ball
rolling
to
get
this
in
front
of
early
adopters
users
to
validate
our
own
assumptions,
to
take
a
closer
look
at
the
implementation
and
the
dependencies
and
so
on,
and
then
we
make
another
decision
down
the
road
like
okay,
what's
the
actual
sort
of
go
to
production,
real-deal
version
of
this
right,
maybe
it's
abroad
like
they're,
maybe
not
right.
If
that's
kind
of
our
approach,
yeah
I'm
in
as
well.
B
This
whole
approach
of
hacking,
this,
like
you,
said
a
super
set
of
functionality
into
this
new
app.
That's
optionally,
including
the
HTTP
API,
seems
like
a
like
a
really
big
waste
of
like
details.
I
mean
I'm
I'm,
with
the
rest
that
guy's
jarrah
dependencies
are
scary
and
bad,
and
we
should
avoid
them
whenever
possible,
but
I
think
adding
an
HTTP
API.
You
know,
like
you
said
if
it
was
one
of
those
dependencies
like
from
square.
B
Obviously
many
many
people
are
using
the
square,
HTTP
library
for
many
financial
applications
and
they
trusted,
and
it's
community
validated
so
I.
Think
in
this
specific
case,
adding
a
jar
DEP
would
be
reasonable,
but
I
do
understand.
Like
you
know,
jar
adepts
are
scary,
so
maybe
we
should
actually
just
have
a
call
with
the
the
most
skeptical
people
who
are
against
the
jar,
depths
and
kind
of
break
down
the
reasons
why
they're
against
adding
it.
Maybe
we
could
even
consider
a
few
various
jar
depths
and
get
some
consensus
on
which
ones
exactly
we
should
add.
B
You
know
this
temporary
API
really
doesn't
do
much
for
me.
So
I'd
really
like
to
see
the
full-blown
API
just
implemented
as
soon
as
possible,
with
the
very
high-quality
jar
dependency
added,
if
necessary,
but
I
mean
this
is
this
is
one
of
those
times
where,
like
it's
totally
necessary
or
reasonable
to
add
a
jar
dependencies
just
of
course
we
have
to
be
very
careful
in
which
one
we
select
and
you
know,
look
at
all
the
security.
You
know
potential
risks
and
everything,
but
I
mean.
Is
it
mostly
Manfred
who's
against
this
adding
jarda?
D
Yeah
I
can.
This
is
almost
certainly
an
incomplete
historical
view
right
both
because
of
just
bad
memory
and
Mike
I
only
had
a
certain
perspective
on
it,
but
I
think
a
big
piece
of
this
was
as
these
efforts
were
coming
together,
but
you
know
Mike
and
Bernard
your
work
I
think
at
some
point
we
saw
whole
requests
coming
in.
D
They
were
just
overwhelmingly
large
right,
not
just
from
a
dependency
point
of
view,
but
wait,
there's
a
lot
of
code
and
forgive
me
because
I
didn't
review
these
in
depth
and
I
was
busy
with
other
things
and
I'm
just
sort
of
remembering
the
overall
gist
of
something
the
overall
feeling
of
something
was
like
too
much
yeah
anything.
It
was
just
like
a
like
a
kind
of
gut
reaction
like
please,
don't
put
all
this
stuff
in
core
right.
D
So,
if
we're
coming
at
this
tearing
it
down
to
a
single
use
case
right,
that's
not
going
to
be
a
lot
of
lines
of
code
added
or
shouldn't
be,
and
it's
going
to
be
whatever
set
of
dependencies
that
approach
that
implementation
introduces
and
if
we
look
at
those
dependencies
when
we
say
that
is
really
heavy
or
uncomfortable
or
complicated.
For
whatever
reason,
if
there's
consensus
about
that,
then
we
say
how
can
we
implement
that
one
use
case
with
something
much
simpler
and,
of
course
we
have
to
kind
of
think
ahead
and
go
like.
D
Is
that
simple
approach
going
to
be
able
to
meet
the
needs
of
the
broader
API
once
it's
kind
of
fleshed
out?
We
do
need
to
think
ahead
right,
but
I
I
mean
I
must
say:
I
agree
like
I.
Don't
want
to
jump
through
hoops
because
of
some
sort
of
like
Amorphis
fear
about
just
dependencies
are
bad
right,
but
rather,
like
I
am
just
so
sheepish
about
this,
because
it's
been
so
much
work
and
the
last
thing
I'm
going
to
do
it
sort
of
like
show
up
and
go
like
hey
just.
D
Do
it
again
issue
these
pull
requests
again,
whatever
and
I?
Guess
I'm
not
saying
that
I'm
saying
like
let's
cut
down
to
that
single
use
case,
make
it
as
clean
as
we
possibly
can
and
evaluate
it.
Right,
I
mean
Barnard
for
you.
Would
this
be
an
extraordinary
effort
or
like
way,
time-consuming
for
you
to
put
together
a
request
that
modifies
the
core
main
class
to
light
up
the
switch
for
the
API
server
or
not,
and
to
include
in
that
pull
request?
Just
one
use
case.
C
Yes,
so
the
base
the
basic
stuff
to
get
the
HTTP
server
started
and
in
this
the
most
recent
public
we
she
had
that
one.
Three
thousand
one
look
at
the
comments:
no
just
yeah.
If
you
look
at
the
files,
there's
58
ours,
but
there
is
docker,
ignore
docker
image
is
stuff
like
that.
Look
at
the
comments.
Look
at
the
comment.
Stop
but
please
collapse,
and
there
is
a
comments
tab,
because
this
is
conversation.
D
C
So
it
does,
and
it
has
only
one
end
point
last
one
end
point
to
get
the
version
of
the
bisquit
is
running,
but
it
includes
integration
tests
in
integral
include
some
arquillian
extensions,
yeah
and
just
a
little
bit
modification
in
the
core.
So
this
to
add
the
flags,
but
it
is
like
a
lot
of
funds
that
you
have
to
modify.
A
I'm,
not
quite
sure
about
that
talk--I
is
there.
I
talked
with
in
private
about
this
doctor
is
there
to
provide
the
integration
tests
and
he
has
done
mighty
tests.
So
it's
really
end
to
end
testing
of
the
whole
bisque
network,
including
Elly's
Papa,
now
iterator,
the
Bitcoin
core
node.
Has
it
node
everything
is
there?
The
question
is:
maybe
do
we
want
this
kind
of
tests
in
such
an
early
state
because
we
only
get
the
offer
to
get
offer?
For
example,
we
agreed
on
to
only
have
to
write.
B
D
Right
introduce
introduce
the
integration
tests
that
first
integration
Testament
meant
the
first
use
case
that
actually
needs
it
right
I
mean
you
could
make
the
argument.
They
need
integration
test
and
just
get
a
list
of
offers,
but
but
just
to
do
one
thing
at
a
time
right
and
we're
going
to
exercise
it
through
the
CLI.
B
Really
to
make
it
easier
for
the
maintainer
x'
to
review
the
individual
thing,
so
it's
like
Chris,
said
it's
very
scary
to
see
I
just
a
huge,
huge,
polar
quest
come
in
like
your
gut
doesn't
even
want
to
look
at
it
and-
and
you
know
maybe
it's
there's
some
emotional
things
in
there,
but
I'll
give
you
just
a
quick
example.
The
other
day
I
wanted
to
remove
three
of
the
hard-coded
BTC
nodes
from
this.
B
B
So
you
know
that's
that's
like
a
very
good
example
of
why
you
want
to
separate
things
as
much
as
possible
just
to
keep
the
discussions
as
separate
as
possible
under
reviews,
because
if
there's
any
any
problems,
any
discussions,
it'll
it'll
block
the
entire
PR
from
being
merged,
whereas
you
could
have
gotten
some
of
it
merged
right
and
then
that
kind
of
baby
steps
would
lead
to
getting
the
other
stuff
merge.
Eventually,
yeah.
A
But
there
there
is
a
flip
side
to
this.
Recently
there
has
been
quite
a
big
pull
requests
only
only
refactoring,
and
it
was
decided
that
it
has
to
be
split
up,
and
now
we
have
three
or
four
pull
requested
for
for
each
each
pull
request
for
itself
doesn't
mean
nothing.
It
just
adds
code
rename
stuff,
but
does
doesn't
remove
stuff.
So
it's
it's
it's
kind
of
a.
A
A
The
question
now
is:
do
we
want
integration
tests
for
the
API
and
I
agree
with
you
guys
that
we
can
maybe
remove
for
the
initial
for
the
initial
thing
of
adding
the
API
getting
the
API
up
and
running
that
we
remove
the
test,
because
if
we,
if
we
do
something
wrong
in
the
API
part
of
the
get
offer
use
case,
we
agreed
on
before
there
probably
isn't
a.
There
is
no
need
to
test
this
as
extensive
as
as
it
is
proposed
in
this
pull
request.
B
Just
one
last
thing:
when
it
comes
to
splitting
a
pull
request,
I
know
a
lot
of
the
jar
dependencies
are
related
to
the
docker
stuff
and
I
and
I
do
understand
that
they're,
just
dev
dependencies
they're
not
actually
shipped
with
the
final
build,
but
I
think
it
would
be
a
lot
less
scary
to
maybe
Manfred
or
the
other
guys
who
are
opposed
to
just
any
new
jar
dependencies
in
general.
If
those
weren't
part
of
a
separate
PR,
so
we
get
the
API
merged
first
and
then
we
can
kind
of
debate
on
the
reg
test.
C
A
A
D
Would
just
offer
at
least
potentially
that,
as
that
first
PR
comes
in,
and
we
actually
have
you
know
some
API
surface
area
but
I'd
be
happy
to
put
together
the
the
CLI
which
I
would
actually
write
in
German,
but
but
just
to
exercise
that
and
demonstrate
my
my
perspective
on
it.
I
think
I
can
have
time
to
do
this
when
we
get
there.
I
could
be
more
certain
about
it,
but
just
just
to
offer
I
could
contribute
that
also.
B
A
I
will
create
some
meeting
minutes
with
the
list
of
how
to
proceed,
completed
and
I
believe
we
can
have
this
as
a
as
a
great
result
of
two
deaf
cars
and
time
of
probably
four
hours
of
discussion
and
well.
Thank
you
guys
for
joining
thanks
for
their
for
the
discussion.
Thanks
for
your
contributions,
see
you
next
time.
Thank.