Corralling communications across the Web3 landscape
In an environment headed towards decentralization, the one thing we actually need centralized is the way we communicate.
The decentralized web — or Web3 as it’s more commonly being referred to as — is an interesting one that propositions users to be the sole owners of their digital property. A Web3 user’s assets could be in the form of financial digital assets such as Bitcoin or other fungible cryptocurrency tokens, an NFT (the non-fungible sort of crypto token), or a user’s data. There are more platforms turning up that allow for users to be the custodians of their own digital and intellectual properties, taking the control away from centralized entities, or at least with that intention to some extent. The models are still nascent and there are major strides to be taken in the way of the Web3 user experience, however the pace is being set and the adoption seems to be coming in steadily.
With all of the ideas around decentralization, the one place in which the opposite might be required for consideration is in communications management. Now, I’m not suggesting that communication ought to be owned by centralized entities and all our data housed on their centralized servers, which is currently the status quo. Not at all. In fact, I am all for the ideas of decentralized platforms that utilize a DAO (decentralized autonomous organization) or some form of community governance to cast votes on protocol governance and use decentralized storage solutions such as IPFS (InterPlanetary File System) or ArWeave to warehouse the data in some form of encrypted format. Heck, I’m even writing this article on the Skiff Web3 email and document platform (https://skiff.com). However, what I am suggesting is that there should exist a standard or model in which communications are handled for Web3 ventures, organizations and communities despite the platform chosen to operate on.
As we unpack the more common platforms being used in Web3 communications and commuity building environments, it will be evidently clear that there isn’t a defacto decentralized communications program that offers a reasonable way to corral all communications from both the private organizational layer through to the public community layer. The applications mentioned in this article do lend themselves to the idea of building a community, some of which offer the ability to segregate the private and public layers. Having close proximity to a community can be very advantageous. However, with that being said, they are in fact centralized entities, operating on centralized servers. So there is much room for improvement in the way of decentralized communications platforms and I get the sense as though some of these challenges are being worked on by some of the innovators in the Web3 space, but to date there isn’t a viable option that I’m aware of.
What about Slack-ing it?
With remote and centralized teams Slack has established itself among giants within the space, setting the pace with applications from conglomerates such as Google and Microsoft to compete with Meet and Teams, respectively. It offers channel segregation, which is great, as well as direct messaging. It integrates with plenty of business and technical applications which expand its value proposition. In fact, I would go as far as saying that Slack has become one of those default team business communication apps, particularly for agile startups.
Although it boasts some of the highest user adoption rates of any software in recent times, some of the areas that Slack lacks are particular to the evolution in Web3 team and community communications. For internal and private groups, Slack works just fine, but this article focuses on a broader environment that spans beyond that of a private workgroup. The lack of controls over private channels, user role designations and the price per user can all start to add up in a negative way once growth within an organization trancends its hypothetical virtual walls.
So, let’s get into how things are currently often organized in terms of the layers within a Web3 community’s communications protocols.
Telegram as the first layer
Telegram typically serves well as a general catch-all for communities to chatter and discuss, allowing potential investors the opportunity to get a sense of what the community is about as well as obtain information which both moderators and community members may provide. However, some Telegram communities can be somewhat overwhelming from the perspective of a new entrant.
Think of Telegram as a combination of Twitter, where you can have a particular @username and Whatsapp where you can be invited or create private groups, but also join public groups (some of which can be thousands of members large) as well as channels which are an outbound communication format. Typically there are a few key members that do most of the talking and in some cases questions from new entrants are dismissed unfairly. This isn’t always the case and it isn’t meant to generalize but it does happen in some cliquey maximalist communities. These large groups will often require a team of administrators that work around the clock in addition to spam bots that uphold the rules and keep people from misbehaving. Most groups are well managed but having worked closely with many community managers and group administrators I can tell you that the number 1 complaint is the overwhelming amount of nonsense that has to be dealt with regularly, which comes in the way of bots or egregious (non)community members.
Using Discord to structure communications
Discord’s role within a community serves to streamline communications by threading conversations into channels, which maintain relativity to the discussions being had. Those channels can be for either text or voice and are managed in channel groups. For example, a general chat channel on a Discord server can have topics that span across anything and everything related (or unrelated, depending on the server rules) to a project or community. Consider this to be similar to what the Telegram main group would be. Adversely, channels that are specific would maintain a threaded and relevant dialogue pertaining to the subject of the channel, bar none. You can also have push notification channels to publish posts, tweets, content, etc. that aggregate from all other platforms pushing out the organization’s content. A single place that aggregates it all. Seems well organized, so far.
Although it is far from perfect, a Discord server from a token holder or community member’s perspective can be quite the opposite to what Telegram offers — a quieter, more organized and streamlined environment for information, productivity, team engagement, product enhancement, bug reporting and opportunities.
The ability to assign roles to Discord users allows for effective scaling of teams. This could be one of the most powerful functions within Discord. User roles in a Discord server act as gates or barriers to particular channels because the user roles themselves maintain a hierarchical order. In that order its is determined what each user role’s access priviledges are, in addition to what their limitations are on the server.
For instance, onboarding new members can have a role associated with their status as being a new-hire, in-training or on-boarding so that other team members are aware and can manage expectations, as well as lend a hand where required. As they start to develop into their actual role, they may assume additional roles within the Discord server which allows them further access within the server’s communication channels.
Here’s a quick example:
Upon joining a new Discord community, members may have a “@general” community member role that allows them access to a certain set of surface layer public community channels, not having access to private team channels and only being able to read, not post on community public channels.
Once that user verifies and agrees to all of the rules on the server, they may earn a new user role which grants them permission to comment and post on the general public community channels.
That user may then apply to work with the team and be granted a new role for @newhire or @onboarding, which would give that user access to particular private channels where interviews, training and other onboarding efforts would take place.
Eventually that user would be given the @team role, as well as other particular roles that relate to their position, that would give them access to the channels they need in order to effectively interact with their peers on the entire team on general team channels, but also within their subteams or subgroups particularly for their work.
All of this occurs in tandem, the team communications grows, the public community comms grow, everything happens in once place congruently. This concept is a cornerstone to how Web3 teams are built directly from the community. It transcends the legacy onboarding methods of applying to work through job posts, agencies and head hunters. In this case the community and the team grow symbiotically and synergistically.
In terms of the flexibility for teams and communities, Discord seems to hold its own when it comes to specialized access for community holders that are in posession of a particular fungible token, such as an ERC20 (or other fungible network token) or Non-Fungible Token, otherwise known as an NFT.
Tokenized access for the token economy
For token holders Discord can be a place where a DeFi pseudo DAO may be managed. Token holders will be able to connect their wallets to 3rd party applications such as the collab.land verification bot which will determine a user’s eligibility to access private channels in which holding a particular fungible project token (or NFT) is a requirement. The benefits of this token-holder only channel could allow token holders to have access to the leadership team in some capacity. It can also serve as a forum for innovative ideas, potentially allowing for voting to take place for particular platform or protocol governance in order to provide incentive for holders of the token to partake in the future of the platform and engagement.
For the general community, there could be other useful resources that are not only benefitial to them but to the team as well, such as
- As mentioned above, a hiring channel to recruit team members directly from within the community
- Bug and suggestions channels for the development team to always be logging the requests and concerns of the community, facilitaed with a natively integrated ticketing system
- Foreign language channels can be implemented to make it a truly globally inclusive platform and experience.
The idea of encouraging users to join a Discord server is not to undermine the Telegram group, but rather to engage users in a more intimate way with the product team. Discord servers that achieve a number of users past a threshold count are also eligible to be discoverable, making it even easier for non-members of a particular community to find and join a community Discord server. Not to mention, Discord has become a defacto Web3 communications platform because of its ability to implement bots to assist with administration and controls, linking to external platforms and for its flexibility in mitigating communications. It also enables more streamlined, threaded conversations that are topic related — similar to Slack — making for easy reference and correlation to a project management task board or document repository, and for informational security. This is what operations managers look for when tying in applications across a workflow; seamless integration and crossover with actionable triggers across productivity and communications platforms.
Web3 doesn’t yet have a native decentralized application for community and team communications management (that I’m aware of). However, I am hopeful that a decentralized communications platform that offers some of the features mentioned will be available sometime sooner than later (if it doesn’t already exist that I don’t know of). Currently, it seems as though the Discord experience — originally created to facilitate multiplayer online video gaming communities — has found its way into becoming an almost standard tool for Web3 projects to manage their internal team communications privately, while also managing the dialogue with the public community, giving team and community members a single source for communications and a thin, single layer of separation between them. It’s no surprise that the seque was so seamless for Web3 natives to adopt Discord as a staple platform. One can draw many similarities to the communities of tokenized economies and that of the online gaming community. Both operate and exist online, digitally and have a decentralized, non-contiguos community within the metaverse. That’s right, the metaverse. Although the term has been catching a lot of attention recently, primarily because of Facebook rebranding their parent organization to Meta, it can be argued that we are in fact already living within the metaverse. That however, is a topic for another day.
