holic / chirp-city Goto Github PK

Frontend will swap out instances of @frolic.eth with @0xC9C.... before submitting, which the subgraph can pick up for mention notifications. Then we convert back in the frontend.

Ideally the frontend has some nice visual indicator when an at-mention is triggered, and ideally with some autocomplete (we can probably do this with ENS subgraph).

This will help with adding at-mentions, auto-linking URLs, etc.

Draft.js seems like it might be abandoned, and I feel like I've heard a lot of platforms moving to ProseMirror. TipTap is built on ProseMirror, which looks nice: https://tiptap.dev/

And Facebook is about to launch a thing soon: https://outline.dev/

My intention is to get the frontend wired up in a way that @-mentions link up automatically to profiles (like Twitter), but swap out the @-mention text for the corresponding address (if @-mentioning a username) before writing to the contract. So something like

@frolic.eth hey!

becomes

@0xC9C... hey!

(frontend will turn this back into @frolic.eth during display)

That way the subgraph will have an easy time parsing out addresses.

Alternatively, I could just let these get written to the contract as @-mentions of ENS names and let the subgraph parse them out + look up the address. Subgraphs do (as I understand it) do point-in-time calls to other contracts. However, the ENS contracts expect a namehash, which is generally calculated off-chain because it's messy and doing this in Solidity would be too gas heavy (if not impossible). May not be possible without some help from Graph Protocol folks to bake in some ENS helpers.

Something like 1) has ens 2) properly configured with reverse record 3) avatar set up 4) confirmed NFT owner

Most operations should be in the single-digit-cents, so it may make sense to consider paying for gas up to a certain amount to help with onboarding. Paying for gas might also let us do some interesting things where you sign a message once for a session, then we forward any transactions for that session, allowing you to interact/write data without approving a transaction or signature every time.

I personally won't be able to afford to pay everyone's gas, especially if the site takes off. Are there ways around this? Some ideas:

• Users prepay for gas (like a subscription service) in chunks in whatever currency/chain, we convert/bridge automatically
  • Can users withdraw unspent gas? If we've converted and prices have since changed, do they get less back?
• Community funded wallet, maybe through some perks on the site (customizations like colors, badges, NFT mints + secondary, etc.)
• Some sort of governance token? You offset x infrastructure costs (gas, eventually subgraph queries) and you get y tokens. This would end up being inflationary, but that seems fine?

Since the contract is so small, we could theoretically deploy to ~all EVM chains (or at least all that are supported by subgraphs) and let folks post messages from their favorite chain/currency. But we could still aggregate into one subgraph/client!

Need to check if the subgraph can operate on the same model across chains or each model is tied to a chain.

So gas can be paid for by other apps/contracts/wallets

Subgraph already supports this, we just need to settle on syntax and wire up frontend UI.

Current approach uses an ID inside a blockquote syntax like

> chirp:000:000:000

Alternatively, I'm considering using the at-mention syntax (e.g. @chirp:000:000:000) or just full canonical URLs like https://chirp.city/_/chirp:000:000:000. The URL approach is nice because it would mean the plaintext view of the message is still somewhat usable (you can click through to the message being replied to). They're just a little long.

• move subgraph to a testnet-specific one (mostly in name)
• deploy contract to mainnet
• create/deploy mainnet subgraph
• figure out how best to toggle frontend to connect to testnet vs mainnet

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?

event MessageReaction(address from, string messageId, string reaction);

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?

event LogReaction(address from, uint chainId, uint blockNumber, uint logIndex, string reaction);

(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):

event Reaction(address from, string objectId, string reaction);

To get this indexed, we could do:

event Reaction(address indexed from, uint indexed objectIdHash, string objectId, string reaction);

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 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?
• Tokens: erc721:$chainId:$contractAddress:$tokenId anderc1155:$chainId:$contractAddress:$tokenId
  • 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?