►
From YouTube: Leap Meeting #39 (Nov 9th) 2022
Description
The Leap upgrade working group gives the community an update on software development, discusses how to make P2P improvements, and goes over the list of Antelope coalition priorities.
00:00:00 Start
00:01:00 Software development
00:12:50 P2P improvement discussion
00:43:00 Antelope coalition priorities
00:58:56 End
Summary
🟢 In progress action items are on track:
#41
Antelope software updates just released:
- CDT 3.1.0 RC1
- Leap 3.2 areas to focus testing:
- SHIP backports
- HTTP 1.1 for API/cleos
Antelope software/documentation updates on the way:
- Document on how crypto extensions inside CDT to utilize crypto
primitive host functions
- System contract updates
- Release of DUNE in the next month
This week we hosted a technical discussion on P2P improvements and
learned about the Antelope Coalition prioritization process
- Antelope Coalition has deemed P2P peer discovery as a priority
and issued a new RFP
Next week, we'll continue the technical discussion on P2P
improvements with a focus on Net plugin enhancements.
Given the evolution of this call, we'll rebrand from The Antelope Leap
Upgrade Working Group to the EOS Node Operator Round Table. Leap
upgrades will continue to be a focus of this group, but the scope has
expanded to also include technical roundtable discussions to inform
the roadmap for future upgrades.
https://github.com/EOS-Nation/leap/issues/106
Participants (16)
Randall Roland
Dario | EOSsupport.io
Kevin Heifner
EOSUSA Michael
brianhazzard
Jeff Werner
Jonathan Giszczak
Denis Carriere
Max_Cho :: KOREOS Owner-South Korea
Daniel Keyes | EOS Nation
Stephen Diesel
Matthew Darwin
Corvin Meyer auf der Heide - cmadh | liquiid.io (Corvin Meyer auf der Heide)
Ted Cahall
Ross (EOSphere)
Hahn Ryu (@luckyhahnryu)
The EOS Network Foundation coordinates financial and non-financial support to encourage the growth and development of the EOS Network. We’re harnessing the power of decentralization to chart a coordinated future for the EOS Network as a force for positive global change.
// EOS Network Foundation //
https://www.eosnetwork.com
https://twitter.com/EosNFoundation
https://www.linkedin.com/company/eos-network-foundation
https://t.me/EOSNetworkFoundation
https://discord.gg/eos-network
info@eosnetwork.com
#EOS #EOSIO #ENF
A
A
Jeff
is
going
to
be
doing
a
quick
demo
on
Antelope
coalition
prioritization
and
before
we
get
into
that,
we
can
just
quickly
check
in
shouldn't.
Take
long
on
software
release
updates
the
last
week
we
got
the
update
that
leap,
3.1.3,
patches
out
leap,
3.2.0
rc2,
is
out
and
still
expect
it
on
the
way.
Cdt
3.1
system
contracts
and
dune,
perhaps
a
little
further
down
the
road
any
anything
to
report
there.
Stephen.
B
Yeah,
so
we
do
have
an
update.
We
released
rc1
of
CDT
yesterday
evening,
I
just
dropped
the
release
notes
there.
Really.
What
it
involves
is,
there's
a
little
bit
of
an
update
around
how
the
data
segment
partitioning
is
taking
place,
but
the
the
big
thing
that's
in
this
release
is
just
some
of
the
remaining
crypto
extensions
that
we
were
hoping
to
get
into
the
original
release
of
CDT,
that
being
3.0.0
in
side
of
the
new
org,
so
that
that's
a
lot
of
what's
going
on
inside
of
that
release.
B
As
far
as
any
of
the
other
releases
go.
Of
course,
the
most
recent
RC
for
leap
is
still
rc2
and
I
think
that
we
are
still
on
track
within
the
next
month
or
so
to
have
a
a
dune
release.
The
timeline
of
that
we've
really
not
nailed
down
just
yet
we're
really
just
kind
of
trying
to
tidy
up
a
couple
of
things
most
notably
what
we
want
to
get
out
in
that
next
releases,
removing
the
versioning
dependency
that's
inside
of
Dune.
B
The
the
only
other
thing
I
wanted
to
bring
to
this
segment
of
the
discussion
is
I
did
want
to
Circle
back
on
just
where
we've
got
eyeballs
testing
out
some
of
the
the
code
that
we've
been
releasing
incrementally
just
to
make
sure
that
we're
covering
our
bases
I
know.
We
were
very
deliberate
about
this,
with
the
upcoming
consensus,
upgrade
that
we
had
previously
back
in
I,
guess
September
timeline.
B
But
there
are
a
couple
areas
where
there
there
have
been
changes
within
leap
across
this
3.2
release
that
we'd,
like
a
little
bit
more
attention
and
after
discussing
with
the
team,
the
two
primary
areas
are
a
ship
in
our
HTTP
protocol
for
clios.
So
with
regards
to
to
ship
there's
a
number
of
back
ports
that
were
integrated
into
the
rc1
release
and
I
I
think
that
we
just
like
people
poking
around
testing
ship,
making
sure
that
there's
nothing
that
jumps
out
at
people
that
are
actually
I.
B
Think
a
few
fixes
that
we've
already
made
here
recently
and
then
I
also
know
that
we
upgraded
to
I,
guess
HTTP
1.1
for
cleos
I
think
this
was
just
related
to
some
errors
that
were
being
thrown
in
certain
Cloud
Stacks.
But
those
are
the
the
the
two
main
areas
that
I'm
aware
of
I
also
see
that
Kevin
flipped
his
camera
on
so
maybe
has
a
bit
more
color
to
add
as
well.
D
Well,
I
I
always
appreciate
I'm
curious
on
that
is
like
on
the
ship
stuff.
Would
that
be
in
relation
to
like
a
full
replay
or
native
3.2
ship
logs?
You
know
like
resynced
and
built
from
scratch
versus
you
know.
Most
of
us
are
taking
these
ship
logs
and
just
snapshotting
them
forward,
but
they're
the
original
logs
are
still
I,
think
in
the
old
format.
So
a
little
clarification
on
that
I'm
curious.
C
Yeah,
that's
fine,
the
the
changes
in
the
ship
that
you
know
probably
needs.
Some
testing
is
just
the
fact
that
it's
multi-threaded
now
and
so
there's
some
enhancements
along
those
those
vectors
in
terms
of
like
it's
its
capabilities,
so
just
making
sure
that
you
know
it
didn't
introduce
any
any
bugs.
There
was
one
already
that
was
discovered
in
rc1
that
has
been
fixed,
and
so
you
know
there.
D
E
D
D
C
A
C
D
C
E
Yeah
I
mean
the
only
thing
that
we
noticed,
which
was
already
fixed,
was
the
404
error.
Messages
came
back
as
plain
text
instead
of
Json,
so
that's
already
been
fixed
in
rc2.
That's
right.
The
validator
picked
up
up
that
error.
The
validator
text
that
it
returns
a
proper
error
message
when
you
generate
an
invalid
you're
out.
E
C
We
just
discovered
yesterday,
while
working
on
a
task
for
4.0
that
we're
not
actually
handling
the
1.1
spec
exactly
correctly
and
so
I'm
curious
that
no
one's
actually
ran
into
that.
So
that
part
of,
like
hey,
did
anybody
actually
notice,
but
we
wish
you
know
we're
working
on
a
fix
for
that,
but
that's
currently
not
even
in
there.
But
it's
curious
whether
anyone
even
even
even
notices
that
you
know
I,
think
in
general,
clients
of
hup
are
fairly
forgiving
of
not
exactly
adhering
to
the
spec,
and
so
you
know.
D
B
B
B
Only
other
thing,
I'll
mention
is
that
we
are
working
on
a
document
to
actually
catalog
and
outline
how
the
crypto
extensions
that
we've
released
across
the
last
two
versions
of
CDT
can
be
utilized
and
I'm
happy
to
share
that
with
this
group
once
I
have
it
it.
We
didn't
have
it
for
this
release
specifically,
but
since
we've
had
a
couple
of
waves
of
releases
there,
it's
Justified
pulling
together
some
materials
there
and
I
think
some
people
will
find
it
interesting.
B
A
A
G
A
A
B
B
I
know
there
have
been
some
changes
made
in
the
past
even
by
people
on
this
call
to
help
make
aspects
of
it
more
performant
by
making
it
multi-threaded,
but
a
lot
of
just
how
peers
are
appropriately
managed,
as
well
as
just
any
sort
of
internal
configuration
settings
that
somebody
May
set
for
net
plug-in
and
related
pieces
of
the
software.
I
have
been
pretty
feature
limited
to
date.
B
Also,
just
the
experience
of
actually
like
locating
and
connecting
to
peers
is
not
a
user-friendly
process
to
date,
and
in
the
summation
of
all
of
that,
the
antelope
Coalition
sought
to
vote
up
improvements
to
the
P2P
thinking
process
as
a
priority
and
back
in
I
guess
it
was
mayor.
So
we
collaborated
closely
with
oci
to
kind
of
develop
some
some
pretty
Advanced
requirements
there
that
were
pretty
far-reaching
in
scope.
B
Quick
is
I'll
drop
that
first
link
for
the
RFP
just
for
everyone's
awareness.
Whenever
we
publish
a
new
RFP
if
you're
not
already
aware
it
is
accessible
inside
of
the
Coalition
rfps
subdirectory
inside
of
the
EOS
Network
Foundation
organization,
we've
been
historically
uploading
these
as
PDFs
and
the
entire
process
by
which
you
can
actually
like
bid
on
and
interact
with
us
is
outlined
in
these
documents.
B
Since
we
went
back
to
the
the
drawing
board,
we
decided
to
slim
down
the
scope
so
that
we
could
actually
deliver
something
that
the
Coalition
felt
comfortable
with
from
a
timeline
and
cost
perspective
based
off
the
different
priorities
that
we
were
attempting
to
balance,
and
one
of
those
bite-sized
chunks
that
was
identified
was
the
peer
node
Discovery
process
since
that
time,
in
a
separate
RFP
has
been
published,
which
I'm
linking
here
right
now,
that's
a
Consolidated
document
or
I'm.
Sorry,
a
it's,
a
kind
of
scope,
cut
back
document.
B
That's
what
we've
officially
submitted
as
of
Monday
for
people
to
submit
their
intent
to
bid
and
inside
of
this
RFP
dock
itself,
there's
been
a
few
updates
to
the
requirements
in
terms
of
the
bidding
process
itself.
That's
stuff!
We
don't
really
need
to
go
into
today.
But
if
anyone
has
any
questions,
you
can
of
course
contact
people
at
the
enf
and
we
can
give
you
the
clarity
that
you
may
be
seeking
there
where
this
has
left
us.
B
Is
that,
of
course,
we're
addressing
this
peer
Discovery
aspect
of
P2P,
but
it
doesn't
directly
acknowledge
a
lot
of
those
improvements
that
we
could
actually
make
to
to
net
plug-in
and
I.
I
know
that
part
of
why
we
did
this
whole
separation
is
that
we
actually
tried
to
keep
the
peer
Discovery
process
and
the
improvements
related
to
it
as
minimally
invasive
to
net
plug-in
as
possible.
B
There's
a
few
areas
where
I
think
we're
going
to
inevitably
have
a
little
bit
of
need
to
do
a
few
changes
there,
but
the
entire
idea
was
like:
can
we
ship
this
thing?
That's
kind
of
Standalone
having
value
and
on
a
much
shorter
timeline,
while
simultaneously
we're
trying
to
build
a
better
understanding
of
those
net
plug-in
improvements
that
we
believe
at
this
time
we
can
accomplish
incrementally,
and
some
of
those
things
may
become
rfps
themselves
in
time,
and
some
of
them
may
actually
just
be
ingested
by
the
enf
internally.
B
That
I
think
that
we've
identified
is
just
management
of
those
connected
peers
when
they're
performing
like
known,
undesirable
or
maybe
even
malicious
behavior.
That's
not
adding
value
in
terms
of
us
performing
quest
to
that
peer.
So
I
think
that
that's
a
lot
of
like
where
we
started
it
and
where
we're
headed
and
I
didn't
really
touch
on
some
of
the
pieces
that
were
in
the
original
RFP
related
to
swarm
downloading.
Just
because
those
things
I
think
are
even
a
further
Evolution
pass.
B
One
piece
of
awareness
that
I'll
just
share
with
everyone
on
the
call
is
that
we
actually
have
an
additional
product
person
on
the
call
today
from
the
enf
in
the
form
of
Brian
Hazard
Brian
has
worked
in
and
around
eosio
and
Antelope
in
different
capacities
at
Block,
Run
and
voice
historically,
and
he's
joining
us
this
week
and
I
believe
that
he'll
have
some
closer
Focus,
specifically
around
groups
like
BPS
exchanges
and
token
holders
to
account
capacity.
So
he'll
be
part
of
this
discussion
actively.
B
You
just
hear
me
talking
today
because
he's
a
three-year-old
baby
and
he's
gonna
be
a
Baby
Genius
by
as
soon
as
next
week,
but
just
wanted
to
give
you
guys
that
awareness
that
name
that
face
because,
of
course,
he'll
be
talking
to
you
guys,
a
good
bit
more
and
we'll
be
working
together
closely
as
a
team
to
really
start
wrangling.
A
number
of
these
initiatives,
so
I
guess
I'll
open
up
to
questions
after
I
dumped
all
that
context
and
then
I
guess
we
can
discuss.
A
B
Absolutely
correct
and
I
apologize
if
I
added
any
confusion
there.
So
if
you
look
at
the
structure
of
like
the
actual
sequence
of
events
for
both
of
these
rfps,
the
original
RFP
that
I
shared
those
sequences
of
events
have
already
come
to
pass
and
there's
no
longer
a
window
to
bid
on
that
larger
RFP.
B
We've
since
done
a
revision
and
introduced
this
newer,
smaller
RFP
I
was
kind
of
trying
to
tell
the
story,
because
I
guess
I
have
this
awareness
that
peer
Discovery
and
management
is
perhaps
less
critical
to
some
of
the
people
on
this
call.
Just
because
my
understanding
is
that
a
lot
of
the
BPS
will
already
have
a
list
of
peers
that
they
wish
to
connect.
F
B
D
Correct
and
it
kind
of
came
up
just
because
you
know,
as
the
Coalition
Loops
back
around
and
you
know,
starts
all
right,
I
hear
you
guys
screaming
about
peer-to-peer
and
then
sees
you
know
either
one
version
or
second
version
of
the
the
proposal
and
whatnot.
You
know
they
don't
really
that
just
kind
of
yell
or
I
don't
know
y'all
keep
screaming
peer-to-peer,
but
there's
so
many
different
aspects
so
that
had
at
least
in
one
scenario,
I
think
kind
of
gotten
lumped
in
as
the
replacement
for
hey
you
know,
y'all
have
been
screaming.
D
This
is
what
you
want
right,
yo!
No,
we
want
it.
I
mean
it's
a
valid
piece,
but
it
wasn't
exactly.
You
know
just
kind
of
clarifying
the
well
the
Nerds
kind
of
yeah.
That's
great.
We
don't
have
to
deal
with
all
of
that
anymore,
but
you
know
it's
still
inefficient.
It's
still,
you
know
has
has
a
lot
to
be.
D
You
know
they
could
probably
be
fine-tuned,
and
now
it
really
starts
to,
in
my
opinion,
bleed
heavily
into
other
initiatives
like
the
trimming
of
logs,
and
you
know
even
overall
infrastructure
like
we
talked
about
you
know
stacking
nodes,
and
does
every
node
really
have
to
have
everything
or
down
the
road?
You
know?
Can
it
be
much
more?
You
know
Administration
friendly
load-friendly
type
of
thing,
so
that's
kind
of
how
at
least
I
got
to
him
this
path,
to
bring
it
up.
B
Right
and
I
think
that
that's
kind
of
the
idea
of
like
this
first
stage
of
what
I'm
referring
to
we
may
change
the
name
of
this
over
time
as
net
plug-in
incremental
improvements.
I
think
this
idea
of
a
block
buffer,
as,
as
we've
been
calling,
it
is
kind
of
alluding
to
to
what
you're
thinking
of
in
terms
of
just
alleviating
some
of
the
pain
around
how
some
of
these
different
things
are
being
managed.
B
I
I
can't
act
like
I'm,
too
much
of
a
Smee
beyond
the
degree
to
which
I've
expressed
so
far,
but
I
did
just
want
to
share
that
awareness
that
peer
Discovery,
I,
think
is
adding
value
for
other
groups,
maybe
a
bit
more
so
than
the
BPS
directly,
and
that's
why
we're
kind
of
trying
to
have
this
conversation
of?
Why
not
both
pursuant
of
this
RFP,
while
also
addressing
these
incremental
improvements
that
we
can
tackle
by
collecting
these
requirements
via
discussion
today,.
D
He
just
ask
the
same
people
twice
you
know
or
or
you
know
you
have
two
different
people,
the
same
question
and
that
may
be
you
know
in
that
board
database
or
or
some
of
that
and
better
handling
of
that
Quagmire
of
data,
but
yeah
there's,
there's
lots
and
lots
of
pieces
of
it
and
and
even
probably
gets
down
into
some
of
the
I.
Don't
know
subjective
billing
or
or
you
know,
I'm
I'm,
not
so
sure
people
aren't
smashing
my
peer-to-peer
nodes
with,
like
you
talked
about
undesirable
whatevers.
C
D
C
C
And
over
and
over
right-
and
so
you
know
that
that
is
an
anti-pattern
right,
but
people
don't
like
everyone
needs
to
explain
that
so
instead,
I
think
one
of
the
things
that
we'd
like
to
do
is
is
let
a
node
make
that
determination,
because
one
of
the
problems
right
now
with
the
net
plugin
is
it
has
no
memory
so
like
it.
It
just
simply
does
round
robin
between
all
the
notes
that
it
have.
E
B
C
Node
but
the
next
time
around
it'll
do
it
again
like
it
doesn't
have
any
memory
of
of
anything.
There's
no,
like
State,
that's
maintained
about
yeah.
You
know.
Did
this
thing?
Have
the
block
range
that
I
care
about?
Yes
or
no
it?
How
what's
the
latency
between
B
and
this
other
node,
you
know,
maybe
I
should
go
to
things
that
have
better
latency
than.
E
C
And
I
should
realize
that,
and
like
so
there's
a
little
bit
of
of
state
that
we
can
maintain
a
little
bit
of
some
heuristics.
That
would
greatly
improve
that
that
whole
thing
that
whole
procedure
basically
just
maintain
a
bit
of
State,
which
we
currently
just
do
not
do
so
that
that's
the
sort
of
thing
I
think
that
we
would
hopefully
try
to
address
in
these.
Some
of
these
incremental
improvements.
D
Call
that
Network
yeah
so
would
that
be
like
an
another
I,
don't
know
following
revision.
Okay,
now
we've
done
this
RFP
we've
kind
of
moved
past,
criticality
number
one.
Let's
then
move
to
almost
a
subset
of
of
these
net
features
that
we're
trying
to
kind
of
identify
and
I
think.
Maybe
everybody
would
agree,
yeah
peer
Discovery
for
developers,
you
know
I
mean
Corbin
I'm
sure
had
a
hell
of
a
time
coming
in
blind
and
being
like.
Where
do
I
sync,
you
know
I
mean
he
wasn't
here
from
the
very
beginning
to
know
everybody
right.
D
So
that's
definitely
number
one
I
don't
want
to
hamper.
You
know
we
don't
want
to
hamper
any
developers
but
number
two.
Would
you
then,
down
this
same
path?
Just
keep
kind
of
pursuing
this
cool
we've
knocked
that
one
hopefully
off
the
list,
or
at
least
the
gears
are
going
and
then
put
another
RFP
out
to
try
to
tackle.
Maybe
this
state
of
peer-to-peer
and
tackling
that
inefficiency
and
then
okay,
cool
we've
got
an
idea
with
that
and
then
moving
to
the
next
phase
is
that
kind
of
how
you're
envisioning
this
whole
net
plug-in
micro
features.
D
B
B
The
other
thing
that
we've
identified
as
an
opportunity
is
to
address
these
net
plug-in
incremental
improvements.
These
are
things
that
we
believe
the
enf
can
ingest
internally,
the
capacity
to
which
we
actually
commit
to
and
take
action
against.
That
is
still
to
be
determined
and
we're
at
the
phase
right
now,
where
we're
really
defining
the
requirements
so
that
we
can
justify
and
prioritize
those
items
appropriately,
but
strategically.
The
idea
around
the
peer
Discovery
initiative
was
to
keep
it
minimally
invasive
in
its
relation
to
net
plug-in,
so
that
these
things
could
possibly
happen
in
parallel.
B
There's
been
no
commitment
on
development
of
any
of
these
things.
Yet,
since
nobody
has
won
the
bid
for
peer
Discovery
and,
of
course,
we're
still
in
the
requirements
Gathering
stage
for
net
plug-in,
but
we
do
believe
that
all
of
these
things
are
important
and
that's
why
we're
working
to
Define
them
right
now.
So
there
is
a
committed
interest
to
gather
these
requirements
and
justify
building
these
Solutions
we're
just
not
at
that
stage
yet
so
kind
of
political
answer,
but
I
hope
it
is
close
enough.
D
D
Also,
you
know
the
fact
that,
and-
and
maybe
this
ties
in
with
it,
that
you
can't
you
know
you
if
you
run
a
peer-to-peer
node,
you
either
have
you
know
no
blocks
really
or
all
the
blocks
and
damn
that's.
You
know
a
a
pretty
big,
decisive.
You
know
difference
between
the
two
of
them
now
on
a
lot
of
different
chains,
so
I
might
put
in
there.
You
know
down
further
down
the
initiative
list
as
we're
I'm,
just
thinking
of
a
spreadsheet
or
project
board.
D
F
Hey
when
I
first
read
the
RFP,
it
was
kind
of
open
to
some
interpretation
because
it
didn't.
It
wasn't
necessarily
built
off
the
back
of
one
of
these
kind
of
conversations,
and
last
last
week
we
said
that
yeah.
We
need
to
have
a
kind
of
conversation
to
further
articulate.
What
exactly
the
ask
is
just
for
my
understanding.
Where
is
the
rfps
someone
already
bidded
and
is
about
to
do
the
work,
and
then
there
would
need
to
be
a
conversation
about
what
it
is
that
they're
actually
going
to
be
doing.
B
E
B
But
technically
this
this
window
is
still
open
it
and
that's.
This
is
kind
of
the
pattern.
Is
that
we'll
be
talking
about
the
RFP
coming
together,
we'll
submit
it
typically
on
a
Monday
and
we'll
give
around
a
week
or
so
time
to
submit
the
intent
to
bid
the
bidding
process?
They're
after
is
a
bit
different
I'm,
not
the
owner
of
these
sequences
in
totality,
but
the
other
thing
that
I
can
mention
As
a
detail.
B
Is
that
there's,
of
course,
exception
cases
here
wherein
you
know
if
there's
only
one
bidder,
some
of
the
follow-on
processes
may
be
expedited
because
it's
a
direct
engagement
and
it's
whether
that
person
wins
the
bid
or
not
versus
whether
or
not
like
one
person
wins
a
bit
over
another
person.
So
I
hope
that
that's
giving
some.
F
H
Why
are
the
road
Define,
but
let
me
interrupt
you
a
little
bit.
This
RFP
has
an
exact
scope
in
it,
we're
talking
to
you
because
there
will
be
follow-on
rfps.
This
RFP
is
half
the
size
of
the
previous
RFP
and
has
half
the
scope
of
the
original
RFP
for
p
to
P.
So
we
reduce
the
scope
in
order
to
get
the
price
down
in
order
to
make
more
competitive
bids.
We
have
two
teams
that
have
already
indicated
they
will
bid
on
this
risk
of
reduced
scope
RFP.
H
But
why
do
we
want
to
talk
to
you
and
get
your
input
well
in
the
old
days
block
one
wouldn't
do
that
because
they
didn't
want
to
admit
they
had
anything
to
do
with
EOS
mainnet.
We've
now
got
two
product
managers
on
board.
We
we
want
to
encourage
the
community
to
start
giving
feedback.
I
saw
you
were
very
interested
a
couple
of
weeks
ago,
Michael
and
that's
why
we
thought
yeah,
let's
get
Ross
and
Corbin
on
the
call.
H
H
Looking
for,
because
this
is
most
about
peer-to-peer,
Discovery
and
maybe
there'll-
be
some
enhancements
on
peer-to-peer
discovery
can
come
in
a
follow-only
or
release,
or
we
can
even
you
know,
discuss
with
the
winner
of
the
bid,
but
you
know
there's
things
the
part
we
took
out
of
the
previous
RP
was
the
Swarm
download
part,
but
there
might
be
whole
topics
on
on
P2P
that
just
aren't
even
covered
in
the
original.
If
you
read
the
original,
which
was
mostly
what
this
is
plus
one
download
or
not,
you
know
not
even
covered
in
just
this.
H
This
peer
Discovery
portion
of
this
one
so
because
there
will
be
follow
on
because
likely
we
will
engage,
whoever
wins
the
contract
to
do
some
maintenance
work
at
a
time
and
material
Level
afterwards.
You
know.
Let's
say
we
missed
something
in
this,
but
we
get
enough
good
feedback
from
all
of
you
on
just
the
peer
Discovery.
H
We
say
to
the
team
that
won
the
bid
that
rewrites
it
we
say,
hey
on
a
time
and
material
basis,
the
Coalition,
the
Coalition
or
even
maybe
just
the
enf
is
willing
to
pay
for
these
two
enhancements
to
be
done.
So
that's
why
we're
really
talking
to
you
we
want
to
hear
like
hey
did.
Did
we
miss
the
mark?
Like
hey,
we
had
a
bunch
of
people
that
had
contributed
to
what
should
be
in
this,
but
we
didn't
have
you
so
now.
F
I
I
appreciate
what
she's
saying
tit
and
I
totally
get
it,
but
I'll
give
you
two
examples:
I
mean
when
I
first
looked
at
the
it
was
more
of
the
RFP
was
presented
to
me
as
look
at
this
RFP.
Can
you
review
it
and
I
reviewed
it
as
an
from
an
RFP
creation
side,
not
a
response
side
and
I
know.
You
say
that
that
wasn't
the
goal
so
I
I
know
I,
know
sorry.
This
was
about
a
month
ago
yeah.
It
came
at
first
because
that
was
not
the
request.
F
Yes,
yes
and
I
get
that
I.
Don't
understand
that,
but
this
was
about
a
month
ago,
yeah
and
I
know
I
know.
You
said
this
is
pretty
locked
down,
but
I
mean
I'll.
Give
you
two
examples
of
something
that
makes
it
open
to
interpretation.
The
first
one
isn't
somewhere
written
here.
It
says
we
want
to
reduce
the
amount
of
steps
that
it
takes
in
order
to
do
a
peer-to-peer
session,
or
it's
something
on
that
kind
of
language.
It's
written
there.
So
what
does
that
mean?
F
Does
that
mean
that
if
there
are
seven
steps
and
now
there's
six
steps?
Is
that
a
tick
in
the
Box
another
thing
was,
it
has
to
be
backwards
compatible?
Does
that
mean
that
it
has
to
run
in
the
same
plugin
function
or
could
it
be
another
function
that
could
run
at
the
same
time
and
they're
both
running
on
the
same
notice,
node?
So
hey
what.
F
H
Mean
maybe,
and
that's
right
now,
that
we
have
you
guys
and
we're
starting
to
engage
you
a
little
more
deeply
will
involve
you
before
we
issue
the
RFP,
though
this
RFP
was
issued
by
the
time
you
guys
were
kind
of
looking
at
it
or
was
agreed
to
so
what
we
will
do
moving
forward.
That's
why
we're
starting
to
collect
feedback
from
you
now
and
then
what
we'll
do
is
we'll
work
with
you
guys
before
we
issue
the
next
RFP
to
say.
H
Okay,
here
we
go
we're
about
to
this.
Is
the
rough
draft
of
it.
Give
us
feedback
where
you
think
the
wording
is
too
loose
or
too
ambiguous
and
we'll
tighten
it.
We,
we
don't
believe
we're
at
Perfection
or
even
close
to
it,
we're
just
hoping
that
each
iteration
we
get
better
and
better
and
your
feedback
and
your
input
will
help
us
do
that,
so
that
that's
really
the
goal
is
to
listen
to
you.
Guys
now
start
to.
H
You
know
collate
all
of
the
information
that
you're
providing
back
to
us
make
the
process
changes
like
you're
you're,
pointing
out.
We
need
a
process
change,
I
agree
with
you
we'll
do
that.
We
also,
though,
want
your
requirements
inbound,
but
then,
when
we
write
the
RFP,
we
now
have
a
larger
group
of
people
that
can
give
feedback
of
this
section's
too
ambiguous
this
this
this
requirement,
this
technical
requirement
or
business
requirement,
is,
is
too
ambiguous
as
to
how
you
would
achieve
it
and
we'll
we'll
tighten
those
things
down.
So
thank
you
for
that
input.
F
H
Oh
I'm
saying
thank
you.
Thank
you
for
this,
because
this
will
make
us
better.
I
mean
we've.
You
know
we're
all
kind
of
new
at
this
as
well
and
we're
you
know,
working
kind
of
of
quickly,
with
actually
still
pretty
small
teams
and
in
terms
of
the
you
know,
Steven
is
like
a
was
a
part-time
product
manager,
so
you
know
he
was
doing.
Maybe
20
or
25
percent
of
his
job
was
to
kind
of
help
on
these
things.
F
A
B
Yeah
I
was
going
to
add
that
color
and
then
the
only
other
thing
I'd
say
is
just
it's
always
going
to
be
a
little
bit
of
a
tug
of
war
game
with
us
kind
of
over
prescribing
the
solution
in
the
RFP
itself
versus
really
starting
with
the
problem,
and
we
as
product
people
who
are
authoring
the
requirements.
Here
we
want
to
communicate
what
we
believe
is
directionally,
like
the
problems
we're
trying
to
solve,
and
we
want
the
respondents
to
really
give
us
a
solution.
B
So
just
taking
the
example
of
like
reducing
the
number
of
steps.
Well,
we
believe
that
directly,
that's
a
place
where
we
can
improve,
but
you
you
know
a
solution
that
only
reduces
One
Step
may
actually
in
totality
be
a
better
solution
than
one
that,
like
cuts
down
way
more
steps,
but
is
a
less
eloquent
solution
right.
B
So
we
want
to
give
you
guys
directions
and
like
the
right
sandbox
to
play
in
as
respondents
and
we'll
tune
it
to
get
more
specific
over
time
where
it
needs
to
be,
but
there
will
also
be
a
desire
from
at
least
the
product
side
of
the
house
to
keep
it
a
little
bit
open
so
that
you
know
Engineers
can
do
what
they
do
best,
which
is
come
up
with
amazing
ways
to
solve
user
problems
with
technology.
So
it's
it's
always
going
to
be
a
little
bit
of
some
Dynamic
there.
D
Well,
I
mean
like
exactly
starts
on
that
I
mean
that's
I
personally,
think
I
mean
it's.
A
good
start
may
not
be
the
perfect
paying
Lessons,
Learned
or
whatever,
but
I
think
everybody
kind
of
agrees.
Discovery
for
General
Pope
might
be
something
quicker
and
easier
to
be
able
to
bite
off
to
and
make
things
better.
D
Is
the
I
don't
want
to
say
intent
of
this
you
know,
but
is
is
one
of
the
the
topics
we
want
to
talk
on.
What
may
be
the
second
or
third
or
fourth,
next
RFP
parallel
whatever
I
mean,
and
yes,
maybe
we'll
be
a
little
more
interactive
in
defining
the
scope
and
and
what
is
backwards
compatible
versus
whatever,
but.
G
D
G
D
You're
going
I
that
that
seems
to
be
where
we're
kind
of
heading
right,
I
mean
let's
get
on
and
talk
about
it.
Let's
engage,
let's
do
whatever
I'm.
Okay,
you
know
I'm
envisioning,
the
Stephen
or
somebody's
jotting.
These
down,
you
know
kinda
all
right.
This
was
one
thing
way
further
down
the
list.
Yes,
yes,
they
kept
babbling,
and
this
is
so.
G
Let
me
let
me
start
like
you
all
know
this,
but
it's
important
to
restate
is
that
we
have
Coalition
or
antelope
prioritization,
and
then
we
have
like
hours
like
you
know
the
EOS
right
our
priorities
and
the
Coalition
is
attempting
to
find
commonalities
between
us,
Telos
wax
and
ux
right.
So
we
can
distribute
the
cost
kind
of
you
know,
and
we
all
get
the
benefits.
G
It's
important
to
keep
that
in
back
your
mind,
because
if
we
go
through
the
Coalition
priorities
and
the
Coalition
doesn't
choose
to
put
something
up
there,
that
this
audience
thinks
is
important,
it
doesn't
mean
we
can't
do
it
just
means
we
would
do
it
independently
of
the
Coalition
and
we
would
do
it.
You
know
directly,
it's
so
kind
of
with
that
in
mind.
If
you
imagine
each
chain
like
has
their
different
communities
and
they
all
have
different
mechanisms
of
how
they're
tracking
their
priorities
I
think
Stephen
would
give.
G
You
know
a
a
much
better
Clarity
on
how
our
chain
is
tracking
our
priorities,
but
what
I
will
do
is
kind
of
pick
up
from
the
idea
of
okay.
We
have
that.
How
does
that?
Like
get
weighed
in
with
the
Coalition
and
and
how
do
they
prioritize
so
kind
of
that's
what
I'll
show
you
guys
now,
let
me
up.
Can
somebody
allow
me
per
to
share
my
screen.
G
So
imagine
two
words:
no
okay,
all
right
where's,
my
there
we
go
all
right
all
right,
so
first
thing
I'll
say
is
we've
already:
we've
done
this
twice
and
we've
changed.
It
we've
improved
it
this
time
and
we
already
have
ways
we're
going
to
improve
this
for
the
next
round.
So
I'm
going
to
give
you
a
general
overview,
but
this
is
already
going
to
change
a
little
bit
for
next
time.
G
You
know
a
long
time
ago
and
then
there's
some
ad
hoc
ones
down
at
the
bottom,
like
we
learned
the
last
time
that
even
with
like
a
list
of
half
of
this,
it
was
just
too
frustrating
to
get
everybody
into
one
place,
and
so
what
each
chain
does
is
say
all
right.
We're
just
going
to
pick
our
top
five
and
so
Eve
will
represent
our
community
and
come
back
and
say
all
right.
Here
are
the
five
that
EOS
wants
to
put
up
as
this
quarter's
nomination.
G
I
want
to
emphasize
the
quarter
Cadence,
because,
honestly,
that's
still
a
little
faster
than
this
community
can
like
build
and
deploy
stuff
well,
I
think
we're
all
getting
better
at
that,
which
is
great
we're
going
to
keep
pushing
at
that,
but
we'd
rather
have
a
backlog
of
knowing
what
our
next
priority
is
than
ever
be.
You
know
stuck
like
you
know,
with
Engineers
out
of
work
and
not
doing
stuff
right.
G
G
So
here
you
can
see
they
just
go
in,
they
add
like
X's
to
the
ones
they
want
to
vote.
You
know
this.
The
way
this
thing's
set
up.
It's
just
you
know,
it
changes
the
number
at
the
top
and
they
can
you
know
so
once
they
all
get
to
five,
then
what
my
team
did
is
we
took
anything
with
an
x
on
it.
We
created
a
new
spreadsheet
and
said
all
right.
G
But
if
you
have
16
votes,
you
can
now
like
spread
them
out
and
say
well
number
one
is
really
important,
so
I'm
going
to
give
it
eight
votes
and
then
I'm
gonna
take
my
other
eight
votes
and
spread
that
out,
and
you
can
kind
of
see
that
hearing.
You
know
some
examples
and
then
that
gets
up
to
the
you
know.
Each
chain
does
their
16
votes
and
then
we
totaled
that
up
at
the
end
and
that's
how
we
ended
up
with,
in
this
case,
four
rfps
that
are
going
out.
D
C
D
The
way
it
kind
of
came
and
and
part
of
you
know
what
we're
figuring
it
out
like
Wax,
you
know,
obviously
they
have
their
core
team
and
their
initiatives
and
what
they're
you
know,
obviously
paying
and
working
towards
seeing,
but
they
then
reached
out
to
the
BPS.
You
know
from
the
technical
side
and
said
here's
the
list
of
all
the
initiatives.
Oh
my
God,
you
know
and
tried
to
get
some
feedback
and
of
course
it
was,
you
know,
archaic
and
Technical.
D
D
D
You
know
technically,
what's
needed,
you
know,
they'll
tell
you
from
a
pretty
hands-on
experience
versus
like
Wax,
who
has
really
no
clue,
it'll
go
out
and
ask
the
same
people,
but
then
to
see
how
it
kind
of
transposed
across
and
and
whatever,
but
now
also
seeing
that
all
right,
I
know
who
to
tell
what
and
just
keep
getting
more
votes
or
is
it
better?
Maybe
there's
because
y'all
have
not
tracks
what
are
they
called
the
different
initiatives
or
whatever?
Maybe
there
is
all
right?
D
We
want
this
to
kind
of
be
an
infrastructure
VP
slot
for
one
of
the
five
votes
or
something
like
that
right,
maybe
some
clarification
to
give
them
more
of
a
all
right.
Y'all,
come
to
a
consensus
and
figure
out
what
our
VPS
want
to
say
and
each
chain
can
do
it
differently,
but
it
was
just
interesting
to
see
you
know.
D
I
mean
there's
still
that
discombobulation,
because
they
don't
do
infrastructure,
they
let
the
BPS
do
it,
but
they're
the
ones
that
you
know
have
the
highest
priority
and
they
wanted
to
make
sure
I
mean
they
were
trying
to
do
the
right
thing
right,
hey
Lucas!
Is
you
know,
here's
the
list
guys?
What
do
you
want
me
to
vote
for.
F
Why
don't
we?
Why
don't
we
talk
about?
Obviously
the
the
peer-to-peer
Discovery?
We
love
it,
even
though
all
the
BPS
would
use
it.
It's
definitely
something.
That's
gonna
help
everybody
spin
up
a
node
and
get
things
going.
Maybe
we
should
talk
about
some
of
the
other
features
that
we
feel
some
of
that
optimizations.
F
B
I'll,
just
chime
in
and
say
that
I
think
the
purpose
for
discussing
with
this
group
is
focused
on
those
net
plug-in
oriented
enhancements
that
we
haven't
really
dug
deep
into
yet
with
the
peer
Discovery
P
oriented
stuff,
like
we've
submitted
that
RFP
to
the
public
already
so
I
think
feedback.
There
is
valuable,
but
the
thing
that
I
think
is
the
most
important
with
this
group.
H
Agree
and
I
think
that
would
be
if
people
want
to
come
back
next
week
and
we
make
that
kind
of
a
piece
of
the
focus
and
we
can
go
into
and
really
what
we're
going
to
ask
you
to
do
it's
it's
not
as
much
about
reviewing
this
RFP,
it's
about
giving
us
your
forward-looking
requirements
to
that
you'd
like
to
see
in
the
next.
You
know
add-ons
after
this
RFP
was
done,
like
additional
requirements
for
net
plug-in
type
of
enhancements.
F
D
To
show
up
I
mean
show
up
to
do
whatever,
but
try
to
have
what
your
version
of
you
know
the
next
five
net
peer-to-peer
feature
requests
would
be
knowing
some
of
them
are
look.
These
are
just
really
really
wannabes
way
down
the
road,
but
Men
start
to
kind
of
I
Collapse
into
an
overall
list
and
I
like
to
see
the
commonalities,
but.
H
D
That's
kind
of
how
you're
thinking
and
going
and
I'm
excited
about
it
like
say,
I,
think,
that's
the.
What
do
you
guys
think
all
right,
let's,
let's
find
the
commonality
and
put
that
as
the
next
RFP,
parallel
sequential
whatever
so
I'm
still
excited
it's
good
to
see
how
the
process
and
stuff
works,
though,
and
figure
it
out,
because
all
these
chains
are
really
different,
we're
all
the
same
people,
but
they
all
function
a
lot
different.
You
know
this
is
cool.
H
A
To
do
that
yeah,
so
I'll
extend
it
and
I'll
I'll
make
sure
whatever
bullet
points,
Steven
prepares
in
the
channel,
I'll
I'll
add
it
to
the
summary
also
for
this
week,
and
so
everyone
paying
attention
there
can
just
don't
know
what
to
expect
for
next
week,
and
maybe
we
can
continue.
It
seems
that
this
is
working
today.
We've
got
looking
at
14
people
we're
up
from
11
last
week,
I
think
10
the
week
before.
So
the
momentum
seems
to
be
collecting
here.
A
All
right,
maybe
we
can
leave
it
there
and
yeah
I'll
touch
check
in
on
on
the
I
guess:
Steven
you'll
post
your
bullet
points
in
the
Antelope
leap
upgrade
telegram
Channel
we
may
have
to
actually
I
was
talking
to
to
Lovejoy
about
this.
It's
this.
This
meeting
seems
to
have
evolved
a
little
bit.
We're
not
so
much
a
leap
upgrade
call
anymore.
A
H
D
H
E
D
The
15
minute,
you
know,
I
mean
weekly.
Let's
manage
EOS
figure
out
where
it's
at
give
some
directives
to
you
know
the
jungle.
Bps
hey.
We
really
want
to
test
this.
It's
important
to
us
from
EOS
standpoint,
but
I
love
these
technical
Roundtable
discussions.
I
think
we
can
get
more
people
in
half
of
it's
figurines
now
other
house
and
the
do.
A
H
Make
a
different
form
for
that
I'd
like
to
keep
this
node
operators
and
node
upgrades
and
because
we'll
use
this
one
when
we
start
to
move
to
the
next
consensus,
upgrade
and
stuff
3.2
is
coming
out.
But
it's
you
know
it's
an
elect.
You
decide
if
you
want
to
upgrade
or
not,
there's
no,
you
know
m-sig
or
big.
You
know
like
countdown
date,
but
I
think
this
has
been
a
really
good
slot
that
everyone
knows
so.