Looking for input

Assume we want to simplify channels to make them:

1. Fully decentralized, zero Farcaster app dependencies
2. Allow other clients to extend them
3. No cost to create them

Which option is most appealing?

A) Hashtag approach — channels are open to everyone, channel pages look less like profiles and instead are a simple feed of casts. There’s no moderation — the feed is unique to each viewer based on their own social graph and maybe a user-controlled setting around filtering. 

B) Niche interest approach — Channels are open to everyone and narrowcast only, ie you get no distribution boost. But allows you to cast in a channel knowing only people interested in that topic will see it.

Assume in both cases membership and moderation in the main Farcaster app would go away. PYou’d be free to use a channel focused client for more community features. 

This is not an imminent change, more gathering input for what matters to people who still use channels.

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?

The challenge with channels is there’s no consensus on what they should be.

1. Distribution vs. niche interest

2. Open but tons of mod work vs. Closed but frustrating for new users

A lot of this is a result of our iteration on the feature and not having anything work. 

A simpler version not dependent on the Farcaster app—but not emphasized by it, would most likely mean other app developers could solve for the various cases. 

And now with mini apps, you could imagine channel-specific clients as mini apps.

The challenge with channels is there’s no consensus on what they should be.

1. Distribution vs. niche interest

2. Open but tons of mod work vs. Closed but frustrating for new users

A lot of this is a result of our iteration on the feature and not having anything work. 

A simpler version not dependent on the Farcaster app—but not emphasized by it, would most likely mean other app developers could solve for the various cases. 

And now with mini apps, you could imagine channel-specific clients as mini apps.

https://farcaster.xyz/dwr.eth/0x19ce197c
https://farcaster.xyz/dwr.eth/0xd7e9b71b

I've shared so many (failed/bad) ideas on this with you, that I'm hesitant to do it one more time... but...

- Assuming that by "channels" we mean a programmable, alternative view of casts. A custom "select".
- Considering that there are enough devs, and we have some pretty good tools that we did not have 6 months ago.

My proposal: Define as channel(fid) the result of "select casts where cast liked by <fid>"

So, now, a channel is defined by an fid and a fname, for example: @mycoolchannel. If someone wants to cast to my channel, they have to mention @mycoolchannel. Then my bot will decide (custom rules) is the cast should be added to the channel, and if so, add a like using @mycoolchannel's appkey.

FIDs that are used as channels are normal FIDs. But they could have a special user_data_type to indicate to clients that they should be rendered as channels (for example, show the reactions view as the default view).

Dad, geek, conversation liquidity provider. vrypan.net (home), @l--o--l (fun). devcoin:$lemon3

This is very close to your FIP-2-based suggestion, but the advantage of using an FID-based solution is the FID has control on what is added to the channel and what not. You can't do this with FIP-2 easily, and this is why previous iterations depended on Warpcast implementing some logic.

So I like this as a technical solution (also had considered way back). But it doesn’t solve the feeling of communities. 

Basically we don’t want to have the surface area in the Farcaster app since it is massive and people will be unhappy with a subpar version.

Extending FIDs beyond just “users” is super powerful!

We should treat FIDs as universal primitives and rename UserAddBody to ArtifactAddBody, a more generalizable entity type.

Users and channels already share common metadata (PFP, bio, URL, handle/channel ID)

Every Artifact could:
- Have its own authored cast feed.
- Aggregate a second feed from casts that reference its FID (as in FIP-2).

This effectively creates a Farcaster Wall, like Facebook’s timeline, where anyone can cast to an Artifact by including its FID in parent_url.

Benefits:
Unified metadata, Native support for ownership of channels, no link spec changes.
Verifications could also extend beyond individuals (e.g., mod assignments)

Maybe we might want to add a definition type in ArtifactAddBody that dictates where its user, channel, etc, so clients know how to render it.

You also solve for announcement in this case, Anything casted by the Artifact is an announcement

CC: @sahil @moe