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?

Dad, geek, conversation liquidity provider. vrypan.net (home), /weatherxm (work), @l--o--l (fun). Also https://paragraph.xyz/@purplesubmarine

The app driven protocol dev philosophy & practice of Merklem seems to kneecap Broad data types esp if those don’t fit into their word view of a social network that is x like err Reddit like err Patreon like err…

Imagine if smtp only let you send personal emails instead of work related or controlled the available subject lines or dictated what could go in attachments. It may have been a slower adoption & smaller surface area. 

Some storage the community can play with to find what sticks & what grows to be a ‘standard’ vs told this is the standard would be rather empowering for devs.

Ethereum builder & people connector. @juicebox revnet.eth.sucks defifa.net d33m.com

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.eth 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.

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)

Haha not meant to be shots fired & certainly not a new thought being shared.