What makes a good feature for a protocol-level subscription?

1. Features are enforced across clients — Snapchain, onchain contracts,  protocol fname and DC servers, etc.

2. Any app-level feature will create incentive for other clients to offer as a top of funnel "our client gives you this for FREE!". This is consumer surplus.

3. Ultimately, protocol-based social networks should generate a lot of consumer surplus in terms of what's available in the standard UX for most clients.

4. Conversely, it's tricky to add features that are 1) valuable 2) can be enforced at the protocol-level. 

5. An additional wrinkle is even clients can fudge protocol-level features (e.g. we support 900 character casts + a link for long casts and render them fully in our client; we link to a slideshow mini app but render the images in our client). This is why the protocol having a "official" client that is protocol-aligned and has high relative market share in the long run is good for the protocol.

This is where I get a bit confused. How hard is it to bake things into the protocol so all clients can use them vs making a feature in the Farcaster client app?

Pi-chi.eth Artist /animeoutcasts
Hosting: /sakura /kyoto /momiji  /anime-manga /farcasterunion

https://portrait.so/pichi

Second channels question

Again, looking for input. No imminent change. 

Assume a “yes” to the below makes it more likely that we unlock channel innovation in other apps and they are fully decentralized and that happens *a lot* sooner than alternatives.

Here’s the hypothetical:

1. We remove all the existing channel functionality from Farcaster app.

2. All old and future channel casts still appear in the app (ie FIP-2 casts today but we make them a bit nicer than they are now).

3. In order to cast in a channel you use a mini app or another client like Cura or Zapper.

Yes or No?

feels like the right place to reference this. we’re inclined to take the bargain you laid out but we know @pichi feels differently

make the case for pushing channel primitives into the protocol, and perhaps also speak to how that would allow for it to be adopted by the 1st party client down the road

feels like the right place to reference this. we’re inclined to take the bargain you laid out but we know @pichi feels differently

make the case for pushing channel primitives into the protocol, and perhaps also speak to how that would allow for it to be adopted by the 1st party client down the road https://farcaster.xyz/dwr.eth/0xd7e9b71b

Depends on the feature. If you have a few ideas, happy to give you reactions on whether a good protocol feature.