fc.proto

Broad vs Narrow data types (for example, cast location vs external data FIPs)

I'm in favor of broad types. I like how RSS enclosures allowed podcasting to emerge (and practically this is the only broadly used RSS application today). Broad types allow clients to implement new features without protocol updates -more permissionless from a dev pov.

On the other hand, narrow types create a well-defined, well-scoped environment, easier to navigate for devs who want to implement a standard feature set.

What's your take?

Ethereum builder & people connector. Juicebox, Revnet, Defifa & Footy App. My Innie writes stuff on kmacb.eth.sucks

Footy App (v5)

KMac woke up today and chose war. 🤣 

Each approach has its pros and cons. It's good to collect them and share them with each other. 

@dwr said the he has changed his mind about (the near term feasibility of) alternative clients. Downstream from this, maybe other decisions/mental models should be reevaluated too. If you expect to have 10 competing twitter clients, narrow types give a clear path to feature parity. If you hope to get a twitter-like client, a social p2p media sharing app, a social event scheduler and a small businesses directory, event parity is irrelevant but freedom to experiment is required.

Dad, geek, conversation liquidity provider. @l--o--l | @wdimapp

lemon3

I'm in line with your pov.

There is something I'll call "dev intimidation". Experimenting with something that looks ugly/spammy on Warpcast is intimidating. From my pov, devs don't want their experiment to look ugly to thousands of users, so they stop. Just like in everything else, if you're driven enough nothing stops you, but don't we want the rest of the cases? Or even better, don't we want these experiments on display?

I can use embed_url to link to an IPFS CID holding an mp3 playlist today. It will look like an ugly bug, or a broken link. A broad type that lets clients like WC and Supercast be agnostic, but show this with an icon and a description  my "type" provides would be 10x better and encouraging.

Side note: Some of us are working on using the profile URL, which is not used by WC for a similar experiment.

1. A venture-backed Warpcast alt client is likely not a good bet right now since time pressure / opportunity cost with venture financing is high

2. I've said multiple times that indie / open source clients make more sense

3. People spend a lot of time worrying about the formal protocol and less time experimenting, especially with embeds, e.g. people could have put location into embeds without permission before a formal FIP.

4. The two limiting factors for Farcaster:

a. Retained user growth (makes more business models viable)

b. Builders hacking on the same project over a long period of time (there are a handful, but most people lose interest, which is fine, but duration / persistence is necessary to create something great in consumer)