►
From YouTube: Hummingbot Weekly Developer Call 003
Description
The Weekly Developer Call is technical & general discussion intended to gather active community developers who contribute in making the Hummingbot codebase better through Hummingbot Improvement Proposals (HIPs) and Bug Fixes.
Time Stamps
0:00 Introduction
0:25 New PM Repo
2:40 Bot Coordination
6:38 Source, Docker
7:20 Local, Global Config
11:40 Proposed Solutions
15:25 Processes with Miro Whiteboard
23:05 Epoch 2 Budget
26:35 How to apply for Dev Grant
29:45 Next Developer Call Session
#hummingbot #developer #algotrading #cryptotrading #liquiditymining #trading #bottrade
A
Welcome
everyone
started
this.
This
series
of
deaf
calls
just
a
few
weeks
ago,
but
it
already
seems
like
it's
a
big
hit
and
for
us
we're
excited
to
actually,
you
know,
really
be
more
transparent
and
communicate
with
the
global
humanwall
community
every
week,
especially
on
the
developer
side
and
and
really
have
you
guys,
helped
us
build
a
better
code
base
that
serves
everyone
in
the
community.
Double
crochet
management
things
before
payday
starts.
We
created
a
new
github
repository
called
pm,
which
is
in
the
humminbot
foundation.
A
Github.Com
hummingbot,
slash
pm,
it's
a
public
repository.
It
is
modeled
after
the
the
one
that
the
ethereum
foundation
uses
for
their
or
debt
calls.
So
the
idea
is
that
before
every
weekly
call,
carlito
or
fedex
would
post
the
agenda
with
the
high
level
topics
that
we
want
to
discuss.
If
you
want
to
add
topics
that
gender
suggest,
your
topics
in
the
community
call
chat
channel
during
the
week
and
then
it
will
try
to
add.
A
You
know
your
topics
to
the
chat
agenda
as
well,
and
then,
after
the
meeting
carlillo
will
post
the
audio
recording
of
a
call
to
the
repo
as
well,
so
that
anyone
who
can't
make
the
time
can
also
follow
along
in
the
future.
We
may
add
notes.
Ethereum
foundation
has
a
note
taker
right
now,
we're
just
starting.
B
A
A
These
are
definitely
long-term
improvements
that
we
want
to
make
to
the
humanbot
code
base
and
the
goal
is
really
to
just
have
an
open
discussion
among
the
community
in
terms
of
what
the
architecture
should
look
like,
and
really
basically
try
to
identify
members
of
the
community
who
wants
to
work
and
earn
hbo
tokens
for
working
on
these.
These
things
format
the
call
we'll
try
to
always
try
to
have
this
call.
B
B
What
I
write
about
this
is
like
it's
a
system
that
interacts
with
multiple
handbot
instances
and
is
able
to
start
top
and
change
configurations
of
the
bots.
That's
like
the
the
main
goal
that
we
are
trying
to
accomplish
with
this,
which
will
be
the
person
that
will
be
interested
in
this
solution.
Community
members
are
running,
multiple
votes
to
liberate
in
different
markets,
or
hedge
funds
are
using
honeybots
and
they
have
to
manage.
I
don't
know
100
or
200
bots,
which
are
the
problems.
B
So
also.
Another
thing
that
you
want
to
do
is
check
the
performance
of
the
bot
and
if
you
have
some
issues
or
you
want,
you
find
you
found
the
market
some
special
conditions.
Probably
you
want
to
stop
the
bot
box
and
adjust
the
strategy
to
run
it
again
so
right
now,
all
these
strategies
are
manual.
This
is
when
running
multiple
bots
on
one
pair.
There
are
multiple
connectors
right,
yeah,
that's
true,
initials
and
and
also
or
another
market
they
can
strategically
try
and
bdc.
Using
the
same
instance,
you
will
be
receiving
to
that
ip
address.
B
You
are
asking
for
the
information
from
the
same
ap
address
the
two
times,
the
same
information,
so
also
it's
a
good
point.
I
would
like
to
the
to
the
prd
that,
because
it's
important
tdc
sets,
these
are
very
good
starting
points.
Okay,
well,
that
part
was
a
little
bit
easy
because
I
was
running
multiple
bus
to
before.
So
I
had
those
issues
too
why
we
are
trying
to
do
this.
Is
I
I
think
that
managing
multiple
bots
is
a
feature
that
anyone
wants
to
be
anyone
that
wants
to
be
a
marketing
maker?
B
It's
because
you
want
to
have
control
in
all
your
bots.
Also.
I
think
that
the
users
have
to
spend
their
times
analyzing
the
markets
on
the
performance
of
the
bots
instead
of
dealing
with
multiple
instances
and
configurations,
and
also
it
will
let
you
take
quick
actions
on
the
bots.
If
a
special
market
condition
appears
you
say,
hey
the
market
is
going
to
crash.
I
want
to
stop
all
the
bots
right
now
and
cancel
all
the
orders.
B
You
don't
have
like
a
safe
way
to
do
it
right
now
how
we
can
say
that
this
will
be
easily
success.
If
we
have
an
interface
that
lets
you
manage
multiple
bots
start
stop
and
change
the
configuration
of
the
different
bots.
Now
we
are
going
to
the
part
of
functional
requirements.
We
will
have
like
a
unified
interface
to
run
multiple
docs
with
docker
we'll
have
each
bot
in
different
order
instances,
and
we
will
need
that
the
user
can
start,
stop
change,
configuration
and
check
the
performance.
B
B
A
B
Tgc
says
be
able
to
do
the
same
for
handbook
running
from
source.
Maybe
we
can
create
a
pool.
How
many
people
is
using
shows
how
many
people
is
using,
maybe
we're
using
docker.
I
will
create
it
and
we
can
understand
that
because
if
you
are
running
in
production,
multiple
bots,
I
think
that
using
docker
will
be
better
than
using
the
drainage
from
source
and
also
you
can
create.
Maybe
you
can
use
a
service,
I
don't
know
who
are
natives
or
something
like
that
to
orchestrate
them
too,
and
this
orchestration
layer
to
manage
them,
but.
B
To
say
yourself,
I
think
we
also
need
to
perhaps
redefine
which
conflicts
are
global
and
which
conflicts
are
local,
for
instance,
in
balancing
it
should
be,
should
it
be
per
exchange
globally
per
bot.
I
think
every
bot
has
to
have
its
own
configuration
if
you
are
using
different
api
keys.
Probably
if
you
are
using
super
accounts,
you
will
have
different
api
keys
and
all
those
things
but
disappoint
to
discuss
which
conflicts
are
global,
which
are
local,
local,
you,
you
say
global
okay,
you
added
micro.
Thank
you
is
local,
is
for
each
box.
Okay,
perfect!
B
A
Think
the
ability
to
change
configurations
from
the
master
interface
that
actually
might
cover
the
the
bot,
the
local
versus
global
config
issue,
because,
let's
say
yeah
like
some
commands,
says
change
all
the
the
the
the
you
know
the
limits
to
to
something
but
yeah.
Actually,
maybe
I
should
maybe
not
because
I
guess
for
bounce
limit
yeah.
I
see
that
well
for
bounce
limit,
because
you're
pulling
from
the
same
account
yeah.
It
would
be
actually
a
global
global
thing,
so
so
yeah.
I
think.
A
I
think
that
I
think
if
you
want
to
do
kind
of
global
versus
local,
you
could
kind
of
set
up
sub-accounts
or
use
different
wallets
for
different
boxes,
and
that
way
you
can
have
bot
based
balance
limits
or
if
you
want
a
global
base
limits.
I
think
the
best
solution
is
to
use
like
a
single.
You
know
account
for
all
the
bots
and
then
set
the
same
balance
limit
for
those.
A
I
think
there's
like
the
interface
part
of
this
versus,
like
the
the
functional
like
technical.
I
think
the
approach
that
I
was
always
I
would
suggest
initially
is
focus
on
the
technical
part,
configure
it
to
be
able
to
run
with
a
very
like
basic
interface
and
over
time,
like
someone
might
be
able
to
develop
multiple
interfaces
depending
on
how
they
want
to
customize
the
behavior
of
the
overall
system.
B
Woojack
says
a
functional
requirements,
bot
status,
reporting,
a
bot
operation,
call
to
action
start
and
stop
buttons.
Yeah,
that's
already
changing
specific
bulk
parameters,
yeah!
That's
like
changing
the
conflicts.
I
agree
to
grows
relating
to
the
balance.
If
stop
box,
if
violence
is
lower
than
x
value,
spin
up
more
works
with
valon
okay.
That
would
be
the
the
same
that
mike
says.
That
is
event.
They
set
triggers
to
stop
and
store
the
bots.
So
right
now
we
have
all
the
topics
covered.
B
B
B
We
were
working
in
the
past,
but
but
I
think
that
also
is
more
related
to
reporting
into
nice
feature
to
able
to
change
both
parameters
from
outside
yeah.
That's
that's
the
main
goal
that
we
are
trying
to
accomplish
to
change
the
parameters
of
the
world
from
the
outside
question,
why
the
docker
can
run
memory
easily,
which
just
says
and
then
crash
binance
perpetuals
connector,
probably
you
have
some
issues
with
the
memory
to
write
more
information
then,
and
we
can
review
that
with
the
qa
team
outside
ttc
says
the
bots
must
have
conflict
separated,
okay,.
A
Let's
try
to
move
on.
I
copied
some
of
the
the
more
like
the
larger
comments
to
the
trd,
so
we'll
try
to
organize
this
a
bit
later,
but
we
also
want
to
talk
about
some
of
the
proposed
solutions
that
members
of
the
community
have
already
created
for
this
and
try
to
get
some
discussion
on
which
direction
should
we
head
toward
which
one
should
we
actually
kind
of
start
investing
into,
and
how
do
we
kind
of
like
combine
them
or
or
or
kind
of
like
iterate
on
them?
B
Asked
different
community
members
of
which
are
the
solutions
that
they
have
already
implemented,
and
I
post
the
answers
of
them
here
in
this
house
section,
so
the
three
main
solutions
that
we
have
right
now
that
interacts
with
the
pot
from
the
outside
the
whole
disruption,
websocket
implementation
that
currently
is
using,
is
receiving
the
signals
from
trading
view.
This
solution
currently
needs
a
server
that
runs
with
node.
I
think
information
to
the
different
bots.
The
next
solution
is
one
created
by
kia
panagi.
He
creates
like
a
broker-based
communication
using
mqtt.
B
There
is
a
protocol
commonly
used
in
iot.
He
likes
a
lot
of
these
distributed
systems.
Currently
there
is
an
image
in
the
part
of
the
panel
that
you
start
stop
the
mods.
I
don't
know
if
there
is
another
page
that
lets
you
change
the
config
or
not,
but
currently
it
has
a.
He
has
those
implementations.
B
He
have
he's
compatible
with
rpc
communication.
He
has
he
the
how
it
works
is
that
kind
of
pops
up.
You
can
publish
a
message
in
the
same
qt
and
the
bots
will
be
subscribed
to
that
topic,
so
they
will
receive
the
information
that
yeah
banaii
sends
through
this
ui.
So
that's
the
second
solution.
Third
solution
is
the
petio
rpc
layer.
Patio
is
a
an
engineer
from
coin
alpha
right
now.
B
The
solution
is
terminated.
Now
you
cannot
stop
start
and
change
the
conflict
of
the
bot,
but
he
said
that
we
can
create
an
ui
to
interact
via
http
with
the
with
the
button
sends
commands
to
it.
So
these
are
like
the
three
solutions
that
we
have
right
now:
the
broker-based
communication,
the
websocket
implementation
and
the
rpc
layer.
A
The
goal
of
this
meeting
is
not
to
kind
of
like
really
make
any
decisions.
It's
really
about
kind
of
like
just
like
a
temperature
check
from
the
community
in
terms
of
like
which
direction.
Should
we
investigate
further
think
about
alternatives,
or
if
you
think
that
kind
of,
like
you
know,
we
should
be
looking
to
combine
some
of
these
solutions,
we're
just
looking
to
kind
of
get.
You
know
consulted
technical
expertise
of
the
overall
community,
so
we'll
probably
end
up.
You
know
having,
I
think,
we'll
actually
end
up
discussing
this
in
more
detail.
A
After
we
kind
of
like
do
more
investigation,
work
started
having
these
calls
to
actually
turn
hummingbird
into
a
middleware
community
base,
so
the
direction
is
not
dictated
by
us
or
by
corn
alpha.
Instead,
the
direction
is
dictated
by
everyone
in
the
community.
The
goal
here
is
really
just
try
to
get
an
initial
discussion
going
on
this
topic.
A
I'll
explain
more
in
the
governance
part,
but
I
think
that
to
us
like
what's
worked
in
the
past
is
like
you
know,
when
I
look
at
the
first
epoch,
it's
when
we've
had,
like
you
know,
good
community
members
that
have
almost
like
formed
teams,
either
themselves
or
with
other
members
to
work
on
something.
So
you
know
this
work
has
really
been
done.
You
know
in
by
individual
community
members
on
their
own.
I
think
they
would
all
appreciate
you
know
people
helping
them
out.
A
You
know
whether
it's
like
and
I'd
like
to
help
them
test
it
to
kind
of
give
them
another
second
opinion,
and
so
I
think
the
goal
of
this
is
kind
of
like
almost
like,
create
some
type
of
like
dev
grant.
That
is
going
to
reward
multiple
people
for
contributing
to
to
one
initiative
and
try
to
make
it
a
truly
a
community-based
effort.
A
That's
a
good
point
we'll
give
everyone
some
time
to
think
about
what
orchestration
process,
so
the
mirror
white
board
is
probably
the
main,
like
sort
of
truth
for
how
we
think
the
the
new
process
work.
So
if
you
guys
open
up
the
link
that
I
just
posted
in
the
community
chat
basically
outlines
different
processes
for
bugs
improvement
proposals
which
are
basically
non-bugs
and
pull
requests
so
just
to
define
what
these
are
bugs
are
things
that
you
know
either
someone
identifies
and
says:
hey,
you
guys
should
fix
this
in
the
code.
A
Improvement
proposals
are
basically
when
someone
says
hey
you
guys.
I
think
you
should
add
this
new
connector,
this
new
strategy
or
some
big
improvement
like
the
coordination,
orchestration
module,
you're,
helping
bot
both
of
these
processes.
We
envision
ending
up
as
a
pull
request,
because
the
first
two
are
issues.
They
really
start
as
github
issues
someone's
created,
but
there's
a
someone
has
to
actually
write
code
to
fix
it.
A
In
addition,
we
kind
of
envisioned
two
public
artifacts,
one
is
a
bounties
board
and
the
second
is
a
review
board.
So
the
idea
behind
the
boundaries
board
is
that
both
bugs
and
improvements
result
in
a
bounty
being
created.
So
for
bugs
the
idea
is
that
the?
If
it's
a
bug
that
there's
no
voting,
because
everyone
wants
that
bug
to
be
fixed?
So
when,
once
the
foundation
assesses
the
severity
and
the
level
of
effort
on
the
bug,
it
would
check
a
schedule
and
then
add
a
bounty
to
the
bounties
board.
A
After
that,
any
developer
can
raise
their
hand
and
say
you
know
I
want
to
work
on
this
bounty
and
and
earn
it,
and
then
it
will
be
assigned
by
the
foundation
to
to
work
on
it
after
that,
the
developer,
once
they
have
the
pull
request
ready.
Then
that
starts
the
pull
request
process
which
I'll
discuss
in
a
bit
for
non-bugs,
which
are
improvements.
We
think
that
the
first
part
is
making
sure
that
the
community
really
believes
that
the
improvement
is
actually
worthwhile.
So
we
think
a
form
thread.
A
A
After
that
it
could
be
a
foundation
bounty
in
the
case
of
some
large
architectural
change
like
this,
but
coordination
discussion,
but
a
lot
of
time.
It's
a
someone
from
the
community
who
wants
to
add
a
a
connector
for
their
own
exchange
or
a
new
strategy,
they've
developed,
or
they
want
to
fund
a
new
strategy
that
they
think
will
benefit
them.
So
in
that
case
we
want
to
really
start
the
concept
of
community
bounties
where
some
of
the
communities
say.
If
someone
builds
x,
I'm
gonna
give
this
amount
of
tokens
to
that.
A
So
we
would
set
up
a
community
bounty
wallet
at
the
foundation.
If
someone
funds
a
bounty,
then
that
gets
added
to
the
bounties
board.
Alternatively,
if
it's
a
foundation
bounty,
so
if
it's
being
paid
aged
by
tokens
or
other
funds
to
the
foundation,
then
it
would
need
to
go
through
the
hip,
helping
about
an
improvement
proposal
voting
process
on
snapshot.
If
the
community
votes
it
in,
then
it
would
get
added
to
the
bounties
board.
A
One
note
is
that
an
epoch,
one
set
of
guidance
that
was
20
000
hbot
tokens
for
one
day
of
dev
work.
Unfortunately,
we
feel
like
it
created
kind
of
an
incentive.
If
you're
a
new
developer,
you
take
a
long
time,
then
you
actually
earn
more
tokens
for
doing
that
span
of
work.
So
this
time
around,
we
don't
want
to
give
any
per
day
guidance
in
terms
of
how
much
hbo
you're
earning.
A
We
think
that
it
should
be
looking
at
the
budget
step
of
the
epoch,
so
we're
proposing
a
dev
grant
budget
of,
I
think
15
million
tokens.
So,
overall,
you
know
if
it's
improvements,
I
think
the
the
women
should
to
ask
for
a
share
of
that
budget,
and
then
the
voting
process
should
be
driven
by
the
community
to
decide.
A
Bugs
and
proof
proposals
end
up
as
a
pull
request.
In
addition,
people
can
also
submit
their
own
pull
requests.
If
it's
a
bug
fix,
we
don't
think
it
needs
to
be
voted
on
the
bug
fix.
We
go
straight
to
the
review
board,
which
is
another
public
github
board,
we're
creating.
It
would
say.
If
it's
a
non-bug,
then
we
do
think
it
should
go
through
a
voting
process
and
that
the
voting
process
for
here
is
not
to
decide
whether
the
request
will
be
merged
in,
but
instead
it
decides.
A
If
the
review
team,
someone
from
the
review
team
should
be
reviewing
it,
the
review
team
is
is
something
we
tried
experimenting
with
in
the
first
epoch.
This
time
we
want
to
open
up
more.
So,
instead
of
just
having
a
limited
number
of
people,
you
know
only
like
one
out
of
the
five
elected
members
being
able
to
review
it.
We
think
that
pretty
much
any
qualified
reviewer
should
be
able
to
review
these
pull
requests
and
they'll
be
compensated
as
well.
A
For
for
these
boundaries
and
bugs
in
case
of
like
a
normal
contribution,
a
poor
request
submitted
by
the
community
member,
we
envision
a
review,
a
review
budget
like
basically
a
budget
of
tokens
that
pays
the
reviewer
tokens
for
reviewing
the
the
pull
request
and
if
it's
a
connector,
which
is
bigger
or
strategy,
you
know
they
might
get
more
than
if
it's
simple
like
a
simpler
thing
to
review.
So
that's
over
our
process
and
also
on
the
board.
A
There's
there's
there's
like
outlines
for
what
the
two
boards
would
look
like
both
the
bounties
board
and
the
review
board,
and
so
there's
kind
of
like.
Basically,
the
the
boxes
are
each
column
in
the
in
the
basic,
the
kanban
pipeline,
and
it
shows
kind
of
how
both
issues
and
pull
requests
would
transition
from
one
state
to
another.
A
So
that's
just
a
quick
overview.
I
know
that
it's
a
pretty
complicated,
know
a
flowchart,
but
but
we
think
that
overall,
it's
a
better
process
than
we
had
in
the
first
epoch,
because
the
goal
is
to
try
to
a
make
it
more
transparent.
What
the
process
is
for
getting
code
in
the
code
base
and
b
a
reward
community
members
for
for
doing
the
work
and
try
to
make
it
more
more
fair
for
them
to
do
so
I'll
stop
here.
A
So
I
think
originally,
when
we
first
started
the
foundation,
we
envisioned
that
we
would
give
out
30
million
hbot
tokens
in
epoch,
1
and
then
60
million
and
epoch
2.,
because
the
the
token
amounts
being
given
out
the
foundation
side.
I
think
we've
kind
of
realized.
It's
not
so
much
about
what
the,
how
much
tokens
we're
giving
out.
A
I
think
some
of
the
things
we've
done
in
the
first
epoch
that
probably
didn't
add
as
much
value
or
things
like,
like
the
the
hackathon,
where
we
gave
out
a
million
tokens
of
people
who
just
did
like
you
know,
just
a
small
amount
of
work
that
didn't
actually
end
up
being
merged
into
the
code
base
or
in
the
case
of
the
developer
airdrop.
You
know
people
are
kind
of
like
earning
10k
tokens,
for
you
know
not
not
really
actually
making
meaningful
contributions
to
the
code
they're
just
getting
airdrops
because
they
submitted
a
request.
A
So
so
I
think
in
the
future.
That's
why
we
want
to
kind
of
try
to
scale
back
the
number
of
tokens
given
out
just
keep
it
at
30
million
again
for
epoch
2
until
we
have
a
good
handle
on
what
actually
is
going
to
benefit,
what
kind
of
like
what
kind
of
grants?
What
kind
of
initiatives
will
actually
benefit
people,
and
because
a
lot
of
us
hold
h5
token
and
the
more
that
is
out
there,
the
more
it's
on
the
open
market
and
then
the
more
that
diminishes
the
actual
the
value.
A
So,
overall,
I
think
the
goal
for
us
is
not
to
you
know
it's.
It
is
a
government.
It's
still
a
day.
It's
a
governance
token.
The
revenues
for
the
foundation
aren't
based
on
selling
token.
The
revenues
are
based
on
the
fees
that
we
get
shared
from
different
exchanges
that
our
partners
on.
That's,
why?
A
I
think
the
the
core
mandate
of
the
foundation
is
to
try
to
essentially
reach
sustainability
by
driving
more
volume
to
these
fisher
exchanges,
which
only
happens
if
the
code
base
is
actually
usable
and
if
the
community
can
actually
you
know
has
a
has,
they
can
can
do.
Lots
can
run
lots
of
lots
of
bots
on
on
these
top
exchanges
and
and
actually
be
able
to
execute
the
trading
strategies
they
want
to
implement
in
a
safe
and
an
easy
way.
A
We're
less
focused
on,
like
the
the
hbo
token
like
how
much
we're
giving
out,
but
more
on
what
that.
What
the
what
the
use
cases
that
were,
that
what
kind
of
value
and
what
kind
of
development
we're
going
to
drive
by
using
token.
So
that's
just
a
quick
explanation
of
how
it
works,
but
we
well.
I
welcome.
We
welcome
all
kind
of
like
any
all
feedback
on
this
process.
A
If
this
is
all
these
are
all
snapshot
extensions
and
then
finally,
we
have
one
for
protocols,
proposals
which
is
hbot
dash,
prp
dash
eve.
We
think
the
right
starting
the
correct
starting
point
is
probably,
if
more
of
a
forum
thread
propose
a
dev
grant
of
some
kind.
We
think
having
discussion
around
that
before
you
just
kind
of
submit
the
proposal
is
a
good
idea.
A
Otherwise,
because
people
don't
check
snapshot
on
it,
often
so
in
order
to
pass
quorum
and
reach
quorum
for
your
proposal,
I
think
you
probably
want
to
try
to
get
some
some
debate
and
get
some
validation
from
the
community,
so
I
would
actually
recommend
creating
a
forum
thread
in
the
in
the
improvements
category.
If
you
want
to
basically
get
your
proposal
implemented
and
get
a
dev
grant
for
doing
the
work.
B
A
B
We
we
discussed
the
different
solutions
that
we
have
already
that
they
are
interacting
with
the
bot
from
the
outside.
One
is
your
solution.
The
next
step
will
be
to
have
more
details
of
additions,
different
solutions
and
create
probably
a
thread
to
discuss
that.
I
I
would
do
that.
I
would
do
that,
might
know
and
create
thread
with
the
different
solutions,
and
maybe
we
can
discuss
that
there.
What
do
you
think.
A
Create
a
form
thread
link
to
the
bot,
orchestration
notion,
page
and
then
people
can
kind
of,
like
you
know,
kind
of
add
you
know
the
comments
and
and
everything
in
line
try
to
understand
more
about.
You
know
how
nugget
solution
might
integrate
with
what
what
holy
roger
has
already
done.
You
know,
and
and
except
I
believe,
the
holy
rogers
spent
more
time
on
the
trading
view
web
server
and
in
in
that,
rather
than
on
the
you
know,
rather
than
on
the
websocket
part
of
it.
A
So
these
two
solutions
may
actually
be
you
know,
aligned
and
in
terms
of
the
what
what
coinoff
has
created
in
terms
of
the
rpc
layer
overall
yeah.
I
think
that
yeah,
I
would
say,
because
we
don't
have
enough
information
about
it
right
now,
so
I
I
would
recommend
we
kind
of
focus
on
the
klimnogi's
solution
and
seeing
how
it
might
integrate
with
the
holy
roger
solution
for
now
and
then,
if
we
can
integrate,
you
know,
coin
office
rptc
layer
into
it
later
on.
B
Okay,
perfect
so
well,
I
will
create
the
phone
thread
today.
I
will
link
the
notion
page
and
then
we
can
move
the
discussion
discussion
to
this
course.
So
maybe
without
those
comments
we
can
the
next
session.
We
are
going
to
continue
the
discussion
of
this
world.
Congratulations
idea,
based
on
which
are
the
comments
in
the
in
the
thread.
B
That
is
advances
in
financial
machine
learning
and
explain
the
difference
between
time
bars,
volume
bars,
lower
bars
and
which
is
important
to
distinguish
between
the
them,
because
they
know
the
the
distribution
of
the
returns
has
much
more
a
normal
distribution
when
you
are
looking
at
a
volume
or
dollar
instead
of
time.
Please
review
that.
B
So
maybe
we
can
discuss
in
the
next
meeting
those
those
topics
too,
and
also,
if
you
are,
if
you
want
to
add
another
topic
to
discuss,
please
write
in
the
community
called
chat,
which
are
the
things
that
you
want
to
discuss
in
the
next
meeting
or
the.
So
we
can
start
doing
creating
the
agenda
properly
so
tires.
B
B
I
would
say
I
agree
with
you
and
I
think
that
that
is
one
of
the
the
main
ideas
that
el
pani
has.
It
will,
let's
communicate
different
instances
between
them
and
different
servers.
Different
services
like
the
trading
new
integration.
I
think
that
we
can
add
that
easily
to
the
kyoto
knight
solution
too.
This
will
open
a
lot
of
opportunities
and
a
lot
a
lot
of
improvements
in
the
in
the
code
base
in
the
future,
and
it
will
be
much
more
easy
to
add
micro
services.
A
What
fit
is
saying
is
the
mqtt
broker
is
not
necessarily
protocol.
It's
more.
It
is
basically
a
communications
layer.
You
know
between
the
the
core,
one
core,
hummingbit,
consumer
and
and
other
and
basically
some
type
of
like
central
control
plane.
So
I
believe
that
the
solution
that
klipnagi
implemented
does
support
various
communication
protocols,
whether
it's
like
you
know
like
websocket
or
you
know,
rpc
or
you
know
or
other
other
other
protocols
for
communicating
between.
You
know
one
instance
to
another,
but
but
this
is
where
I
think
there's
there's.
A
Probably
the
devil
is
probably
in
the
details
here.
So
moving
discussion
to
the
discourse
forum.
You
know
like
architectural
discussion
involving
some
diagrams
and
you
know
kind
of,
like
you
know
some
flowcharts,
so
that
we
can
actually
be
more
specific
in
terms
of
describing
what
the
best
solution
might
look
like.