►
From YouTube: 2022-11-28 IPFS Content Routing WG #1
Description
Sync of those involved with creating IPFS Content Routing Proposals. Meeting #1
Notes:
https://www.notion.so/pl-strflt/2022-11-28-Content-Routing-WG-kickoff-mtg-89c5ab58e31f4771b98747edd3b73b26
For more on the IPFS Content Routing workgroup including calendar information see:
https://www.notion.so/pl-strflt/Content-Routing-Workgroup-e59fa94a9c3f48d58480b7daf15bd356
Website: https://ipfs.io/
Twitter: https://twitter.com/IPFS
A
B
B
A
B
And
then
I'd
encourage
everybody.
If
you
have
read
through
these
notes
already,
you
have
comments
or
issues
that
you
want
to
bring
to
the
table.
There's
a
section
down
at
the
bottom
here
called
top
of
mind
for
team
contributors.
You
can
go
ahead
and
punch
anything
in
there
during
the
meeting
and
we'll
try
to
get
to
all
that
stuff
before
the
end
of
the
meeting.
B
B
B
But
basically
the
purpose
of
this
meeting
y'all
is
to
kind
of
conclude
the
decisions
we
need
to
make
in
order
to
kind
of
design
the
MVP
for
the
interaction
between
integrating
the
indexer
into
Google
nodes,
and
so
we
need
y'all's
support
to
kind
of
nail
down.
What
are
the
outline
items
that
will
enable
us
to
do
this?
Any
blockers
for
decisions
that
we
need
to
cover
and
then
support
work
for
any
information.
B
And
then
one
of
the
components
of
this
that
we're
going
to
be
discussing
is
double
hashing,
they're.
Technically
two
documents
on
this
right
now,
but
I'd
like
to
point
you
towards
the
one
with
the
hourglass
here.
This
documents
had
some
pretty
recent
revisions,
which
include
more
detailed
kind
of
components
of
our
approach
and
The
Leverage
kind
of
comparison
that
we're
making
on
how
to
proceed
with
this
decision.
So
I
think
you
all
will
find
that
document
to
be
very
relevant.
B
I
threw
the
link
to
some
contact
up
in
here,
just
in
case
anybody.
That's
watching
kind
of
wants
to
follow
along
and
isn't
familiar
with
that
stuff
and
then
there's
this
ipfs
asynchronous
discussion
with
leadership
on
Kubo
integration,
which
is
ultimately
the
decision
document
that
we're
hoping
to
inform
so
that
our
leadership
can
kind
of
provide
a
path
forward.
C
In
this
whole
Endeavor
was
first
about
getting
gateways
to
be
talking
to
cid.contact
by
default,
and
we
first
did
that
with
the
reframe
in
that
process,
and
shortly
afterwards
we
discovered
the
problems
with
the
reframe
API,
which
is
where
all
the
work
has
been
to
get
to
the
just
generic
HD
or
get
to
the
HTTP
delegated
routing.
Api
I
don't
want
to
make
sure
we
kind
of
close
out
on
that
guy
two.
C
Okay,
so
I
guess
I
think
a
couple
things
for
people
to
be
aware
of
well
I
think
it
also
probably
applies
to
a
Content
routing
working
group.
I
think
it's
probably
most
people
aware
we
are
doing.
We
are
dialing
down
the
non-bridging
portions
of
the
hydras
on
Thursday,
you
know,
probe
lab
is
leading
that
effort
in
terms
of
the
communication
and
all
the
monitoring,
and
we
folks
like
Gus
and
Antonio,
will
be
doing
the
actual
Hydra
deployments
for
that
for
that
work
and
the
only
change
we're
making
here
is.
C
Basically,
you
know
severing
the
database
connection
between
the
hydros
and
the
UI
dynamodb.
We're
not
doing
anything
else,
especially
here
we're
not
trying
to
minimize
responses
or
anything
we're
only
not
we're,
basically
we're
turning
empty
results,
but
we
will
be
returning
results.
They'll
just
be
empty
set,
so
that's
happening
on
Thursday
as
a
result
of
that,
problab
has
requested
that
we
not
do
any
other
Hydro
deployments
beforehand
or
afterwards
for
some
number
of
days,
so
they
kind
of
have
a
stable
environment
for
them
to
be
monitoring
the
network
as
a
result.
C
C
D
I
mean
we
can
do
it
quite
quickly.
We
have
had
a
draft
PR
of
the
addition
of
this
HTTP
delegated
thing
for
10
days
and
are
waiting
for
code
review
that
we
Linked
In
This
content
writing
working
group
slack
channel.
So
no
one
has
commented
or
approved
that
PR
okay
to
confirm
that
we
have
it
compatible
with
the
spec
that
you
guys
have
LED.
C
Cool,
okay
and
so
I
guess
the
we.
Obviously
we
have
been
working
on
a
I
guess
on
a
practical
matter.
Obviously
we
have
been
working
on
a
a
go
implementation
of
the
spec,
we're
actually
planning
to
move
that
not
we're
not
planning
to
put
that
into
the
go
delegated
Road
and
repo
we're
actually
going
to
put
that
into
the
lib
ipfs
repo,
so
that
things
like
hide
like
our
hydras
can
have
both
deployed
at
the
same
time,
because
it's
because
we
won't
hit
go
minor
version.
C
You
know
issues
because
it'll
actually
be
a
separate
repo.
That's
what
we're
planning
to
do
on
the
hydras
I
guess
if,
if
cid.contact
wanted
to
use
that
they
could
but
I
guess,
obviously
it's
totally
fine
for
you
all
to
do
your
own
implementation,
I!
Guess!
What's
our
preferred
path
forward
here,
keep
you
know
supporting
bedrock's
own
implementation,
or
should
we
try
to
consolidate
on
the
live
ipfs
version.
D
Foreign
having
multiple
implementation
like
having
us
own,
it
means
that
we
will
debug
the
server
side
and
understand
it
rather
than
like
punching
it
back
to
you
guys
in
some
sense-
and
this
is
meant
to
be
a
pretty
simple
rest
one.
It
was
quite
simple
for
us
to
take
our
current
fine
thing
and
and
have
an
adapted
version
that
was
compatible
with
your
semantics,
as
proposed
in
the
spec,
and
so
in
the
same
way
that
we
found
that
that
initial
rest,
HTTP
API
was
pretty
minimally
painful.
I.
Think
it's
easier.
C
C
D
D
C
Great
so
just
yeah
timeline
wise,
so
we'll
get
the
go,
delegated
routing
changes
released
and
merged.
Today,
again
that'll
happen
in
lib
by
PFS,
not
in
this
repo
we're
not
like
we're,
not
gonna,
deploy.
Well,
sorry
we'll
make
the
changes
in
hydras
and
then
deploy
them
on
the
eighth
obvious
I
think
sometime
this
week,
we'll
get
the
CID
contact
changes,
merged
and
then
I'll.
C
Let
you
all
do
a
deployment,
so
I'll
update
the
dates
here,
but
we'll
assume
this
is
happening
by
end
of
week
and
then
we
also
have
to
make
the
changes
in
Kubo
itself,
which
will
you
know.
Antonio
is
working
on
right
now
and
it's
not
obviously
it's
not
it's
not
done
yet
I,
don't
know
I'm,
assuming
we're,
probably
looking
at
near
the
end
of
the
week
as
well
on
this
guy.
C
We
didn't
actually
ask
him
today
earlier,
but
that's
I,
don't
know.
The
point
is
like.
The
key
thing
we
wanted
to
make
sure
is
that
this
gets
out
with
the
this
gets
out
with
the
next
Kubo
release,
which
we're
going
to
be
doing
the
release
candidate
on
the
8th
and
doing
the
final
release
the
following
week.
Before
we
all
break.
C
D
Yeah,
the
the
one
other
fun
thing
was,
the
it
turned
out.
Bifrost
didn't
prioritize
doing
the
direct
connection.
We
we
pinged
them
at
the
beginning
of
this
week
again
and
they're
they're,
going
to
see
if
they
can
also
get
the
direct
connection
from
gateways
to
Sid
contact
actually
running
this
week.
But
we'll
see
so
you
know
we
would
have
liked
that
before
the
hydras.
It's
a
shame
that
it
you
know
we
had.
We
ended
up
with
two
months
where
that
didn't
get
rolled
out,
that
config
change.
C
God,
oh
God,
okay,
yeah
that
sorry
I
I've
actually
meant
to
start
with
that
to
see
where
that
was
actually
at
because
hey
I
was
looking
at
the
config
yesterday
and
I
didn't
look
like
any
of
it.
Had
it
only
been
on
like
one
or
two
Banks
or
something
right,
they
hadn't
pushed
it
everywhere:
okay,
yeah!
C
D
Right
we
would
like
that
to
happen
before
the
hydro
drill
down
the
dial
down
as
a
way
of
reducing
potential
impact.
There
right
like
that.
That
would
make
us
feel
better
about
hydra's,
changing
configs
in
ways
that
we
don't
know,
because
if
there
are
issues
with
hydras,
it
means
that
we're
not
losing
service
during
the
time
that
we're
spending
we're
figuring
out.
What's
what's
up
so
it
makes
the
the
hydro
changes
like
less
sort
of
critical
and
less
like
scary
to
mess
with
I.
C
C
B
C
Okay,
great
and
I
guess
then.
The
other
thing
that
would
be
ideal
is
right.
When
we
do
the
RC
we
we
do
get
that
RC
deployed
across
bifrost
infrastructure,
ideally
as
part
of
that
we're
also
converting
from
using
well
obviously,
they'll
have
to
kind
of
switch
from
using
reframe
to
the
new
delegated
routing
config
for
hitting
cid.contact
like
I
think
it
would.
It
would
be
great
if
we
can
go
into
the
Christmas
break
where
at
least
the
link
between
the
gateways
and
cid.contact
is
the
way
we
ideally
want
it.
C
A
B
Currently
I
would
say
wrestling
a
little
bit
with
two
options
before
I
get
too
into
the
Weeds
on
this
I
should
give
Ivan
a
chance
to
to
jump
in
and
take
the
reins.
I
think
he's
he's
gonna,
be
our
subject
matter
expert
on
the
topic.
Ivan.
Would
you
care
to
kind
of
provide
a
high
level
summary
for
the
folks
on
the
call
real
quick
of
these
two
options
documented
here.
F
Yeah
sure
so
we
started
thinking
about
how
to
implement
the
double
hashing
story.
On
the
on
the
index's
side
in
the
in
the
main
notion
dog.
That's
about
the
double
hatching
story.
There
is
a
section
about
the
indexes
and
we
started
some
dating
this
section
today.
Basically,
the
punch
line
is
we've
done
some
backup
envelope,
calculation
for
like
how
much
storage
is
going
to
be
required.
Extra
surgical
requires
if
we
were
to
implement
like
the
the
species
and
Etc.
D
Looked
at
this
and
I'm
I'm
I
think
we
need
to
revisit
this
before
we
try
and
get
to
consensus,
because
I
think
it's
much
less
like
we're
already
storing
a
value
that
is
a
pure
ID
context,
ID
as
the
value
and
the
the
encryption
here
is
just
adding
the
small
amount
of
salt.
In
addition,
so
I
don't
think
it's
an
additional
70,
plus
12
plus
eight
bites
I
think
it's
going
to
be
maybe
eight
to
32
bytes
per
record
that
we
end
up
adding
versus
the
code.
Let's.
F
D
I
wanted
to
say
here
was
my.
My
sense
is
that
the
extra
storage
is
not
something
that
we
need
as
indexer
to
raise
the
flag
on
or
I
would
prefer
not
to,
and
just
say
yes,
it's
going
to
be
somewhat
bigger,
but
not
so
much
bigger
that
we
can't
just
encrypt
each
value.
The
I
think
the
main
interface
difference
that
we
need
to
figure
out
is
that
our
values
are
not
directly
pure
IDs.
D
So,
for
instance,
you
know
what
deal
is
this
graph
sync
pure
advertising
to
Sid
Within,
and
so
there's
there's
something
that
comes
back
to
a
client
that
is
encrypted
by
the
Sid?
That
is
not
just
the
pure
writing,
and
so
that's
the
addition
to
the
interface
that
we're
for
delegated
routing
double
hashing.
That
indexing
is
going
to
end
up
sort
of
colliding
with
if
we
use
exactly
the
same
interface
that
the
DHT
double
hashing
is
on.
D
So
I
think
the
question
is:
do
we
just
propose
what
this
additional,
or
what
the
double
hashing
that
works
for
indexing
in
the
context
of
the
HTTP
delegated
routing
API?
Is
you
know
what
how
do
we?
How
do
we
manage
this?
You
know
addition
of
some
additional
context
in
this
proposal
that
indexing
is
going
to
want.
F
B
The
outcome
from
this
is
we'll
we'll
continue.
Iterating
on
this
we've
got
a
little
bit
of
Discovery
to
kind
of
wrap
up
but
asynchronously
the
documents
that
give
you
a
good
General
sense
of
the
direction
we're
taking
with
this
is
available
so
that
you
all
are
welcome
to
kind
of
take
a
look
in
the
time
being
and
then
I'll
take
an
action
item
to
follow
up
on
once.
Decisions
are
made
making
sure
that
y'all
understand
clearly
The
Proposal
that
we're
putting
forward.
G
H
H
D
Have
a
different
model:
it's
not
specific
to
filecoin,
but
it
I
mean
in
that
we're
ingesting
indexes
and
advertisements
from
web3
storage
and
other
ipfs
nodes
as
well
and
ipfs
clusters
and
so
forth.
It's
not
a
put-based
model,
rather
the
indexers
pull
that
content
and
expect
the
publisher
to
be
online
and
available
to
act
as
the
server
that
that
answers
their
requests
for
it.
F
B
I
could
get
confusing
okay,
so
just
to
recap
that
really
quickly
we
we've
got
some
final
ideation
to
kind
of
lock
down
our
our
proposed
method
and
we'd
like
to
propose
a
method
on
the
basis
of
the
research
that
we've
done
so
far.
We
feel,
like
that's
the
quickest
way
to
a
feasible
outcome,
so
as
soon
as
we've
got
kind
of
a
more
concrete,
you
know
proposal
put
together
for
that,
we'll
inform
the
team
and
hopefully
move
forward.
B
B
C
C
B
C
E
B
E
E
E
B
Fair
enough,
so
what
actually
needs
to
happen
here
is:
we
need
to
essentially
kind
of
collaboratively
come
up
with
a
baseline,
for
what
criteria
would
need
to
be
established
to
ensure
that
these
are
met
is.
Is
this
something
that
this
group
perceives?
We
would
seek
like
Community
feedback,
for
instance,
from
service
providers,
or
my
perspective.
That
I
think
would
be
beneficial,
but
also
would
probably
take
a
long
time
or
potentially,
not
necessarily
biases,
towards
action
on
this
discussion.
Can
we
solve
for
this
discussion
internally
among
our
work
groups.
C
C
So
any
of
the
current
indexer
providers
or
people
that
are
coming
on
board,
maybe
as
well.
The
ipfs
operators
channel
is
a
good
place
to
expose
it
again.
I,
don't
think
I
would
block
here,
but
I
think
just
giving
as
long
as
we
have
high
visibility
into
what's
happening
as
we
move
it
forward.
I
think
that's,
probably
okay,.
B
Okay,
so
I
I
won't
volunteer
anyone
for
any
work
on
this
call.
But
let's
take
this
as
a
kind
of
an
asynchronous
action
item
that
we
need
to
kind
of
form,
at
least
a
rough
outline
for
what
our
Baseline
for
acceptance
criteria
would
be
to
integrate
integrate
indexers
into
maintainers.
If
we
need
to
start
like
a
brainstorming
session
with
a
smaller
group
to
kind
of
Kick,
this
off
I
can
organize
that,
but
I
won't
belabor.
This
point
too
much.
What's.
D
E
But
so
this
would
then
be
a
stop.
Gap
then,
until
we
get
so
I
mean
I
wouldn't
spend
a
whole
lot
of
time
trying
to
work
out
a
sorry
little
you're
I
can
barely
hear
you
I
mean
if
it's
just
a
stop
Gap,
then
we
probably
shouldn't
spend
a
lot
of
time
working
out
a
process
and
criteria
and
all
this
stuff
right.
If
it's
just
going
to
be
something
that
we
keep
around
for
a
few
months
and
then
throw
away.
D
G
We
were
talking
about
I,
think
location
in
to
the
Gateway,
so
that
would
be.
These
are
part
of
the
CD
get
parameter
whatever,
but
like
in
the
URL
of
a
Gateway.
You
will
be
able
to
specify
something
like
a
multi-address
that
points
to
someone
that
has
the
data
or
maybe
an
indexers.
That
know
someone
that
points
to
the
data,
and
maybe
that
could
be
the
stop
Gap.
G
G
D
Have
that
I
mean
so
so
I?
Don't
think
that
solves
this,
because
a
we're
going
to
have
the
gateways
all
week
always
always
querying
already,
so
the
gateways
will
always
be
be
looking
that's
happening
like
this
week
or
next
week.
So
we
don't
need
an
additional
hints
at
the
Gateway
level
and
then,
like
the
point,
is
we've
got
more
content
in
the
indexers
already
than
in
the
DHT,
so
that
should
be
a
default
like
it.
D
It's
going
to
location-based
writing
where
it's
only
some
subset
of
Sids
that
are
somehow
communicated
with
an
additional
like
location
hint
where
it's
opt-in
is
weird
when
the
default
of
where
this
sit
is
most
likely
to
be
able
to
be
mapped
to
Providers
is
in
this
other
database.
That's
only
being
opt-ined
like
the
point
is
we
want
to
default,
not
opted
in.
A
B
B
Foreign
thanks
y'all
all
right
next
up
on
the
list,
I
I
brought
this
item
up
just
to
ensure
that
we
had
completely
closed
this
out,
but
I
saw
a
comment
from
Liddell
in
in
slack,
which
was
on
the
ipip337
regarding
the
stats
endpoint
on
current
operators.
Is
this
consistent
across
all
operators?
I
just
wanted
to
make
sure
that
there
wasn't
any
like
additional,
outstanding
or
blocking
work.
B
H
B
H
D
Right
but
but
is
there
a
value
like
for
why
clients
would
want
to
for
why
we
would
put
it
in
the
snack
like
it's
something
we
use
for
monitoring
and
for
like
our
next
web
page,
but
it's
not
something
that
we
have
clients
actually
querying
right
now.
So
if
that
is
the
value
of
it,
then
it's
not
something
that
we
would
put
in
the
spec.
B
A
A
B
H
D
I
guess
are
we?
Are
we
reasonably
happy
on
what
that
proposal
for
Content
writers
is,
and
the
next
step
is
implementation,
or
is
there
more
on
sort
of
like
a
draft
design
dock
that
we
would
want,
and
should
we
do
more
rounds
of
like
trying
to
think
about
what
a
design
would
look
like
before
we
move
to
an
implementation
is
probably
where
we
are
on
on
that
ambient
Discovery
I.
D
Maybe
torfin
is
the
right
person
to
like
think
about
what
to
propose
what
an
MVP
looks
like
in
terms
of
work
items
and
try
and
break
that
down
that
that
seems
like
one
thing,
I
think
the
other
one
is:
what
is
the
work
split?
There
I
think
we.
We
know
that
there's
probably
some
modeling,
that
we
want
to
do.
D
H
H
D
And-
and
we
could
hard
code
like
like
in
the
first
round
like
the
thing
that
we
could
do
in
a
few
months
potentially
is
have
bootstrap
nodes
running
and
advertising
sub
hard-coded
set
of
indexers
yeah
as
the
ones
that
they
know
about.
So
not
do
the
gossip
like
advertising
of
your
own
new
indexer
that
could
be
malicious
yet
and
then
and
then,
at
the
same
time,
figuring
out
some
of
the
like
feedback
loop
through
through
monitoring
or
measurement.
D
H
Yeah
I
don't
know
if
it's
useful,
but
the
Kubo
is
still
always
connecting
to
bootstrap
nodes
that
that's
been
my
understanding,
yeah
yeah.
So
that's
if
we
could
like
Park
solving
that
until
we
have
a
real
Discovery
here.
But
this
way
we,
you
know
we
don't
hardcot
any
strings
in
Kubo
and
we
we
don't
like
the
problem
is
you
know
there
are
different
problems,
but
the
main
problem
is
like
having
clients
being
stuck
on
some
hard-coded
string
and
then
having
to
like
write
migrations.
H
D
Cool
I
guess
I,
don't
know
if
darfin's
going
to
come
back
or
if
his
internet
just
went
out
entirely,
but
we
can
definitely
try
and
like
propose
some
Milestones
of
what
these
various
levels
of
deployment
might
look
like
and
that
that
seems
like
the
The
Next
Step
here
and
I.
Think.
The
other
thing
that
we'll
propose
is
what
that
breakdown
would
be
between
work,
that
we
will
hope
to
get
help
from
or
that
we
think
the
stewards
need
to
own
because
it
is
in
ipfs
or
in
Kubo
directly.
D
So
certainly
the
deployment
but
I
need
to
think
about.
You
know
what
steps
before
that
is
also.
It
makes
more
sense
for
for
stewards
to
own,
but
but
I
think
that's,
that's.
Probably
the
right
thing,
I
I,
think
we're
reasonably
happy
with
the
basic
sketch
where
the
next,
like
the
the
thing
that
would
change
this
design
in
my
head,
is
data
more
so
than
opinions
right
like
we
have
some
uncertainty
of
like.
Does
this
actually
work,
but
the
way
that
we're
going
to
understand
is
it
going
to
be
reasonably?
B
So,
tracking
time
we
actually
landed
right
where
we
were
hoping
with
kind
of
a
wrap-up
section
for
anything,
that's
top
of
mind
for
team
members.
So
this
is
more
of
an
open
pile
for
anybody
that
wants
to
bring
topics
to
the
work
group
that
weren't
referenced
in
these
prior
discussions
on
the
agenda
so
open
to.
If
we
could
start
with
the
ipfs
stewards,
did
you
all
have
anything
to
bring
to
the
work
group?
B
H
We
don't
have
that
flexibility
with
a
partner
like
brave
brave,
is
running
kubernetes,
but
they
essentially
have
hard-coded
configuration
there,
which
their
security
team
reviewed
and
they're
very
skittish
around
things
like
DNS
privacy
leaks,
anything
that
smells
like
leaking
user
browsing
history.
Even
if
there
are
three
layers
of
indirection,
it
will
be
problematic,
even
if
it
finally
passes
it
will
be
very
slow
to
go
through
review,
so
I
just
wanted
to
flag.
H
So
this
group
is
cognizant
that
it's
not
like
stewards,
just
pushing
pushing
some
things
for
the
sake
of
pushing,
but
it's
like
actual
limitation
we
may
hit
with
Partners.
So
it's
good
to
have
at
least
have
answers
or
like
a
plan
of
the
roadmap.
Just
like
will
said
it's
fine
to
do.
Some
compromises
with
like
bootstrappers
having
hard-coded
lists
and
not
having
like
any
reputation
system
yet
and
then
doing
the
next
stage.
But
you
know
having
that
plan
we'll
make
some
discussions
way
easier.
H
B
Thanks,
that's
actually
I
think
really
valuable
context
for
everybody
on
the
call.
It
helps
to
kind
of
give
the
broader
team
an
understanding
of
the
decision-making
process
and
what
kind
of
drives
some
of
these
barriers
or
obstacles
to
committing
to
a
pathway.
I
think
it's
important
for
everybody
to
understand,
appreciate
you
bringing
that
up
any
questions
about
that
from
anybody
on
the
team
or
other
items
that
are
top
of
mind
for
the
ipfs
stewards.
D
D
B
E
A
B
B
B
One
was
the
approval
on
the
implementation
for
basically
where
we're
going
to
put
the
code
for
the
ipni
Team
to
own
the
code
for
the
HTTP
API
migration,
replacing
the
reframe
API
I
think
we
found
issues
with
I
have
Gus
looking
into
that
kind
of
by
the
end
of
the
week
and
I
think
Gus.
If
you
need
any
context
or
support
from
us.
Obviously,
teams
here
for
you.
A
B
And
then
also
will
volunteer
to
take
some
action
on
the
ambient
discovery
of
content.
Router's
proposal
he's
going
to
put
together
an
MVP
for
us,
we'll
communicate
I
think
both
of
these
things
out
in
the
content
routing
work
group,
but
if
we
need
more
Hands-On
kind
of
coordination
of
efforts
or
anything
like
that,
I'll
keep
an
eye
out
and
be
here
to
support
that.
If
we
do
and.
A
B
B
All
right,
well,
we'll
get
a
few
minutes
back.
I
want
to.
Thank
you
all
for
joining
this
I
think
it
was
pretty
successful
if
you
have
any
feedback
for
how
this
was
run
for
improvements
that
you'd
like
to
see
before
the
next
one
in
two
weeks
feel
free
to
reach
out
to
me
directly
and
we
can
restructure
this.
However,
we
need
to
to
be
the
most
effective
I
appreciate
any
and
all
feedback,
but.