Trying to think through some ideas for reactions. Since most platforms are going the way of "react with any emoji", it makes sense to me to start with more than just likes/favorites, at least at the protocol level. The indexer/frontend can decide which ones are allowed.
Possible approaches
1. Text-based and human-readable, like iMessage → SMS
For replies/"subtweets", I'll probably be using a regular PublicMessage with the chirp ID inside the message text. The subgraph will parse these out and associate the message objects together and the frontend will do whatever replace-with-embed necessary.
We could do something similar for reactions like iMessage does when reacting to an SMS, where it might look like
> chirp:137:23896424:107
Reacted with "👍"
I am liking the "degrades to human readable text" approach. But the downside is that the Chirp City subgraph and any future indexers/clients would need to know about and parse these messages and associate objects, etc. together. Seems like lots of room for error without structured data?
2. Reaction event
We could create a separate event for reactions specifically. This leans more into the "structured data" approach without being too heavy, and keeps the PublicMessage channels clear in case there are several clients listening/indexing these but haven't caught up with new syntaxes/features like the above.
There's a few approaches here I can think of. The obvious one uses the message ID like above as the reference point. We won't be able to add indexed to the messageId because it's a dynamic length string, though. Maybe a hash stored in a uint, just for the purposes of filtering? Is an indexed, fixed-length string possible?
The message ID is just a pointer to a log item, so we could break it out into its component parts. The downside here is that we can use indexed on a maximum of three fields, but we have ~four that I could see being useful to have indexed. Which do we leave out?
(using "log" here instead of "chirp" in case it becomes broadly useful to have a general purpose reaction event for log items.
Another possibility is using a generic object ID, rather than just a message, which lets you react to ~anything on the blockchain (see below for schema/spec proposal):
It might be useful to come up with a standard set of IDs that correspond to blockchain entities for referencing later, then a Reaction event could refer to any kind of object, not just a message/log/event. Same with the reply/embed syntax.
Events/logs: log:$chainId:$blockNumber:$logIndex e.g. log:137:23896424:107
Is it possible/easy to distinguish different logs/events from each other at index time? e.g. can I determine based on the above reference point that a log/event is a PublicMessage from the ChirpCity contract?
Can we quickly/easily determine what kind of contract interface is used at index time and simplify this to just token:$chainId:$contractAddress:$tokenId?
Addresses/contracts, because they're a fixed length, can probably remain as-is, e.g. 0xC9C022FCFebE730710aE93CA9247c5Ec9d9236d0.
Is it useful to distinguish between address vs. contract, or can this be done in the indexing step?
Is it useful to have the chainId included if addresses/wallets are technically compatible across EVM chains?
Trying to think through some ideas for reactions. Since most platforms are going the way of "react with any emoji", it makes sense to me to start with more than just likes/favorites, at least at the protocol level. The indexer/frontend can decide which ones are allowed.
Possible approaches
1. Text-based and human-readable, like iMessage → SMS
For replies/"subtweets", I'll probably be using a regular
PublicMessagewith the chirp ID inside the message text. The subgraph will parse these out and associate the message objects together and the frontend will do whatever replace-with-embed necessary.We could do something similar for reactions like iMessage does when reacting to an SMS, where it might look like
I am liking the "degrades to human readable text" approach. But the downside is that the Chirp City subgraph and any future indexers/clients would need to know about and parse these messages and associate objects, etc. together. Seems like lots of room for error without structured data?
2. Reaction event
We could create a separate event for reactions specifically. This leans more into the "structured data" approach without being too heavy, and keeps the
PublicMessagechannels clear in case there are several clients listening/indexing these but haven't caught up with new syntaxes/features like the above.There's a few approaches here I can think of. The obvious one uses the message ID like above as the reference point. We won't be able to add
indexedto themessageIdbecause it's a dynamic length string, though. Maybe a hash stored in a uint, just for the purposes of filtering? Is an indexed, fixed-length string possible?The message ID is just a pointer to a log item, so we could break it out into its component parts. The downside here is that we can use
indexedon a maximum of three fields, but we have ~four that I could see being useful to have indexed. Which do we leave out?(using "log" here instead of "chirp" in case it becomes broadly useful to have a general purpose reaction event for log items.
Another possibility is using a generic object ID, rather than just a message, which lets you react to ~anything on the blockchain (see below for schema/spec proposal):
To get this indexed, we could do:
Related: object ID schema
It might be useful to come up with a standard set of IDs that correspond to blockchain entities for referencing later, then a
Reactionevent could refer to any kind of object, not just a message/log/event. Same with the reply/embed syntax.log:$chainId:$blockNumber:$logIndexe.g.log:137:23896424:107PublicMessagefrom theChirpCitycontract?erc721:$chainId:$contractAddress:$tokenIdanderc1155:$chainId:$contractAddress:$tokenIdtoken:$chainId:$contractAddress:$tokenId?0xC9C022FCFebE730710aE93CA9247c5Ec9d9236d0.chainIdincluded if addresses/wallets are technically compatible across EVM chains?