Do we need to limit "official" out-of-band collaboration channels?

[JFWooten4]

The website prominently promotes the "TAD3 Developers" Discord, which I have used to configure items such as stablecoin setups which are not otherwise documented on GitHub.¹

Since mid-2024, I have wanted to migrate that venue to Matrix, a public and open-source alternative. However, despite at least three attempts to deploy those changes with collaborations from the greater DRS community, I have not gotten to a point of being able to bring that into production. The biggest gripe with Discord is what makes it a risk of informal support or internal discussion that creates untracked instructions, incident evidence, or identifying communications. Its privacy.

The support system will need strict privacy, and certainly we need to protect production secret keys and API caller credentials. But I always wanted complete public transparency over developmental efforts. Even though the Discord is open to anyone, it requires heavy user authentication effort to make a new account, join the server, and only then navigate to reference URLs, which could be in a private channel.

I've seen Discord used as a corporate support venue, and it looks very immature. You can easily forward confidential discussions from a private section to a public channel. And its user authentication is fine with semi-honest users, but it requires a lot of role permissioning to enforce 2FA and access policies.

Footnotes

1. There has been no other "internal" forum of discussion about this working item. The legacy Zoho-controlled, gatekept, permissioned chat forums such as Cliq have been broadly decommissioned, and they never contained material, nonpublic statements, or correspondence between team members. ↩

[JFWooten4]

I think a much better route is to use Discussions and issues here on GitHub, which relatively mimics Matrix. We get the public channels only, clear chat history, and comment URLs. What we lose in real-time feeds and group chats, I think we gain back and then some in domain specificity and a focus on the working source code.

Namely, there are a lot (three plus) of documentation-only repos in the org which are perfect places for less coding-related discussions. With the work I'm doing on the GitHub intro guide, it should also be simple enough for permissionless proposed amendments to our procedures in the actual repo through PRs. Best of all, anyone (including regulators) can see them through unauthenticated URLs and navigation.

Incident coordination is already proposed to execute here through issues, so that only leaves investor support up in the air, presuming issuers onboard themselves through the DRS general marketing front. That is to say we have much less to manage on onboarding news and hence MNPI when companies only flow in through Issuers.info --> IssuerLink. There will still be the greater DRS Discord, which is much better moderated and can serve as more of a community-building hub for more governance and decisions topics.

Lastly, as to the title, I think it will be difficult and foolish to try to stop independent collaboration offline and such.¹

Footnotes

1. As long as the final result and actual production reference winds up on GitHub, these efforts must matriculate into public artifacts. And they should be reviewed like any other substantial new contribution without deference to preexisting private conversations, should they become necessary. ↩