►
Description
Lately Bisq support has been rather disorganized...it's spread across too many channels, with no designated handlers, and has been compounded by an uptick in frustrated users caught in the update to v1.2.
The situation needs to be improved. On this call, we discuss current conventions, pain points, and paths forward.
Join us in the #ticketing-system channel on Keybase if you'd like to help!
https://keybase.io/team/bisq
👇 Links mentioned 👇
Initial proposal on improving support:
https://github.com/bisq-network/proposals/issues/130
GitHub issue for this call, where preliminary discussions took place:
https://github.com/bisq-network/growth/issues/164
A
Hello,
everybody
welcome
to
this
week's
risk.
Brief
call
we're
gonna,
try
to
restart
this
series
bi-weekly.
This
week's
topic
is
the
improving
the
support
workflow
for
bisque
I.
Think
lately,
things
have
gotten
a
little
bit
scattered
across
the
various
channels
that
we
have.
We
have
a
presence,
slack
key
base,
Twitter
the
forum
telegram,
although
all
the
places
that
this
people
are
questions
have
come
in
and
some
get
answered,
some
don't
get
answered.
A
Some
that
do
get
answered
may
not
be
answered
as
well
as
they
could
be,
and
overall,
it's
just
not
a
good
outcome
and
we
want
to
make
sure
that
people
are
getting
the
best
advice
that
they
can
get,
and
so
this
call
is
about
refining
that
workflow,
perhaps
designating
people
and
processes
and
tools
to
make
that
process
smoother
and
better
for
everybody
involved.
So
we
have
a
rough
agenda
in
the
github
issue
and
let
me
get
that
one
second
I'll
put
that
in
the
chat
for
those
who
are
on
the
call.
A
So
there's
a
bit
of
a
discussion
there
on
just
preliminary
ideas
and
preliminary
research
on
the
tools
out
there
and
the
goals
that
we
have
to
implement
them,
but
this
call
is
to
discuss
those
and
also
to
solicit
feedback
and
additional
perspectives
from
those
of
you,
who've
joined
on
the
call.
I
see
some
names,
I,
don't
recognize
so
I'm
glad
to
see
a
number
of
you
guys
join
thanks
for
joining.
So
let's
go
ahead
and
get
started.
A
A
Should
be
full
screen,
oh
I
see
what
you
mean.
Maybe
use
that
a
little
bit
better,
yeah,
okay
yeah.
So
this
is
the
basic
agenda
we
have.
We
want
to
talk
about
where
we
are
right
now.
What
the
current
state
of
support
is
and
then
goals.
What
do
we
actually
want
to
achieve
with
this?
What
are
the
limitations
in
achieving
our
goals,
privacy
and
security?
A
Think
Christophe
and
I
can
talk
to
each
other
I'm,
not
sure
what
else.
Oh
dear
works,
fine
for
me,
too.
Okay,
all
right,
maybe
it's
just
issues
on
I
thinking
your
guys
and
you
and
then
yeah.
If
we
can
get
this
far,
then
the
last
step
would
be
talking
about
implementation
and
how
to
actually
get
this
this
plan,
if
whatever
we
come
up
with
in
in
motion.
A
So
as
far
as
the
the
current
state
of
support,
that's
I
guess
like
went
over
that
a
little
bit.
It's
a
bit
scattered
and
that's
kind
of
the
main
issue.
We
have
lots
of
channels
knows
no
designated
people
to
provide
support,
no
training
basis,
so
to
speak,
people
just
kind
of
come
in.
They
maybe
read
some
read
through
the
form,
a
little
bit
read
through
past
issues
and
then
kind
of
start
answering
people
as
they
as
they
can.
Usually
that's.
Okay,
but
I've
seen
some
instances
where
people
may
not
be
giving
the
most
accurate
responses.
A
A
C
We
also
have
a
problem
of
not
being
able
to,
even
though
there
is
a
solution
for
some
problems.
We
have
no
way
to
find
it.
So
if
somebody
had
the
same
problem
in
a
different
country
like
we
just
have
absolutely
no
way
to
to
find
that
unless
we
go
digging
and
trying
to
find
some
roots
and
github
issue
from
way
back
or
something
that
might
be
close.
Even
so,
that's
another
bummer
yeah.
A
C
Yeah,
what
channels
that
we
do
have
today,
like
I,
know
that
we
have
a
telegram,
like
the
the
english-speaking
one.
I
am
sort
of
running
a
president
president
Portuguese
one,
but
it's
more
for
low-tech
stuff.
Like
onboarding
people,
we
have
a
slack
which
were
slowly
migrating
out
of.
We
have
the
forum.
We
have
key
bays
what
else
we
have
an
email
as
well
or
no.
No.
A
C
A
C
C
In
our,
but
it's
got
a
low
touch
solution.
It
is
a
high
touch
that
to
me
to
watch
somebody
through
and
like
I.
Remember,
I
brought
in
some
five
different
people
into
into
key
base,
so
they
could
reach
out
to
the
mediators
and
stuff
like
that.
Is
that
something
that
we
want
to
be
supporting
moving
forward
like?
Should
we,
maybe
maybe
I,
don't
know,
write
a
post
about
it?
What
is
the
attitude
towards
something
like
that?
I
think,
that's
something
that
we
should
think
about.
I.
A
B
B
It
won't
be
perfect,
probably,
but
it
should
be
close
to
perfect
so
so
that
if
you
want
to
reach
in
many
mediator
or
your
trade,
that
you
can
do
this
from
within
the
app
without
any
problems
still
yeah
tempter
must
be
some
other
way
to
to
contact
mediators,
if
you,
if
you're,
just
not
able
to
do
so
through
the
app
and
yeah
for
that
we
we
have
to
have
a
different
channel
at
least
one
different
channel.
I
guess.
B
Because
of
this
is
update
from
from
the
old
trade
protocol
to
the
new
trade
protocol,
we
had
so
many
additional
arbitration
cases,
because
people
were
also
not
following
our
guides,
so
we're
so
there's
lots
of
manual
fixing
of
existing
trade
so
and
that
that's
just
accumulated
and
just
escalated.
The
problems
we
had
on
on
the
support
part
so
it
it's.
C
Not
it's
not
really.
A
bug
in
the
in
the
software
is
just
guiding
how
to
use
it
or
explaining
something
that
didn't
understand.
You
know
its
basic
question
that
you,
you
can
probably
answer
in
one
like
two
lines
of
of
answer.
You
you're
good
and
the
person
is
good
to
go.
Instead
of
all
I
have
a
bug.
I
need
to
see
your
log,
ok,
I,
try
to
read
your
logs
I
didn't
and
what
happened
so
I
loose
it
on
support
and
ask
for
help
from
from
somebody
who
understands
more
about
the
law.
A
A
B
B
Have
to
just
fix
usability
of
the
client
and
try
to
improve
that
over
and
over
to
have
as
little
support
requests
as
possible,
as
as
everyone
knows,
this
wouldn't
scale
probably
properly
and
yeah.
It's
it's
not
worth
to
to
spend
so
much
with
money
and
resources
or
support
that
actually
needs
to
be
spent
for
fixing
I.
C
Totally
agree
like
with,
after
all,
we're
not
a
high
value,
how
can
you
say
that
high-touch
service,
you
know,
there's
not
like
there
is
an
account
manager
if
you're,
a
big
trader
or
a
thing
like
that,
absolutely
like
it
could
be
aim
for
something
scalable?
Shall
we
move
on
to
how
we
aspire
to
have
the
support
and.
A
C
Let's
do
it,
let's
talk
about
goals,
the
next
topic,
cool,
so
I.
Think
Christoph.
Could
you
share
with
us?
What
are
the
known
constraints
that
you
you
see
from
within
the
app
because
I
mentioned
there?
Are
there
a
few
channels
of
support
right?
So
one
is
you
have
a
problem
and
try
to
solve
it,
the
app
the
other
is.
You
have
a
problem.
You
have
no
idea
what
the
hell
happened
and
you
go
search
for
stuff
and
you
end
up
in
the
website
and
finding
something
there
from
within
the
app
yeah.
B
Let's
say
bass
bass
best
case
solution
would
to
have
half
the
support
within
the
app
to
have
kind
of
knowledge
base
access
with
from
within
the
app
how
you
are
probably
used
on
mobile
apps,
where,
where
it's
quite
common,
but
that's
also
because
there
are
really
good
support
systems
available
to
provide
normally
a
good
SDK
which
you
just
plug
in
and
then
you
have
everything
you
want
from
a
ticketing
system.
It
just
suggests
possible
articles
which
could
solve
your
problem
to
do
this,
but
yeah.
B
That's
for
mobile
app
stats
for
apps,
which
yeah
to
have
identity,
and
it's
hard
of
us
to
do
this
properly
and
also
in
a
in
a
private,
private
and
secure
way.
I
think
with
has
some
experience
how
they
did
it
in
one
of
his
former
companies
in
combination
with
regular
support
systems.
I
think
it
was
sin
desc
with
ya.
D
D
Even
when
using
like
a
fully
hosted
solution
like
send
disk,
you
can
add
some
encryption
or
other
layers
of
to
protect
the
users,
privacy
and
the
message
the
contents
of
their
messages,
while
still
maintaining
all
the
features
and
functionality
of
Zendesk.
So
the
way
it
worked
is
we
just
had
a
web
page.
D
So
we
didn't
use
the
Zendesk
web
pages,
except
for
like
the
public
articles
contents
and
things,
but
you
could
you
could
just
Pete
basically
like
PGP
and
crypt
to
some
public
key
and
then
it
would
create
a
ticket
with
this
encrypted
blob
of
data
and
for
the
agents.
When
they
view
the
tickets,
they
would
have
like
a
browser
extension
and
they
would
have
their
private
key
loaded
in
the
browser
extension.
They
could
just
view
that
encrypted
blog
and
so
that
way
we
could
get
the
best
of
both
worlds
right.
C
D
Yeah
I
mean
you.
You
can
implement
some
kind
of
a
fancy
key
rotation
system.
You
could
do
you
know
public
key
infrastructure.
You
certificates
do
all
kinds
of
cool
stuff.
You
could
do
depending
on
how
complex
you
want
to
make
it
I
think
in
practice
you
probably
just
need
to,
like
maybe
rotate.
The
key
is
once
a
month
or
something.
B
Yes,
so
so
what
what?
What's
probably
possible
from
within
the
app
I
haven't
implemented?
That
I
suggest
that
a
quick
look
at
relay
service,
which
we
use
for
sending
out
push
notifications
and
that's
that's
using
regular
api's
from
Google
and
from
Apple
to
send
out
the
mobile
notifications
and
sends
encrypted
messages
from
the
clients
and
the
clients
connect
through
tor
to
an
onion
address
to
the
relay
service.
Passing
on
the
encrypted
message,
which
isn't
just
forwarded
to
push
notification.
So
that
sounds
thing
that
only.
B
D
Fabio
like
to
be
clear,
we're
not
gonna
be
using
the
email
functionality
of
Zendesk
at
all.
The
only
way
you
would
be
a
little
interact
with
the
support.
Backend
is
from
the
disk
desktop
app
directly
and
it
would
be
totally
invisible
to
the
user,
because
the
desktop
app
would
just
be
hitting
some
tor
hidden
service
onion
like
API,
and
that
would
post
it
to
the
Zen
desk
and
it
would
all
be
end-to-end
encrypted
or
something
like
this
cool.
C
D
C
D
C
D
Maybe
maybe
it's
better
to
like
imagine
it
that
we're
not
even
using
Zendesk
we're
just
using
like
a
dumb
database
where
you
can
tag
the
messages,
but
you
can
also
assign
the
messages,
and
we
were
also
looking
at
this
self
hosted
solution
called
coyopa
and
I
sent
the
the
pricing
to
Christophe
I.
Think
it's
like
300
dollars
a
month.
It
wasn't
like
too
cost-prohibitive,
but
maybe
if
we
combine
the
our
end-to-end
encryption
stuff
with
the
self
hosted
solution
that
we
get
have
the
best
of
all
the
worlds
I
mean
Zendesk
is
just
two
centralizes.
D
Importantly,
like
when
we
use
the
disk
app,
we
get
all
the
security
and
privacy
from
you
know.
There's
no
need
to
authenticate
the
user,
because
it's
I
mean
it's
gonna
be
like
signed
with
their
tour
key
or
something
like
this,
whereas
you
know,
if
you
just
shoot
an
email
to
Zendesk,
we
have
no
idea
who
you
are.
You
could
just
you
know,
be
a
scammer
right
like
there's.
You
need
to
authenticate
the
user
while
providing
her,
basically
exactly
what
Cubase
is
doing
right.
You
get
the
security
and
the
privacy
together.
C
C
B
To
open
a
support
ticket
immediately,
so
we
meet
some
how
to
point
user
first
or
a
little
bit
harder
so
that
they
first
read
up
on
a
knowledge
base
or
in
the
documentation
section.
If
that
could
solve
their
problem
before
just
shooting
out
very
low
key
support,
requests
that
can
be
solved
easily.
Just
by
reading
one
article
or
so
cuz
yeah
is.
C
B
C
B
Yeah
some
something
like
that
we
just
have
to
think
about
not
so
that
they
can't
provide
real
supported
how
people
are
probably
used
on
other,
like
a
client
base
that
have
any
problem,
we'll
get
somebody
immediately.
That's
one
scale,
so
it's
more!
If
you
really
have
a
technical
problem
or
something
like
that
can't
be
solved
easily
by
just
reading
documentation,
then
we
should
be
able
to
provide
support
for
these
users.
A
C
B
Regarding
the
other
other
channels-
and
it
probably
is
better
to
just
as
you
said,
point
people
to
knowledge
base
or
just
random
people
can
can
reply,
because
it's
it's
probably
not
not
so
difficult
or
so
it's
problematic
the
problems
that
are
out
there,
but
I
guess
we
do
have
support
within
the
app
and
people.
Don't
need
to
go
to
the
forum
post
on
Twitter.
We
go
to
key
base
yeah,
but.
B
A
Was
gonna,
say,
I
think
having
the
same
people,
whoever
is
designated
to
be
in
charge
of
this
support
infrastructure
or
whatever
it
is,
should
also
keep
an
eye
on
these
other
channels,
which
is
just
like
designate.
What
are
the
channels
we
want
to
focus
on
and
have
these
people
watch
these
channels,
low,
touch,
support,
requests
and
then
just
handle.
C
Them
there
yeah
and
also
like
I'm
envisioning.
Then
we
we
have
a
support
tab
in
the
app
which
we
do
and
there
we
just
have
a
big
message
saying,
but
please
go
check
the
knowledgebase
and
I.
Don't
know
some
some
things
before
you
are
able
to
actually
send
the
message
to
to
support.
Maybe
we
put
some
form
to
try
to
triage
what
their,
what
they're
getting
and
also
to
actually
have
just
a
barrier.
C
C
C
A
A
B
Yes,
yes,
yeah!
Actually
at
the
moment,
it's
not
that
sophisticated,
so
you
can't
tag
or
reassign
ticket.
So
it's
it's
more
like
that
when
the
the
ticket
or
support
across
this
opens
an
arbitrator
or
mediator
or
support
agent
is
selected,
and
then
only
this
support
agent
will
receive
the
messages
and
he
has
to
kind
of
solve
the
problem.
Yeah.
C
Yeah
yeah,
so
it
is
hard
to
do
something
like
imagine
that
I
get
assigned
a
ticket
I,
don't
know
how
to
solve
the
problem.
I
need
to
ask
for
help
from
another
support
agent
that
might
know
that
the
solution
so
that
either
need
a
private
channel
where
all
the
support
people
talk
to
each
other,
but
then
they
are
sharing
the
information
and
the
encryption
is
as
safe
as
all
the
support
team
right.
C
A
B
Support
might
be
then
another
problem
and
yeah
we
may
be
not
able
to
solve
the
problem.
The
user
is
having
splitting
it
up
still
if
we
still
communicate
through
tor,
we,
it's
probably
quite
safe.
That's
just
a
regular
communication
to
another
onion
address
will
work
compared
to
our
messaging
system
on
p2p
messaging
system,
but
yeah,
okay,.
A
Cool,
so
I
guess
moving
knowledge
that
we
have
we're.
Gonna
have
a
couple
of
parts.
We're
gonna
have
some
kind
of
conventions
to
handle
social
channels.
We're
gonna
have
something
with
possibly
within
the
software
in
the
program,
the
bisque
itself,
some
kind
of
knowledge
base
and
then
also
probably
some
kind
of
a
ticketing
system.
Are
we
in
agreement
right.
C
C
A
C
A
Maybe
we
could
consider
starting
with
one
of
these
items
first,
so
maybe
designating
people
who
want
to
take
this
on
and
who
sorry,
who
designating
people
who
want
to
take
on
the
the
lower
hanging
fruit
so
to
speak
so
the
social
channels
and
then
once
they've
got
those
under
control,
then
start
building
a
knowledge
base
from
there
and
then
I
think.
Maybe
this
process
will
give
us
a
good
idea
of
what
we're
really
dealing
with
and
what
we
need
to
the
tools.
We
really
need
to
build.
The
next
step
of
the.
A
A
A
A
good
first
step
would
be
to
like
to
get
people
on
this
actively
in
all
the
places
we
want
them
to
be
active
on
and
you
know,
get
them
get
them
trained
speaker
get
get
them
up
to
speed
on
the
most
important
issues
of
the
moment,
so
that
they
can
respond
as
well
as
possible
and
then
from
there
start
building
a
knowledge
base
and
potentially
getting
a
ticketing
system
ready
in
parallel.
So
I
ought
approach
it.
C
A
B
No
yeah
I
just
wanted
to
say
it's
pretty
the
same
as
I
think
we
need
to
to
to
speed
up
the
time
how
long
it
takes
to
to
answer
support
requests,
because
that
takes
out
the
pressure
a
lot
for
from
the
from
the
people
having
problems.
If
the
devil
is
it's
the
are
to
help
me
and
then
the
quality
of
the
of
the
support
response
and
I.
Think
for
that
having
knowledge
base
is
the
next,
so
that
support
agents
they
can.
B
Well
thought
well
formulated
guidance
for
the
most
common
problems
and
just
post
it
there
and
yeah,
and
that
there
should
be
a
big
big
first
step
already
and
yeah,
and
and
and,
as
you
said,
Steve,
so
we
will
see
them
most
of
the
tools
they
do
have
some
some
social
media
integrations
Twitter
is
quite
quite
common,
so
what
agents
can
can
test
test
this
hours?
You
can
test
the
systems
we
already
provide
value
with
the
knowledge
base
and
I.
Don't
know
if
how
hard
it
is
to
to
directly
fill
in
the
forum
as
well.
A
B
Yeah
and
the
last
the
last
step,
because
it's
the
most
most
complicated,
but
it's
it's
yeah,
it
yeah,
it's
it's
the
most
complicated
and
it
will
be
some
some
development
effort
to
integrate
and
then
support
within
the
app
and
then
just
forward
it
to
our
support
system.
There.
I
would
also
see
that
that,
as
a
last
step,
because
yeah,
we
can
do
all
the
other
stuff
quite
easily
and
quite
independent
from
the
client
really
sorry.
A
C
A
I
was
thinking
that
we
would.
We
would
discuss
that
once
we've
gotten
past
this
first
step
of
designating
people
and
getting
started
with
the
social
channels
and
no
like
it's
not
a
base,
we
can
talk
about
yeah
ticketing
system
to
me
is
something
that
will
like
work
toward
as
we
learn
more
about
our
needs
in
these
first
two
steps.
B
C
B
B
Sure
the
temple
be
great,
yeah
I
think
it
just
needs
first,
one
who
kind
of
pushes
that
and
yeah
I
think
for
for
setting
up
this
knowledge
base
there.
There
should
be
also
lots
of
developers.
It's
not
kind
of
a
hardcore,
back-end
engineer
that
is
necessary.
It's
it's
more
kind
of
following
this
setup
guides
and
oh
yeah,
setting
up
everything
but
I
think
technically
part.
There
will
be
guys
available
developers
available
to
help
out
with
that.
A
C
A
C
I
think
what
did
one
for
for
the
ticketing
system,
one
for
the
knowledge
base,
then
the
the
process,
it's
a
whole
different
discussion,
which
in
part
depends
on
which
tool
was
decided
because
it
shapes
the
process.
If
we
want
to
do
a
process
that
is
not
supported.
Just
true.
So
three
proposals
I
think
we
could
start
writing
an
overview
document
and
have
that
circulate.
That's
like
the
the
master
document
about
this
project
and
then
three
sub
documents.
B
Yeah
sounds
good
I
think
we
do
need
proposals
for
that,
as
of
course
it
should
be.
It
should
be.
Compensating
the
end
on
one
side.
Support
agents
should
be
able
to
be
compensated
and
also
setting
up
this
whole
Steadman's,
and
for
that,
as
all
stakeholders
take
active
part
in
the
course
cause.
It's
so
much
stuff
going
on
the
bisque,
Network
and
ecosystem
already
so
I
think
it's
it's.
A
You
are
interested
in
what
we've
talked
about,
and
you
think
you
might
have
something
to
offer
advice,
ideas
on
tools
and
you
know
ways
to
achieve
a
better
support
process
for
bisque.
Maybe
just
join
our
support
channel
on
key
base
and
make
your
your
your
contributions
or
ideas
known
and
get
involved
with
making
these
proposals.
A
C
B
C
C
A
B
C
C
You
wanna
have
an
array,
no,
but
I.
Think
that's
where
that
that's
a
support,
despair,
automated
discussion
about
support,
so
I'll,
create
this
channel
or
ask
for
help
for
creating
it
and
whoever
wants
to
help
with
this
join
the
channel.
Let's
chat,
I'll
I'll
put
in
a
list
of
things
we
need
to
do
as
a
team
and
we
we
go
tackling
those
one
by
one.