Migrate primary chat from Keybase to a new self-hosted Matrix team

[wiz]

This is a Bisq Network proposal. Please familiarize yourself with the submission and review process.

Keybase has served the Bisq community very well over the past few years since we migrated from Slack. However, as many of you know Keybase was recently acquired by Zoom, which is not good since Zoom is accused of censoring calls on behalf of the Chinese government.

Recently the matrix protocol and related desktop/mobile apps have come a long way in terms of functionality, and now has a "teams" feature similar to what we are using on Keybase (known as "spaces" on matrix). I've been using it for the mempool project and other personal chats recently and found it to be perfect for Bisq.

While Bisq already has a matrix chat room on the matrix.org server I propose to migrate this to a new Bisq team on my self-hosted matrix server, accessible at @bisq:bitcoin.kyoto with a quick link setup at bisq.chat - I've already setup the space and a few rooms for those who want to check it out. I recommend the Element desktop app, and fluffychat for iPhone. There are many other fine apps for Desktop and Mobile available.

Please check it out and let me know what you think.

[m52go]

I've been monitoring the existing Matrix room for Bisq over the past few months and the clients have improved a lot.

One of the biggest complaints I've gotten from people is that Keybase is hard to access since it requires a login that many don't already have and it requires users to download apps to actually chat. Element has a web interface that doesn't require new app downloads.

Users often complain about Keybase's questionable ownership, siloed nature, and potential censorship...especially now that a number of other Bitcoin-related projects have started migrating to Matrix recently, it would be good for Bisq to establish a more meaningful presence there.

[cbeams]

I'm generally +1 on this. My thoughts / feedback:

• Spaces have not been rolled out fully on the iOS Element client yet. So people will have to join the Bisq space via web or desktop and only then will they be able to see them on their (iOS) phone. I just went through this process.
• There are nearly 3,000 members in Keybase. Not sure how many are active, but that's one of the larger Keybase teams, last I checked. There's something significant about that, but probably not worth staying just for its own sake.
• The 'official' part of the move would probably mostly be about support, i.e. where we direct users for getting help. Also the #buy-bsq channel etc. Otherwise, the move can happen more or less organically, I'd think.
• Maybe a phased approach will be a good idea. Just start doing it now, make it open to anyone to join, etc., and then officially revisit this in, say, one cycle, to see how the migration is going. Maybe don't move support and buy-bsq until after that period.

[m52go]

Maybe a phased approach will be a good idea.

For sure. I think we can learn and adapt the room operation and user-oriented messaging in the process to make it smoother over time.

[wiz]

Spaces have not been rolled out fully on the iOS Element client yet

Yeah, I use fluffychat on iOS which is far superior IMO. The UI on iOS Element is just weird.

There are nearly 3,000 members in Keybase.

Sure, our Keybase group won't go away anytime soon, this proposal is more of getting a rough consensus to start the very slow migration to a self-hosted alternative. One day Keybase will probably do something really evil and then we'll uninstall the app but it will be fine since we'll already have been prepared for that day.

The 'official' part of the move would probably mostly be about support

Yeah, I think the web interface of matrix (i.e. without having to install software) is the main advantage for support.

Maybe a phased approach will be a good idea.

TBH it's up to you guys how to migrate, this is just me as the ops guy saying hey I made this server let's start using it.

[chimp1984]

Who would take over the lead for a transition? E.g. communicate, promote, plan transition...

[wiz]

Who would take over the lead for a transition? E.g. communicate, promote, plan transition...

Definitely @m52go is the best person for this job

[mrosseel]

@wiz sooner or later we were going to end up on matrix, glad the project has progressed enough to make it viable
So +1 for a phased transition.
Some questions around ownership though:

• is this a bonded role?
• how easy is it to take over the matrix hosting, which creds are needed if any?

[wiz]

Yeah good point, I think there was already a Rocket Chat Operator role or something we can just rename. As for migrating I think it's fine as long as we have 4-5 admins to control the room.

[m52go]

Plan

Now

• change official links on website (done)
• create rooms (in progress, mostly done)
  • consolidate existing setup to avoid room inflation
  • get admin/mod permissions set properly
• start encouraging community to migrate with occasional messaging on twitter, keybase, and telegram
• add links where appropriate on wiki, github, and bisq itself
• encourage active project contributors to move conversations to matrix (especially those doing support)
• write wiki article with any special guidance (verifying support staff, etc)
  • figure out how to handle identity for high-risk functions like support

Soon

(when there is a notable shift in momentum)

• remove links to keybase on github, wiki, and bisq itself
• make announcements on forum and reddit

Afterward

(when keybase activity is minimal)

• shut down keybase

@mrosseel do you have access to any of the old Matrix and/or IRC rooms? I think the IRC one is still on Freenode whereas most FOSS projects have moved to Libera. Would it be advisable to shutter these rooms? Or at least remove links to them on the Bisq website?

[chimp1984]

@m52go Thanks for taking on that!
When you recreate rooms, use dev_bisq2 instead of dev_misq, as we plan to use bisq2 instead of misq to avoid confusions...

[w0000000t]

Identity can be currently verified on matrix by using keybase as a medium for 2FA: chat on matrix between userA and userB, A asks B to write them message M on keybase, so B messages A on keybase with "M", they can so get verified.
I did verification this way with MwithM and jmacxx.
The great downside to this is Matrix verification not working as web of trust: being reciprocally verified with MwithM and jmacxx, this didn't lead to MwithM and jmacxx seeing each other as verified as well, since they didn't do verification between themselves.
This doesn't scale at all and will definitely be a problem if we want to rely on trustless verification; we talked with MwithM about having an index of verified Matrix support agents on wiki, but that would be a trusted approach, and would also need someone to keep the wiki constantly updated.
Requesting a "web of trust" feature to Matrix, or something like cross-platform verification as it is on keybase, would be a possibility.

[m52go]

The great downside to this is Matrix verification

Agree, and this needs to be figured out before Matrix is recommended for support. And it needs to be super-simple, or people will be discouraged or skip over it.

Two approaches I can think of are:

• list matrix user account URLs on wiki, software, etc for known support staff (e.g. https://matrix.to/#/@handle:matrix.org)
• create new matrix server with new domain and closed/restricted signups, such that anyone with an account on that server can be trusted

[w0000000t]

Two approaches I can think of are:

I like that both are totally independent from Matrix collaboration.
First one is way easier to implement at first and yet I still don't like it would be a trusted method and needing care.
Second one I prefer on the premises of it being much more elegant and "self-contained", but if users on that domain are access-restricted to support agents only, how can users in need of support verify the accounts on the public domain against the ones in the restricted server?

[m52go]

First one is way easier to implement at first and yet I still don't like it would be a trusted method and needing care.

That's pretty much how we do it now...Keybase handles are listed on the wiki. I doubt anyone further verifies proofs. We'd just change those handles to Matrix links.

how can users in need of support verify the accounts on the public domain against the ones in the restricted server?

The restricted server would only be used for user accounts, not chat rooms. Users on that server would participate in the #bisq:bitcoin.kyoto space just like everyone else, but anyone could easily check that their accounts are hosted at bisqsupport.org (e.g. @w0000000t:bisqsupport.org or whatever).

Maybe that's overkill and we just need user account links on the wiki.

[w0000000t]

I would still prefer the second method, but I can be overengineering sometimes and I see how this would require more tinkering.
What I like about keybase, is the builtin platform verification where you can show that you are the owner of your reddit/github/twitter/younameit account, and that is trustless, in a way.

[MwithM]

The keybase verification feature is top, but I think that maintaining a list of mediators and support agents links should be enough.
Matrix not being a massive tool plays in our favour, scammers go to the biggest honeypots like Slack, Discord or Telegram. Maybe that was a reason for not having impersonators at Keybase, more than the verification tool.

We could have a manual web of trust by verifying two or three Matrix accounts and sharing that we have been verified with those two or three users with another verified user. That would speed up a little bit the process of getting the main accounts verified, as we could avoid the proof of external verification, but it's still a very slow process anyway as it needs to be done individually for every account and needs coordination.

[pazza83]

Closing as approved