Samuel ツ on Warpcast

Geoff Golberg pfp

👀👀 $degen – not frames – has been driving Farcaster's growth 📈📈 (data from The Indexing Company; h/t to @aperture)

8 replies

2 recasts

13 reactions

Ghostlinkz pfp

@ghostlinkz.eth

What changes would you make? Would you simply disallow devs from adding tipping through replies, or is there another solution you have in mind?

2 replies

0 recast

0 reaction

KMac🍌 ⏩ pfp

Tips could be protocol level reactions (extend with two fields ticker & amount) or a new message type or outsourced to frame servers & processed onchain. There’s no way to stop in cast tipping. Would be super curious to hear how much activity is now in dc & group chats vs onHub

1 reply

0 recast

0 reaction

Ghostlinkz pfp

@ghostlinkz.eth

You could filter out reply tipping at the client level. What’s the reason for not having reaction tips at the protocol level? I assumed it’s because Apple doesn’t like it, but clients don’t need to add it if they don’t want to? I also want to see some data about dc/group chat.

1 reply

0 recast

0 reaction

KMac🍌 ⏩ pfp

Filtering at client is fine when the context is isolated. eg this is a cast. This is a tip. Mix the two & 🤦. That’s why new reaction or msg type suggestion. Why not do that? Good q. Same q for why not have frame interactions (ie messages) onHub? 🤷🏻‍♂️ Guessing: speed of iteration 😒

1 reply

0 recast

0 reaction

Samuel ツ pfp

@samuellhuber.eth

I would prefer cast actions for tipping with frames to show allowances and received tips vs protocol Keep protocol as lean as possible. No need to have tips there

1 reply

0 recast

0 reaction

KMac🍌 ⏩ pfp

Agreed on not increasing what the protocol does (verify, store & sync). I wonder in your suggestion, how the recipient of the an offchain, frame base tip would hear about the tip? A cast? Seems heavy if not a new message type. How are you envisioning that?

1 reply

0 recast

0 reaction

Samuel ツ pfp

@samuellhuber.eth

Either bot replies (removes 1 tip reply from the set of messages sent) Or even better programmatic DCs Bot will DM you every tip you get That way (until DMs are in protocol) the protocol is clear

2 replies

0 recast

0 reaction

KMac🍌 ⏩ pfp

Keeping protocol ‘clear’ seems like a non issue. It’s gonna be onHub or onchain I think. Having messages on a frame dev’s server is a sad side effect of the existing trade offs. If msg is private whocares where it’s stored. If it’s public then it’s ‘on’ something decentralized I like the dc idea🤝

1 reply

0 recast

0 reaction

Samuel ツ pfp

@samuellhuber.eth

For now DCs would mean any alt client would not get notifications but they‘d have the frames to check For DC: the hard thing to solve for is how to make sure if I store the message for the future that it can’t be decrypted then

1 reply

0 recast

0 reaction

KMac🍌 ⏩ pfp

We are living in dwr’s world. I will not dev to the ‘for now’ use case it’s just too painful. Too many breaking changes & trust assumptions for me Frames users need to revisit kinda suck when the context is ephemeral. I’m sure some alt apps will figure something out for notifs Missed your point wrt decrypt

0 reply

0 recast

0 reaction