►
From YouTube: AsyncAPI SIG meeting 65 (January 11, 2022)
Description
This is the recording for the AsyncAPI Special Interest Group (SIG) meeting #65.
Agenda and notes: https://github.com/asyncapi/community/issues/207
Chat:
17:07:24 From Lukasz Gornicki : https://github.com/asyncapi/spec/pull/584
17:12:09 From Jonas Lagoni : Does traits play a role here?
17:21:18 From Jonas Lagoni : Wonder if it makes sense to try to apply the change it to different scenarios? To see how it behaves?
17:21:27 From Jonas Lagoni : i.e. how is it applied to something like https://github.com/asyncapi/spec/tree/master/examples/social-media
17:22:25 From Sergio Moya : https://www.asyncapi.com/docs/specifications/v2.2.0#serverObject
17:22:31 From Sergio Moya : A declaration of which security mechanisms can be used with this server. The list of values includes alternative security requirement objects that can be used. Only one of the security requirement objects need to be satisfied to authorize a connection or operation.
17:22:39 From Fran Mendez : Yeah, I second that, Jonas. We should test it with use cases.
17:23:07 From Sergio Moya : +1 to test cases
17:25:52 From Sergio Moya : Kafka works as well. You can add security at channel (Topic) level, like ACL’s right?
17:26:16 From Sergio Moya : At Operation I mean 🙂
17:27:01 From Dale Lane : that makes sense for different credentials, but for different security mechanisms?
17:28:56 From Jonas Lagoni : https://swagger.io/docs/specification/authentication/oauth2/
17:40:29 From Refael Botbol Weiss : Just something I thought about - if this constrain is not mutual to all Async protocols... we might want to have an include file which specific to that use-case+protocol.. and reference it in the spec... that way we keep the simplicity but allow complex specs if needed
17:40:52 From Refael Botbol Weiss : From an AsyncAPI newbe... so feel free to ignore🙂
17:47:10 From Jonas Lagoni : Yep, good suggestion Refael, documenting the use-cases in actual examples is a good way to do it
17:50:34 From Fran Mendez : https://github.com/asyncapi/community/blob/master/TWEET_TOGETHER.md
18:00:24 From Abir Pal : Hey AsyncAPI, I am Abir (@imabptweets) .. and this is my first meeting.. Really found it great...and looking forward for first contributions :P
18:01:20 From Sergio Moya : Nice to see u here Abir
18:01:27 From Refael Botbol Weiss : Have to drop for my next meeting - it was super cool 🙂
18:02:06 From Abir Pal : Not yet.. Will message you in slack, for contributor resources
A
How
to
say
it
like
I
mean
if
it's
a
problem
for
you,
then
just
don't
turn
on
your
cameras
and
just
write
in
the
chat,
maybe
but
yeah.
We
have
to
make
this
meeting
transparent
to
others
and
record
it.
So
that's
the
reason
why
we
record
before
we
usually
starts
different
topics
from
the
agenda.
It's
also
a
time
for
people
that
join
for
the
first
time
to
the
meeting
to
introduce
themselves.
B
Hi,
I'm
rafael
from
a
company
called
up
nine.
I
came
here
to
learn
how
to
create
consume
work
with
the
async
api.
Part
of
our
open
source
project
is
miso,
which
showed
traffic
of
a
lot
of
us
in
kps
platform
protocols.
So
thank
you
for
having
me
and
thanks
for
the
great
work
on
async
api.
The
community
is
amazing,
based
on.
A
A
A
A
D
No
I'll
just
talk
to
it,
it's
very
straightforward
use
case
so
today,
when
we
define
operations
or
channels.
The
asynchronous
api
currently
does
not
support
cons
security
constraints,
but
security
can
only
be
defined
at
the
server
level,
so
our
proposal
was
straightforward.
It's
to
introduce
security
also
at
the
operational
level,
because
for
an
interactive,
mutually
interacting
system,
mostly
it
will
be
the
components
and
the
operations
that
others
other
components
will
be
interacting
with
not
necessarily
directly
with
the
broker.
D
You
may
have
at
the
broker
level
and
that's
how
I
had
it,
and
then
I
removed
it
and
and
and
here's
why
that
yes,
in
most
topologies,
that
would
be
the
case.
You'd
be
only
interacting
with
a
set
of
with
a
with
a
with
events
or
even
topics
through
operations,
yeah
and
all
that
all
most
of
the
interactions
with
streams
consuming
or
producing
and
writing
to
a
stream
would
be
defined
by
the
operations
produce
and
subscribe
operations
on
the
thing.
But
there
could
be
topologies
where
your
broker
itself
is
externalized
for
some
reason.
D
D
A
E
E
Yeah,
I
was
thinking
about
it
and
I
kind
of
understand
why
you
move
it
out,
but
at
the
same
time
I
I
try
to
put
my
the
skin
of
someone
that
wants
to
define
their
api,
and
I
think
this
should
be
included
in
the
spec
and
the
reason
it's
that
like.
If
we
don't
include
in
the
spec
and
we
leave
it
up
to
the
implementation.
D
Now
the
operations
when
they
interact
with
the
broker,
which
is
not
externally
exposed,
could
be
using
x5z
scope
to
interact
with
the
server
but,
however
abc
so
essentially,
what
I
mean
is
that
the
scopes
that
you
specify
up
in
the
operation
levels
are
not
necessarily
or
at
the
server
level
and
not
necessarily
a
direct
subset
but
functionally
they.
They
are
a
different
set.
But,
however,
just
in
my
example
that
I
was
giving,
this
could
be
internal
scopes
and
on
the
operation
level,
maybe
you
have
externalized
scopes,
which
other
components
can
interact
with.
D
E
E
E
F
D
I
mean
okay,
so
I'm
I'm
okay
with
calling
it
out,
if
that,
if
all
of
you
folks
advice
on
that,
in
fact,
I
had
it
and
I
removed
it,
but
but
yes,
if
the
consensus
has
put
it
back-
and
I
was
for
it-
that's
why
I
had
it
in
the
first
place.
But
then
I
was
thinking
of
all
these
different
potential
topologies
and
I
hesitated.
D
B
D
D
How
would
you
know
that
xyz
at
the
server
level,
security
is
sort
of
like
an
internal
and
overridden
by
abc
in
the
operation?
Implementation
could
very
well
do
it
differently.
They
will
not.
I
mean
it's
very
highly
unlikely
that
anybody
would
do
that,
but
I'm
just
saying
whether
we
should
put
in
things
that
we
cannot
validate.
E
D
So
I
can
explain
that
so
my
thoughts
were
that
see.
Async
api
serves
two
purposes
for
us
for
ebay.
We
are
using
a
single
service
api
purely
for
http,
push
notifications
just
to
call
out
or
pill
message,
payload
and
our
semantic,
but,
however,
think
of
evolving
topology.
Let's
say
we
are
collaborating
on
a
design
and
we
have
these
evolving
systems
still
work
in
progress.
So
we
have
the
server
set
up.
D
Anybody
trying
to
understand
or
introducing
a
new
topic,
for
example,
a
new,
even
stream
into
the
system,
would
need
to
know
about
the
broker,
any
security
constraints
that
the
broker
would
need
for
introducing
this
event
or
writing
and
operations
around
it,
but
and
also
they
would.
I
totally
agree
with
you
that
they
would
in
fact
that's
why
I
had
it,
but
I
was
just
wondering
whether
the
specifications
should
try
to
call
out
something.
D
That's
potentially
I
mean
again,
I
can't
imagine
a
real
functional
production
use
case
where
people
interacting
directly
with
the
broker
instead
of
a
stream
other
the
channel
or
operation,
but,
however,
for
evolving
work
in
progress,
topologies
both
need
to
be
specified
to
any
integrator.
I
mean
to
any
developer
any
collaborator.
A
Just
wanted
to
add,
like
that
asking
api
is
not
just
brokers
right,
so
there
might
be
other
use
cases
for
us
in
epa
like
websockets.
So
it's
not
just
because
I
hear
that
you're
mentioning
brokers
that
they're
not
exposed
but
yeah.
We
know
that
there
are
other
use
cases
for
us
and
api
other
than
just
brokers
and
even
driven
architectures
plus.
I
mean
like,
for
example,
when
I
was
commenting
on
your
pr
to
have
it
this
information
about
like
what's
priority.
A
It's
because,
like
it's
just
based
on
my
experience
of
how
people
want
spec,
to
be
precise
and
from
like
last
two
years,
I
learned
people
won't
spec
to
be
like
super
precise,
because
they
then
build
tools
on
top
of
it.
So
they
don't
want
to
have
anything
open
for
interpretation.
They
they
want
to
be
yeah.
They
won't
expect
to
answer
all
the
all
the
questions
for
them.
A
A
D
D
Maybe
the
operations
are
exposed
as
what
but
the
dbm
and
sorry
the
server
uses
something
completely
different
so
functionally
they
would
most
likely
be
overwritten
by
operation
level
when
both
exist
for
the
same
event,
and
it
is
the
the
specification
is
indeed
structured
to
make
everything
a
function
of
the
channel
or
the
event.
So
so.
In
that
sense,
it
makes
sense
to
mention
that,
if
both
are
available,
then
the
operation
overrides
server
level
security,
because
that's
kind
of
internal,
because
you're
interacting
with
the
stream
you're
interacting
with
the
operation.
D
E
D
Yes,
so
if
corporation
level
is
not
specified
and
server
is
only
specified
as
the
case
today,
I'm
not
sure
how
folks
interpret
it,
but
we
in
our
case
it
was
different.
We
didn't
even
have.
Ours,
was
a
purely
a
subscription
facing
http
push
notification
use
case,
so
we
didn't
even
have
a
server
in
our
schema.
So
for
us
there
was
no
conflict,
but
I
was
wondering
in
case
both
only
server
level
security
is
present.
B
D
These
brokers
tend
to
have
very
internal
facing
authorization
scopes
with
the
operations
are
aware
of,
and
they
use
it
to
interact
with
it.
But
when
the
operations
themselves
are
exposed
for
outside
integration,
they
use
a
completely
different
externalized
scopes,
which
other
people
can
use,
and
it's
only
applicable
to
the
operation
level.
So
you
could
have
three
operations
and
each
of
them
maintaining
the
granularity,
maybe
operation
a
is
x,
is
accessible
to
scope.
A
dash
operation
b
is
accessible
to
scope
b
dash,
but
all
of
them
use
scope
x
to
talk
to
the
broker
internally.
F
So
it
was
just
just
a
suggestion
that
we
have
this
example
with
the
social
media
system,
which
has
both
rest
interface
and
it
has
websockets
and
whatnot
and
broker
systems
that
all
all
are
defined
with
async
api.
So
if
we
try
to
apply
the
changes
for
the
operations
and
how
security
are
defined
there,
maybe
it
makes
more
sense
or
gives
more
sense
how
everything
works
together.
F
F
Just
just
one
just
pick,
one
see
how
it
works
together
like
in
which
cases
is
it
constraining
and
where
does
it
not
fit
like
these
changes?
Because
that's
that's,
basically
all
the
discussion
about
right
now
right
it's.
Where
does
this
apply
and
what's
the
constraint
and
how
far
to
take
it?
Basically,.
D
There's,
always
this
fear
of
getting
locked
into
a
specific
pattern
and
thereby
limiting
the
gen
the
generic
nature
of
the
specification.
It
was
the
other
reason.
I
was
a
little
hesitant
honestly,
whether
by
calling
out
relationships
which
may
or
may
not
apply
to
all
use
cases,
I'm
not
even
familiar
with
all
of
the
use
cases,
but
I
was
just
wondering
whether
we
would
be
constraining
ourselves
or
limiting
the
specification
itself
by
calling
out
constraints
which
probably
we
shouldn't
get
into,
I
mean
yeah.
F
I
mean
it's,
it's
a
it's
a
perfectly
good
question
right
because
it's
also
a
question
of
whether
the
security
like,
if
it's
only
for
kafka,
for
example
or
whatever
the
protocol
is,
should
it
reside
in
the
bindings
rather
than
being
implemented
in
the
specification
right.
That's
also
like
a
question
that
has
to
be
answered.
C
Just
yeah
the
discussion
in
the
chat
was
sort
of
because
kafka
as
an
example,
you
can
specify
the
security
requirements
like
accords
for
different
topics.
You
know,
maybe
your
credentials
can
access
this
topic,
but
not
that
topic,
but
we
don't
put
the
credentials
in
the
async
api
specs.
I'm
not
sure
that
helps
us.
What
we're
talking
about
is.
Would
you
want
to
access
one
topic
with
one
security
mechanism
and
a
different
topic
with
a
different
security
mechanism,
and
that
seems
unusual.
D
D
There
is
a
operation
that
allows
you
to
access,
or
rather
deal
with
even
stream
that
has
pii
information
about
the
pets
yeah.
So
in
that
case
it
may
have
a
more
rigid
control
on
security
than
something
which
is
just
get
the
name
of
the
bed,
maybe
so,
depending
on
the
nature
of
data
flowing.
Through
these
events,
you
may
have
different
security
requirements,
protecting
the
information
and
flowing
through
these
events,
and
then
the
specification
does
leave
it
open.
D
No,
but
we
should
think
of
it.
The
reason
I
say
that
is
because
see
all
operations
are.
Let
me
put
it
this
way.
All
even
streams
may
not
be
controlled
by
one
central
scope
like
you
can't
have,
for
example,
let's
hear
a
banking
operation
and
there
are
simple
things
to
get
ads,
maybe
for
your
banks,
and
there
are
other-
even
topics
for
critical
account
information
changes
which
may
still
be
okay,
but
there
are
other
events
which
actually
have
to
do
with
users.
Personal
information.
D
E
D
C
One
scenario
would
be
good
to
include,
is
how
would
you
explicitly
say
you
don't
want
security
for
a
particular
channel,
because
what
or
like
you
know,
or
even
for
an
operation
like,
maybe
you
say,
security
is
required
to
send
a
message
to
this
topic,
but
there's
no
security
needed
to
receive
a
message
from
that
topic.
You
know
it's,
it's
public
read
but
secured
send.
C
D
Well,
wouldn't
it
be
that
if
you
don't
have
security
defined
at
the
operation,
level
means
there
are
no
additional
constraints.
But,
however,
if
you
do
have
explicit
security
mentioned
at
the
operation
level,
I
was
wondering
if
that
would
help,
because
you
can.
Oh
it's
an
optional
entity.
It's
not
required
entity.
E
D
E
D
E
I
think
we
should
like
clarify
this
documentation
so
prior
to
that,
of
course,
like
discuss
and
get
to
an
agreement
with
more
people.
I
think
in
the
issue
or
somewhere
just
to
get
with
some
statement
that
clarifies
this,
because
otherwise,
I
would
see
this
like
very
confusing.
From
my
point
of
view.
That's
my
opinion.
D
Could
we
treat
this
as
non-breaking
in
the
sense
that
for
topologies,
where
they
have
designed
their
topologies
to
specify
security
schemas
and
apply
it
only
to
the
server
level
and
they
assume
that
it
propagates
to
the
operations
automatically,
and
they
don't
need
the
case
of
this
granular
controls
as
we
require
it?
These
cases
still
remain
unchanged.
So
in
that
sense
they
don't
have
any
operational
constraints
at
the
operation.
Well,
I
I
don't
know
yeah.
E
D
Is
there
a
way
we
could
reach
out
for
community
feedback
like
at
least
for
the
folks
who
are
using
it?
A
lot
of
folks
may
have
just
specified
it
at
the
server
level
because
they
don't
have
a
option
of
specifying
it
at
the
operation
level,
but
they'd
like
to
have
it
at
the
operation
level,
perhaps
more
to
do
with
even
stream,
rather
than
the
server.
D
D
Or
inherits
operations
in
edit
from
server-
I
don't
know
if
folks
really
should
be
treating
in
that
way,
because
server
a
server
level
security
constraint,
is
a
contract
between
the
different
in
the
microservices
world
in
different
microservices.
That
are
components
that
are
interacting
with
now.
The
component
concept
itself
is
being
thought
through.
I
understand
that,
but
today,
since
we
don't
have
these
the
concept
of
a
component,
it's
mostly
operations.
It's
just
operations
on
the
server.
D
E
D
D
D
So
if
you
just
leave
it
to
the
implementations
and
not
really
get
into
that,
we
could
avoid
this
because
there's
no
way
we
can
solve
it
and
because
we
can
take
opinions
but
we'll
never
take
opinions
from
all
the
I'm
sure.
This
specification
is
catching
on
so
fast,
we'll
probably
talk
to
a
few
big
ones,
but
that
I
reach
out
to
the
community.
Not
many
people
respond
and
we
could
still
be
introducing
something
breaking.
D
G
D
And
friend,
if
I
may,
we
are
also
putting
a
line
there
saying
that,
if
both
are
specified
now
for
all
existing
contracts,
only
one
would
be
specified
only
server
level
and
whatever
semantics
or
assumptions
still
hold
good.
But
if
both
are
specified-
and
that
will
only
be
with
this
release-
then
is
when
this.
So
in
that
sense,
it's
not
a
backward
incompatible
change
people
who
already
have
existing
contracts,
they
don't
even
have
operation
level
security,
so
whatever
they
have
to
have,
and
that's
fine
non-conflicting
yeah.
G
It's
not
about
the
documents
that
people
have
from
like
in
until
now
right
it's
the
contracts
that
people
will
have
from
now
on
from
this
release
on
like
two
yeah
right
and
then
people
start
using
it
in
both
in
servers
and
operations,
and
then
suddenly
we
change
this
and
make
it
more
restricted.
That's
a
breaking
change,
right,
bro!
G
D
G
My
perception
of
this
feature
was
that
it
was
an
override
to
what
was
declared
on
the
servers.
Yes,
it
was
overriding
I
mean
it
was
merging.
Let's
say
not
overriding
right:
it
was
merging
if
you
had,
let's
say
the
same
security
mechanism
or
if
you
have
let's
say
you
have
two
different
security
mechanisms
in
the
server
and
then
you
have
one
which
is
completely
different
on
the
operation.
Then
you
have
three
to
to
access
this
operation
to
perform
this
operation.
You
have
three
options,
but
it
seems
not.
D
You
would
probably
not
be
interacting
so
much
with
the
broker
or
broker
level
security,
but
if
say
from
an
external
consumer
standpoint
subscriber
standpoint
or
a
producer's
standpoint,
you'd
mostly
be
interacting
with
operations
through
which
you
can
produce
or
or
consume
from
that
even
stream
so
specifying
that
operation,
and
that
was
my
thought
when
I
originally
had
put
that
the
security
specifications
and
the
operation
level
override
that
of
this
thing,
because
what
I
meant
by
that
was
not
necessarily
override,
but
I
meant
that
I
mean.
If
you
have
security
at
operation
level.
D
D
G
Right
so
what
happens
here
is
that
whatever
we
decide,
I
think
it
should
be
clearly
defined
and
not
left
not
left
for
interpretation,
because,
let's
see
it
from
the
other
point
of
view,
like
the
point
of
view
of
the
user
right,
so
the
user
is,
is
using
our
tools,
let's
say
the
parser
or
whatever
tools
that
we
offer
and
suddenly
they
want
to
change
the
tools
and
use
some
community
contributed
tool
and
they
want.
They
want
things
to
behave.
The
same
way
right.
We
don't
want
to.
G
We
don't
want
to
live
this
open
to
interpretation
for
the
tooling,
for
the
implementation
or
for
the
tooling
vendor,
or
call
it
whatever
you
want,
because
then
you
replace
one
tool
with
another,
and
suddenly
you
get
a
different
result
right
when
it
shouldn't
right.
But-
and
I
mean
you
have
I'm
talking
about
two
tools-
two
different
tools
that
respect
the
spec
100
100.
Of
course,
if
one
of
them
is
not
respecting
the
spec,
then
we
can't
do
anything
right
to
prevent
that.
So
so
we
want
to.
I
think
we
should.
G
We
should
aim
for
making
it
clear
making
it
super
clear.
What
it
is
about
and
and
restricted
not
restricted
is
like
clearly
defined
and
not
open
for
interpretation
right,
because
in
this
case
we're
gonna
face
more
issues
in
my
opinion,
so
so
yeah
and
I
don't
know-
and
and
maybe
we're
trying
to
rush
things
out
for
this
release-
I
mean
I
don't
want
to
be
the
party
blooper
here
now,
but
it
seems
that
it's
january,
it's
mid
january
almost
and
we're
still
not
clear
on
that
point.
G
G
D
D
D
It's
very
tricky
yeah,
but
should
we
have
another
discussion
because
I
might
given
that
I
don't
have
visibility
into
the
broader
aspects
of
the
specification
we
just
playing
started
playing
with
it
last
year,
so
I
could
be
missing
things,
but
I
would
look
to
all
your
guidance
too
and
we
can
take
it
out
of
the
current
release.
If
that's
the
best
way-
and
I
mean
I
wanted
the
current
release,
but.
G
G
A
Yeah
and
anyway,
we're
gonna
use
our
official
social
media
channels
to
to
promote
it
again
in
this
proposal-
and
I,
like
few
months
ago,
I
dropped
an
email
to
jj
from
paypal,
because
I
remember
from
the
community
discussions
that
actually
like
since
I'm
here
in
the
project.
It
was
the
only
time
when
somebody
talked
about
security
on
the
operation
level.
It
was
an
architect
from
paypal,
and
I
made
him
to
ask
him
to
have
a
look
on
the
proposal.
He
was
interested
but
yeah.
A
He
was
overloaded
and
like
he
couldn't
even
come
to
present
the
dusting
api
conference,
but
I
can
try
to
reach
out
to
him
again
the
good
thing
if,
if
we
don't
push
it
now,
is
that
next
week
a
dedicated
3-0
meeting
starts
that
jonas
organizes
with
the
community
about
the
work
for
the
housing
api
3-0.
So
it
would
be
a
platform
where
this
could
be
also
regularly
discussed
and
some
action
points
could
be
could
be
assigned.
A
G
G
Yeah,
let's
say
I'll,
say
this
plus
you
know
a
few
use
cases
like
janice
was
saying
it
would
be
great
to
explore
a
few
use
cases
and
and
see
how
this
feature
behaves
right,
like
I
mean
not
necessarily
this
social
media
example
which
can
be
but
another
one
can
be,
I
don't
know
like.
We
have
in
microservices
architecture,
say
using
kafka
and
one
of
the
topics
is
shared
with
an
external
company
and
therefore
with
the
partner
not
with
the
public
right.
G
So
therefore,
this
needs
to
be
protected
a
little
bit
more,
that's
one
way.
The
other
way
is
another
example
could
be
what
they'll
say
like
we
want
to
protect,
sending
but
not
subscribing
right
receiving
messages.
So
we
can
subscribe
to
this
topic,
but
and
it's
public
it's
open,
but
we
don't
want
to
enforce
publishing.
G
E
Yes,
something
there.
Oh
sorry,
I
I
need
to
write
my
hat
okay,
then
I
just
wanted
to
so.
Maybe
it's
something
purely
subjective
or
I
don't
know
if
that
word
exists,
but
what
I
think
we
have
to
clarify
it's,
how
people
is
using
the
current
security
field
at
server
level,
because
if
we
don't
clarify
this,
if
we
don't
get
the
real
use
case,
it's
quite
related
with
what
you
were
saying,
fernando
jonas.
E
E
G
G
I'm
not
sure
we
should
be
clarifying
this,
I
mean
we
can
clarify,
but
my
question
here
is
actually
like
what
question
do
you
want
to
clarify
like
with
the
current
behavior
like,
for
instance,
we
know
we
have
security
mechanisms
on
the
server
level
and
those
are
applied
to
operations
as
well,
because
yeah,
you
don't
have
any
other
place
to
define
it,
so
they
they
are.
I
mean
that
is.
G
G
G
G
G
I
can,
I
can
also
understand
and
foresee
that
people
will
see
it
as
you're
overwriting
right,
you're
overwriting,
the
existing
one,
the
one
on
the
server
many
people
will
think
like
that.
I
did
and
and
and
many
people
will
also
think
like.
Oh,
I
wasn't,
and
if
we
do
it
like
this,
because
we
think
that
many
people
are
going
to
think
like
this,
then
we
have
the
other
problem,
the
other
people.
G
Thinking
that,
oh
no,
I
thought
it
was
a
different
set,
all
together
right
so
yeah,
but
in
my
opinion,
like
what
we
had
so
far.
I
think
it's
clear
I
mean
I
don't
know
I
might
be
grown,
but
what
you
define
on
the
server
applies
to
the
whole
to
the
whole
document,
right
to
the
whole,
to
all
the
channels.
G
D
D
F
B
B
H
D
February
yeah
so
yeah,
it's
sort
of
at
the
age
where
it's
really
hard
to
explain
things
to
them,
but
yeah,
but
but
yeah.
So
we
reach
out
for
community
feedback
and
then
we
trade
notes
on
the
pr
that's
the
way
forward.
Maybe
we
have
another
second
two
weeks
or
so
would
that
be
reasonable?
Maybe
we'll
get
some
feedback
by
then
yeah,
I
mean
not
for
january.
Of
course
I
mean
sorry.
A
So
the
thing
is
like
we
like:
we
have
one
of
the
most
important
rules
here.
We
don't
make
decisions
here,
so
we're
not
also,
I
would
say
I
I
personally
as
one
that
approves.
I
would
I
did
not
make
it
a
decision
if
it
should
go
for
april
or
not
we're
just
discussing
the
topic,
so
the
most
important
is.
We
should
now
go
back
to
the
pr
put
our
thoughts
there,
because
this
this
meeting
opens
up
a
lot
of
different
ideas
in
our
heads.
A
So
let's
just
go
back
into
pr
and
set
ourselves
a
a
deadline
like
this
week
to
actually
like
have
a
decision
in
the
pr.
What
are
the
next
steps
and
like
to
not
rush
with
decision
making
on
the
meetings,
especially
that
we
can
release
this
video
and
somebody
can
can
jump
in
into
the
into
the
recording
so
yeah.
To
summarize,
let's
continue
in
the
pr
and
let's
talk
there
this
week
and
see
where
we
should
go.