dIRC implements the ERC-1155 Multi Token Standard to establish relationships between a user and his followers. Using the Multi Token Standard, each user is able to establish a one-to-many relationship with his followers. Since the User and Followers tokens are inextricably linked (same token type), users can bring their followers across various dApps, allowing them to "own their followers".

Soulbound

Every token is a soulbound token. Our definition of soulbound = non-transferable but can be burned. The tokens need to be soulbound as:

• Relationships are established at the wallet address level, an immutable construct.

• Each relationship needs to be a user driven choice - i.e., a user chooses to mint a Follow Token, or a Channel Token.

• The ability to allow transferability will lead to spam. While the receiving party can burn them, the hassle to do so defeats the entire purpose of what we are trying to do here.

• In the case of channels, admins have the ability to burn a members’ Channel Token, akin to kicking someone out of a group chat/discord channel.

User Token

When a user first enters the dApp, he mints a User Token, soulbound to his connected wallet address.

The User Token functions as an extension of his wallet address, allowing us to add more functionalities to it that is compatible within dIRC (and beyond).

This does not mean a real-life person can only have 1 on-chain identity. Remember, a seed phrase holds multiple private/public keys, with in turn holds a public address each. As such, a person in real-life can hold multiple private keys, each with multiple wallet addresses that holds a User Token each.

An important note. Unlike other protocols, we are not allowing users to pick their profile name and picture. That problem is already solved. We are integrating ENS domains as the only way to view a human-readable profile name, and ENS-registered NFTs as the only way to showcase a profile picture. See here on how to set them up.

Follow Token

Once a User Token is minted to existence, Follow Tokens can be permissionlessly minted by other users.

Followers that want to receive messages from a user will need to mint his Follow Token. Follow Tokens can be burned anytime (to unfollow a user). There is no limit to the number of mints of Follow Token- i.e., you can mint, and burn, and mint, and burn a user's Follow Token if you wish.

Channel Token

Anyone can create a channel permissionlessly.

When a user creates a channel, he is minting into existence a Channel Token, and is the owner of the channel. Once a Channel Token is created, other users can join the channel (and access the content) by minting the Channel Token as well.

Channels can have token-gated conditions set on it. The way it works is: The Channel Token can only be minted if a user holds a certain amount of ERC-20, ERC-721, or ERC-1155 tokens. The contract checks for this condition before allowing the user to mint.

The owner can set the list of admins of a channel. This list of wallet addresses (and the owner) are given special rights, which includes:

• Talk in read-only channels

• Kick members out of the channel

Chat Token

The ability to chat in a channel is a separate token - Chat Token. For read-only (announcement) channels, the owner disabled the minting of Chat Token, apart from him and the admins. For read-and-write (discussion) channels, the mint is enabled for all.

Channel settings

In summary, the owner of a channel is able to set a few parameters:

• List of admins: By wallet addresses. E.g., A DAO setting their admin team that will help manage their channel.

• Token-gated: E.g. The Pengus creates a channel for other Pengus to join the huddle and chill.

• Read-only vs. read-and-write: Read-only settings keep the channel clean and are useful for announcements. Read-and-write settings drive discussions among channel participants, but would crowd out the channel.

A short note on token-gating

Token-gated channels are a new paradigm in web3 messaging. NFTs showed us that people like being within a community. What that community represents might not be clear for everyone, but the idea holds. The idea of token-gating as a way to find your own communities could be an interesting idea, with a few experiments taking place right now.

Unlike other solutions out there that rely on centralized servers/bots to check for eligibility, our conditions are written on the smart contract itself.

Post-MVP, we plan to implement keepers that will continuously check members for their eligibility, and to flag to the admins those members that are no longer eligible - e.g., they sold their NFT. It is then up to the admin to decide whether to kick them out or not.

dIRC implements the ERC-1155 Multi Token Standard to establish relationships between a user and his followers. Using the Multi Token Standard, each user is able to establish a one-to-many relationship with his followers. Since the User and Followers tokens are inextricably linked (same token type), users can bring their followers across various dApps, allowing them to "own their followers".

Soulbound

Every token is a soulbound token. Our definition of soulbound = non-transferable but can be burned. The tokens need to be soulbound as:

• Relationships are established at the wallet address level, an immutable construct.

• Each relationship needs to be a user driven choice - i.e., a user chooses to mint a Follow Token, or a Channel Token.

• The ability to allow transferability will lead to spam. While the receiving party can burn them, the hassle to do so defeats the entire purpose of what we are trying to do here.

• In the case of channels, admins have the ability to burn a members’ Channel Token, akin to kicking someone out of a group chat/discord channel.

User Token

When a user first enters the dApp, he mints a User Token, soulbound to his connected wallet address.

The User Token functions as an extension of his wallet address, allowing us to add more functionalities to it that is compatible within dIRC (and beyond).

This does not mean a real-life person can only have 1 on-chain identity. Remember, a seed phrase holds multiple private/public keys, with in turn holds a public address each. As such, a person in real-life can hold multiple private keys, each with multiple wallet addresses that holds a User Token each.

An important note. Unlike other protocols, we are not allowing users to pick their profile name and picture. That problem is already solved. We are integrating ENS domains as the only way to view a human-readable profile name, and ENS-registered NFTs as the only way to showcase a profile picture. See here on how to set them up.

Follow Token

Once a User Token is minted to existence, Follow Tokens can be permissionlessly minted by other users.

Followers that want to receive messages from a user will need to mint his Follow Token. Follow Tokens can be burned anytime (to unfollow a user). There is no limit to the number of mints of Follow Token- i.e., you can mint, and burn, and mint, and burn a user's Follow Token if you wish.

Channel Token

Anyone can create a channel permissionlessly.

When a user creates a channel, he is minting into existence a Channel Token, and is the owner of the channel. Once a Channel Token is created, other users can join the channel (and access the content) by minting the Channel Token as well.

Channels can have token-gated conditions set on it. The way it works is: The Channel Token can only be minted if a user holds a certain amount of ERC-20, ERC-721, or ERC-1155 tokens. The contract checks for this condition before allowing the user to mint.

The owner can set the list of admins of a channel. This list of wallet addresses (and the owner) are given special rights, which includes:

• Talk in read-only channels

• Kick members out of the channel

Chat Token

The ability to chat in a channel is a separate token - Chat Token. For read-only (announcement) channels, the owner disabled the minting of Chat Token, apart from him and the admins. For read-and-write (discussion) channels, the mint is enabled for all.

Channel settings

In summary, the owner of a channel is able to set a few parameters:

• List of admins: By wallet addresses. E.g., A DAO setting their admin team that will help manage their channel.

• Token-gated: E.g. The Pengus creates a channel for other Pengus to join the huddle and chill.

• Read-only vs. read-and-write: Read-only settings keep the channel clean and are useful for announcements. Read-and-write settings drive discussions among channel participants, but would crowd out the channel.

A short note on token-gating

Token-gated channels are a new paradigm in web3 messaging. NFTs showed us that people like being within a community. What that community represents might not be clear for everyone, but the idea holds. The idea of token-gating as a way to find your own communities could be an interesting idea, with a few experiments taking place right now.

Unlike other solutions out there that rely on centralized servers/bots to check for eligibility, our conditions are written on the smart contract itself.

Post-MVP, we plan to implement keepers that will continuously check members for their eligibility, and to flag to the admins those members that are no longer eligible - e.g., they sold their NFT. It is then up to the admin to decide whether to kick them out or not.