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.

[moul]

Start using GitHub discussions again as the forum for questions and answers.

I have never had a positive experience with GitHub discussions. Could someone with a more positive experience explain what makes GitHub discussions combined with issues better than just using GH issues?

Matrix VS Mattermost

One thing I appreciate about Matrix is that, like Discord versus Slack, people can join using their existing account. However, on Mattermost, they will need to register.

Can anyone justify why Mattermost is superior to Matrix for our needs?

The Hub software should enable publicly searchable, indexable (by search engines) and linkable logs on all of its public communication channels.

Yes.

One option is to store the logs regularly on GitHub.

IRC

Native support with Matrix.

Gno.land integration

THIS!

[thehowl]

I have never had a positive experience with GitHub discussions. Could someone with a more positive experience explain what makes GitHub discussions combined with issues better than just using GH issues?

For this, it just came up during the workshop.

I personally don't have a strong preference, if not that I consider the fact that it integrates with GitHub issues as a plus.

That said, what I'm looking to have is a place that is the closest equivalent to a Stack Overflow that we can use for as long as we don't have a tag on SO.

I would still prefer something which works with the key features of SO. (Answers are sorted by reputation / accepted answer, not chronologically; users are encouraged to answer their own questions; discourse and chit-chat is avoided, providing "documentation" for anyone with the same problem on the internet is more important than interacting with other gnophers in the moment).

One thing I appreciate about Matrix is that, like Discord versus Slack, people can join using their existing account. However, on Mattermost, they will need to register.

Yep, agreed.

The way I personally see it: Matrix is the likely better option. I still think we should self-host (mostly because I see the matrix.org instance/homeserver as being very big, and resulting in unbearably slow server-side load times in my experience using it). But it is much more aligned philosophically on all fronts: an open protocol, many clients, can bring over your existing account, etc.

Mattermost, at this point, is to me a "centralised fallback" if we find any reason for which Matrix cannot suit our needs.

[ajnavarro]

I have a different view on this (apart from my previous comments and conversations about the topic).

It's important to talk about two kinds of information sharing: structured and unstructured. Structured information is stuff like documents, specifications, or databases. It’s organized and easy to search. This is the kind of information that’s really useful in the long run.

Chat, on the other hand, is unstructured. It's great for quick, casual conversations, but it's not organized and it's hard to find information later on. Information in chats can be easily lost over time, making it not so great for keeping as a reference.

Because of this, I’m not sure if indexing chats is the best idea for us. Chats are good for quick talks, but when we need reliable and easy-to-find information, it's better to have well-written documents and clear specifications. These are the types of information that last and are really helpful later.

Indexing chats might help in the short term, but for long-term use and finding information easily, having structured information is much better. Maybe we could find a way to write down the important stuff from chats into documents or other organized formats.

[thehowl]

ChatGPT tl;dr

Morgan emphasizes the importance of documenting chat conversations for long-term project growth. While acknowledging the value of structured information like documents, he argues that recording chats is also important for understanding past decisions and their context. He sees it, together with the GitHub issue corpus, as a "preventive archiving for posterity," allowing future contributors to explore discussions and debates that shaped the project. Morgan believes that, as the project evolves, having access to comprehensive historical records will prevent repeated debates and ensure a deeper understanding of decision-making. He draws parallels with recording meeting minutes and highlights the risk of losing context if conversations are not archived. Morgan's perspective stems from a commitment to transparency, accessibility, and the belief that a well-documented history will benefit the project's governance in the long run.

---

Indexing chats might help in the short term, but for long-term use and finding information easily, having structured information is much better. Maybe we could find a way to write down the important stuff from chats into documents or other organized formats.

Of course. There is obviously a need to have information in structured and clear reference documents, which really serve in the long term as our documentation. I don't see the importance of chat logs as being authoritative documents, or as a substitute for doing the hard work of documenting stuff.

I see the argument here as being a bit philosophical. Essentially, I see documenting our chats as part of a more general necessity to document all of our decision making when building the chain.

There is an underlying assumption here which is that the project will grow at one point to be much beyond what we are doing today, and that people other than the core team today will be in charge of decision-making on crucial components of the chain and the DAOs. This assumption may turn out to be wrong (it's impossible to predict the future and thus tell if the project will succeed and be as big as we hope it will be). However, if it does succeed, it will be better if the Gno.land blockchain and central DAOs we're building today have the capacity to access all the conversations and discussions that lead to things being structured the way they are. That is, it will be important not only to know how things are structured on the DAOs and blockchain, but also to understand what in the past was considered as a solution and why it was not adopted.

Under this principle, we are also recording and publishing the minutes of our meetings.

In other words, the point I see to recording the meeting as being a form of "preventive archiving for posterity", and making it possible in the future for anyone to roll up their sleeves, and look through heaps of GitHub issues, meeting minutes and being able to fully research all of the context that lead to a certain decision. The full extent of all of the reasoning of a decision cannot always be documented in conversations and issue comments (for instance, even when discussing, two parties may already agreed on a given notion without need for discussion, so that notion will not be debated), but most of the "contentious" or "controversial" issues will pop up, be discussed and hopefully have a consensus reached.

In the projects that don't do this, context that leads up to a decision remains within the authors and "those present in the room". If a project survives the test of time, the context of the decision is lost and the future governance is doomed to eventually repeat some debates already discussed, because they're unaware of anything that came before them.

This conversation itself is an example of what I'm talking about. At this point, we may turn out to do either decision (not storing logs of our chats, or indeed storing logs of our chats, though you know which one I favour ;) ). Let's assume that this conversation instead happens on an internal, ephemeral medium like Signal, whereby new chat participants cannot read previous conversations. Let's also assume for a second that this project is continued being worked on for a long time to come.

Eventually, even internally at AiB/NewTendermint, our current core team will change and be replaced (most of us will change jobs, and even assuming if we don't our ageing will eventually come around). Thus of this conversation there will be no trace in any future archive, and at some point, the future Gnophers will be doomed to ask again the question "Should we publish our conversations or not?". We would be stuck asking the same questions because the "collective conscience" cannot read and study what happened before its current participants, and be left to hope that the oral tradition and the team leaders properly instruct any newcomers on the context, history and principles of all decision-making that has been made.

Most conversations do already happen in public mediums like GitHub. We did have some which were on Core-Contribs. We will have more as we welcome more developers to join us, develop on Gno.land, and ask questions. Ideally, most of these still happen on GitHub issues or the Q&A platform that I also talked about. I think there is no real way to ensure and enforce that all "serious conversations" happen off-chat, though.

Sorry I got into a philosophical essay for this, but I care deeply about archiving and the job of historians. It is pretentious to assume that our project will have historians; but the way we're building it, we want to make sure that if they do eventually happen, they won't have a hard time figuring out the decisional origin of everything :)

[grepsuzette]

Nice thread. thanks @thehowl for the link.

moul said:

IRC

Native support with Matrix.

Gno.land integration

THIS!

As an old IRC user, I haven't used Matrix, but I can respect their philosophy, It would be awesome to connect from a text client.

Anything with those characteristics is more than good to me:

• connectable with irc (can open in a tab in vim or tmux) or a text client,
• open-source, not-for-profit, to eliminate surprises/misalignements,
• old and stable enough, or strongly aligned with Unix principles.

A light GUI is also good. Text client make it much more likely for my computer to stay connected however.

About the rest: simplicity precedes organization. A few channels is enough. As long as there are archives (or even bots), a search feature can always be done later.

Anyway glad to see there are some discussions about this. Can't wait :)

[moul]

TODO(@moul): clarify our goal to transition to self-hosted Matrix soon and eliminate Slack internally + reduce Signal. Waiting for the new DevOps to join.