We are happy to announce that the initial implementation of the Emote Repository is now live on Görli, Sepolia, Mumbai and MoonbaseAlpha test networks @ 0x311073569e12F7770719497CD3B3Aa2dB0a0C3D9.
2 Likes
Hashcash for emotes. They actually mean something if someone had to pay a little bit for them. If they are free, they are meaningless.
2 Likes
Hi there, just to clarify this EIP is meant to be an extension to ERC721 and ERC1155?
because the title in ERC-6381: Public Non-Fungible Token Emote Repository is different from the one here " Emotable Extension for Non-Fungible Tokens"
1 Like
Initially it was meant to be an extension but we changed our mind after feedback and went for a repository approach which can work with any deployed 721 or 1155. @ThunderDeliverer can we update the title/description?
1 Like
Thank you for pointing this out!
The thread, as well as the initial post, have been updated. 
2 Likes
This is an interesting idea, and I’m intrigued to see it in action! A few questions I had about it as I consider how I’d implement it for collections I work with:
-
Mainnet Cost: I can understand the argument of “they actually mean something if someone had to pay a little bit for them”, however my feel is that “a little bit” per emote most users would only tolerate “a few cents”, not “a few dollars” in cost (I think this is similar in effect to something like Y’alls paying for access/reaction to an article). Would the authors consider updating the standard to uniquely identify tokens as “chain ID, collection address, token ID” rather than just “collection address, token ID”? this would allow an Emote Repository to act as “super-emotes” while any L2 Emote Repository act as lower-ranked emotes, but either of them able to emote for tokens on any chain.
-
Multi-Emote: In addition to a function to emote for one emoji for one token, adding bulk functions for adding a single emote to multiple tokens in the same collection, and adding multiple emotes to a single token in one action would provide a little gas savings for the most common sorts of interactions projects may wish to use it for (for the provided example of a plant NFT needing
, a holder of multiple tokens of that collection would want to on multiple tokens (their owned portfolio) at once) -
Relayer or Abstract Account Emoting: Allow emoting on behalf of an address other than
msg.senderby providing a signature from them (ERC712 or other). This would allow emotes to be bundled up (some gas savings) and allow off-chain processes to grant emotes (allows for a system where a
from a specific abstract account identifier is “worth more” than the same emote from a random public user)
2 Likes
Thank you for this productive feedback! It gave us a lot to think about, and here are our thoughts on the subjects you raised:
- If you have to pay a small fee to react to a token, you will only react to the tokens you feel really deserve. This incentivizes meaningful reactions as well as de-incentivizes spamming the emotes.
- We checked, and emoting is cheaper than an ERC-20 transfer.
- An ERC can be used in any chain that supports EVMs. While keeping emoting on one chain to NFTs of another might be fun, it might get confusing when you try to react to Ethereum NFT in a Polkadot-based parachain.
- The ability for NFTs to evolve or react to the emotes programmatically requires the repository to reside on the same chain as the collection.
This is a great idea! We will update the proposal with multi-emoters shortly!
This is a good suggestion as well. There are several possible combinations to approach this, and we will evaluate each while implementing the extended proposal.
1 Like
I think in general penalizing all users (assume they’re spammers and make them pay a cost to show they’re not) is not the greatest spam-prevention method (instead the front-end or client implementation logic can filter out spam (e.g. the plant NFT needing could have their app logic only count emotes from addresses that fulfilled other requirements. That way others could spam the emote on tokens, but they’d just be ignored by the application.)
The intent here is that a common ERC6381 Repository/Registry could be set up on each EVM chain, correct? Therefore if a collection already exists on mainnet, and wanted to make a game with frequent interactions, they could use the ERC6381 Repository on another chain, either pointing it at a dummy contract on that other chain to represent the NFT collection, or the mainnet contract’s address (as there’s a low likelihood of the same address on another chain being a different collection). That logic could be baked into a collection’s app, but having a Chain ID in the ERC6381 would allow that to be more human-friendly/evident that the emote is meant for an asset that’s on another chain.
From all the initial suggestions (which I really liked and supported on internal discussions with @ThunderDeliverer), this is the only one that I don’t agree with. It just makes it very hard for dApps to keep track of the emotes of multiple collections if they have to look on every chain for them.
If a particular collection wants to do this, they should take care of either deploying an alternate repository to track their collection, or as you suggested, deploying a dummy contract on the alternate chain and use it keep track of the reactions to the original collection. I don’t see the need to increase complexity of the contract for this, as it’s up to each collection to manage.
1 Like
To be clear, my proposal wasn’t to force dApps to look on every chain; adding in the chain ID as metadata would simply make it possible for dApps that wanted to, to use a registry on another chain. I would expect each dApp to choose for themselves which chain(s) to use and which registry/registries to use. If some user emoted to the “wrong registry” for a specific dApp, it would be on the blockchain, just ignored by the dApp.
The intent was to make the standard more flexible to allow the possibility of that sort of structure, not force all apps to be multi-chain.
I just wanted to update you all on the development of this proposal. We’ve published the updated proposal with bulk and presigned actions, as well as updated the last call deadline.
We’ve addressed this in the updated proposal in the Rationale section. We gave it a lot of thought and think this is the best design decision moving forward with the proposal:
During the course of discussion of the proposal, a suggestion arose that we could add chain ID as a parameter when reacting to a token. This would allow the users to emote on the token of one chain on another chain.
We decided against this as we feel that additional parameter would rarely be used and would add additional cost to the reaction transactions. If the collection smart contract wants to utilize on-chain emotes to tokens they contain, they require the reactions to be recorded on the same chain. Marketplaces and wallets integrating this proposal will rely on reactions to reside in the same chain as well, because if chain ID parameter was supported this would mean that they would need to query the repository smart contract on all of the chains the repository is deployed in order to get the reactions for a given token.
Additionally, if the collection creator wants users to record their reactions on a different chain, they can still direct the users to do just that. The repository does not validate the existence of the token being reacted to, which in theory means that you can react to non-existent token or to a token that does not exist yet. The likelihood of a different collection existing at the same address on another chain is significantly low, so the users can react using the collection’s address on another chain and it is very unlikely that they will unintentionally react to another collection’s token.
1 Like
The repository has now been deployed to three mainnets; Ethereum mainnet, Polygon, and Moonbeam @ 0x31107354b61A0412E722455A771bC462901668eA
https://etherscan.io/address/0x31107354b61a0412e722455a771bc462901668ea#code
If you wish to have the repository deployed to another network, please reach out!
1 Like