proposal: using a central, searchable and open hub (matrix / mattermost) to use as a chat for Gno development

[thehowl]

Hey, this is something I've discussed a few times internally with @moul and @waymobetta but I realised currently exists only as a brief mention on #21 . I think it's time to make an issue because I'd like to kick-start this discussion, decide if this is a good idea or settle on a better approach, and get going on making this change because I'm tired of what we currently have.

Basically, we currently have our communication channels scattered in a few places:

• Internally, we have a slack channel, #gno-core-tech, formed by the team members.
  • Admittedly, though, this is not much useful as an informational channel, but rather as a banter-channel or for communications with other AiB teams. Part of the reason for this is Manfred and Jae's dislike for Slack, which I share, and for the security-focus of Signal (AFAIK).
• Then, still internally, we have a Signal group Gno-Tech-Staff, which is the employee-specific discussion channel. This is however less useful in comparison to...
• The Gno-Core-Contribs signal group, which contains the core staff together with all of the core contributors.
• Finally, we have a few scattered channels on our Discord which were previously used for development and support: gnolang-dev, gnoland-core, gnolang-support.
• Except... we also have our reddit, where we're "redirecting" our users from GitHub discussions, and we have half-mentioned the idea of starting to use it for public, searchable discussions and support questions on Gno.

In order to attempt to tackle this, I've come up with a first proposal, which you can find by expanding the details box below. There is an updated proposal discussed with the team which incorporates various feedback further down this conversation which you should probably read instead.

Original proposal

I think this steers away from what I think are our actual requirements for communications:

1. To have basically a three-layered system, with one obvious communication channel for each
   1. Large community: this is comprised of everyone who has any kind of interest in Gno, but may not be necessarily interested or capable of taking part in its active development.
   2. Builders: partners and individual external contributors who do have some kind of interest to take part in discussions, and should have a way to fast-track discussions to get help when starting out on their journey and discovering how Gno works.
   3. Employees: AiB/NewTendermint employees who make up the Gno Core Team. This communication channel would be mainly to organise internal meetings, and any conversation which doesn't particularly concern builders as a whole (for instance, the Rouen retreat).
2. To have our community and builders discussions public and searchable, and if deemed useful the employee discussions too (for the purpose of full and complete transparency). -- per Centralizing Logs and Meeting Transcriptions for Easier Searchability #21
3. To be able to make it reasonably effortless for people interested in building to join our builders communication channel, without stumbling on a large number of half-dead places while getting there.

As such, I propose the following solution:

• Creating a self-hosted Mattermost server. Mattermost has mobile and desktop apps, I've used it before and it worked great.
  • This allows us to seamlessly create a public, searchable and indexable log of our conversations.
  • I propose build.gno.land for the domain :) but otherwise, chat.gno.land works too.
• Access to the mattermost server is granted to anyone by linking a GitHub account more than 1mo old.
  • The 1mo requirement is added to try and avoid people creating ad-hoc GitHub accounts to join the Mattermost chat, and to try to filter for builders.
• The mattermost server has three channels:
  • #general - equivalent of the current Gno-Core-Contribs
  • #tech-staff - equivalent of Gno-Tech-Staff and Slack's #gno-core-tech
  • #banter (random, watercooler, ...) - a muted-by-default channel where everyone can go and post and have non-gno related discussions.
  • More channels may be added in the future if we deem them useful. For instance, I envision other channels we currently have on slack through slack connect being brought over to Mattermost, such as gnoland-onbloc and gnoland-teritori
• And finally, we have bridges. This is important to keep in touch with other stakeholders and the larger community.
  • Matterbridge can provide most of the bridging functionality we need.
  • Slack's current #gno-core-tech is two-way bridged over to Mattermost's #tech-staff.
  • Mattermost's #general is bridged in a one-way bridge to Discord's #gno-builders. On the Discord channel topic, we point to instructions to join through mattermost or IRC.
  • Mattermost's #general is bridged in a two-way bridge to an IRC channel to be created on libera.chat. The reason why I think it makes sense to have an IRC bridge like this is that many developers (especially old-school ones) use IRC for FOSS development communications. Knowing how to use IRC is also to me a reasonable barrier for entry which can be used in place of a 1mo-old GitHub account.

DM's and small group chats can as always be where the participants deem them most useful to be. For instance, Mattermost does not guarantee the same amount of security as a platform like Signal does. However, I think self-hosting our communications is a crucial step towards being able to have public logs without causing more headaches than we need.

cc/ @jaekwon @albttx @leohhhn @Ticojohnny

Please comment on this issue with feedback/criticism and other alternative solutions we can explore. I'd like to converge on this issue as part of our Rouen retreat.

[thehowl]

Note, I forgot to address reddit. I think it may be useful at one point to also understand whether for "forum-like" discussions we want to keep reddit, or want to additionally add a tool for StackOverflow-style QA (while we wait for us to be relevant enough to have our own SO tag!). Some options. I've only previously had experience with Question2Answer, although I found its UI/UX not that nice overall.

This may be worth discussing in another issue; and maybe after we've figured out this first part of communications.

[waymobetta]

@thehowl This would be a great topic to discuss during the offsite considering its significance and how this impacts our entire company's use of Signal.

[ajnavarro]

I understand the challenges involved and, based on my experience, I recommend against bridging chat applications for the following reasons:

• Reliability Issues: Bridging often leads to inconsistent performance, resulting in missed messages. This unreliability can disrupt communication flow.
• Compatibility Challenges: Variations in features and formats across different chat platforms mean that messages may not translate well when bridged, leading to confusion and miscommunication.
• User Identification Conflicts: Different handler systems across platforms can make it difficult to recognize and track users consistently, complicating conversation tracking.
• Cross-Platform Conversation Complexities: Engaging in conversations across platforms, such as Discord and Slack, amplifies these issues, often leading to a frustrating user experience.

To address these concerns, I propose the following:

• Unified Communication Platform: Opt for a single chat system. While Discord is popular, especially in blockchain circles, alternatives like Slack are equally capable of building and maintaining a vibrant community.
• Integration with Key Web Apps: Implement bot notifications for essential web applications like Reddit and GitHub. This approach ensures centralized updates and interactions, streamlining communication within a single platform.

[thehowl]

Here's an updated version of the proposal, taking into account the feedback and what we discussed together at the Rouen retreat:

For context, a link to the internal miro board, which also contains a link to the recording.

Goals

• Publish our conversations as a core team and with the builders, both for transparency and creating a public body of conversational documentation: Centralizing Logs and Meeting Transcriptions for Easier Searchability #21
• Making it straightforward for developers, partners, potential grantees and all kinds of builders to obtain a synchronous direct line of contact with existing developers and the Gno Core Team.
  • All the while, posing some barrier of entry for users to join, both as an anti-spam measure but also to restrict access to developers. (ie. you must know how to use GitHub).
• Have a public, searchable database of questions and high-quality answers relating to Gno programming, the Gno.land node and Tendermint2. (The core Gno projects)
• Consolidating our usage of different platforms for group communications
  • (ie. removing Discord as a platform used by the core team)
• Provide clearer indications for people to get help.

Proposed solution

• Asynchronous Communications: consolidate GitHub as our central platform for async.
  • Start using GitHub discussions again as the forum for questions and answers.
    • Avoids using another platform, as we'll for sure continue using GitHub for issues, and allows us to quickly categorise questions and bugs and move them to the appropriate location (discussions / issue tracker).
    • Integrates with the existing notification systems that core team members have.
  • Continue using GitHub as the main, asynchronous communication platform used by the core team.
  • Update documentation and gno.land website to point to GitHub Issues for bug reporting and feature requests, and GitHub Discussions for Q&A.
• Synchronous Communications: decide on a "hub" platform to use to host our conversations, and shift our communication channels to using it.
  • One-way bridges and connections:
    • GitHub -> Hub: provide updates from our GitHub repositories on a separate channel, siilar to our #github-feed channel on Discord.
    • Hub -> Discord: mostly meant as a redirection tool, but the main chat could be forwarded one-way to Discord, so that developers landing on our Discord server can see that there is development activity; and they have the channel description specifying how to join the conversation on the Hub.
  • Hub software being considered:
    • Matrix: open protocol, widely used in Open Source. Has modern chat features (images, replies, threads, attachments...) and was built from the beginning with bridging support. We can self-host our own homeserver to ensure performance and scale the server as we need.
    • Mattermost: another alternative, the one I originally proposed. An "open source Slack" written in Go. Supports most slack features
  • The Hub software should enable publicly searchable, indexable (by search engines) and linkable logs on all of its public communication channels.
  • Slack will continue to be used as a communication tool within the wider All in Bits company, and for cross-team efforts.
  • Discord, Telegram, Twitter and Reddit are considered as tools for communicating with the wider Cosmos and Blockchain communities. They are not meant to be used to communicate with developers or builders.
  • Future developments, that can be evaluated as needed:
    • Putting barriers to entry: with a publicly-available hub we might encounter problems relating to spam or to allowing too broad of an audience to access the chat (ideally, we want to maintain it focused, and welcome any technical questions but avoid "community banter"). If necessary, we can consider introducing a requirement for a GitHub account, or other similar measures.
    • IRC: if we have contributors asking for it or any desire coming from the team, we can consider bridging at least the main chat with IRC. Considering @ajnavarro's comment, this is bound to be somewhat imperfect, although, for instance, Matrix was designed partly with the intention of being bridgeable with existing platforms (including, majorly, IRC).
    • Gno.land integration: on top of the platform, we should consider integrating a 2-way integration with the Gno.land blockchain as needed. This has mostly been proposed my @moul during the conversation in Rouen: examples of integrations includes new realms being published, or perhaps providing some kind of faucet (similar to our community faucet) through a bot on the Hub.

Next steps

Based on this, I'd like to re-open up the discussion with this new information for a new round of feedback, objections and other proposals before moving forward.

After that, if the plan stays the same I'd like to work sometime around the last week of the month together with @leohhhn, @waymobetta to set-up GitHub discussions for Q&A and re-organising our resources to point to that; then work towards creating the Hub platform in February and starting a trial run once logs and some of the key items of the new hub are set-up.

Please, provide any feedback you want on this proposal as well as any opinions or previous experiences you've had using Matrix/Mattermost.