@dwr on Farcaster: "Looking for input Assume we w..."

7mo

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.

11Kviews

Lean towards B. I like hashtags as an idea, but they feel like a skeuomorphic tech from before we had machine learning.

2

6

68

Worth clarifying: there would be no hashtag in the cast.

1

8

My point still remains. I thing AI can do a better job classifying than humans. Human generated tags will always be a subset of content and have the extra problem of incorrect labeling (check out /zora for egregious examples of off-topic content)

2

5

/zora and any financially incentivized channel (/base, /ethereum, /rainbow, etc) will always be noisy due to farmers, and the only viable solution is the platform nerfing them as spam. While AI can do a better job at categorization, it would be hard pressed to label something in a humorous or even human way. It's too literal. /bad-takes and /someone-build are examples of great channels because you can place new and existing casts in there and give them a larger meaning.

2

1

6

Yep

1

Without membership, moderation, and ownership at the protocol level, they are essentially just hashtags, regardless of how the narrative is framed, and they will inevitably be flooded with spam. Infrastructure providers like Neynar have built around the current structure, so if memberships were removed, a channel-based client like Tunecaster would quickly be overwhelmed by spam. I strongly suggest making channels a core priority and introducing a channel-based onboarding flow. This could be the growth engine you've been searching for.

1

8

Channels as a core priority isn’t an option. So looking for the next best alternative.

1

1

I suppose this is another opportunity to learn who truly controls the direction of this supposedly decentralized protocol. Thanks for the clarity

1

4

Blows my mind how they fumbled the channels thing.

1

3

farcasteradmin.eth

i don't like hashtags, people start optimizing them (e.g. see instagram) by spamming hashtags (as many as they can fit)

2

7

Yeah assume you can only pick one per cast and default spam filtering is aggressive.

1

2

Only having one just makes it worse in my opinion. The number isn’t the issue, it’s how they’re used. Axing the ability to tag multiple subjects is restrictive and will create friction, so I’d lean towards B too.

1

A could be nice if they don't end up being such a huge toxic wasteland like they are right now

1

5

The reason they don’t work on Twitter: 1. Cringe to have in the body of the tweet 2. They aren’t aggressive enough with spam filtering.

1

2

degenveteran.eth

This is another reason I feel like we're going to have a better experience than Twitter for a while The ability to cut spam during our early growth phases will be beneficial all around

2

eyesobscura.eth

It won't be a clear answer but the channel thing is quite disturbing when casting, each time I ask myself if appropriate to cast a thing in a channel or not and it always end the same way, I always cast in same channels. Furthermore I haven't noticed any difference in distribution so that's a lot of questions for a similar outcome.

2

2

There is no benefit to distribution.

1

1

eyesobscura.eth

Oh sorry I thought there were today. I understand the interest of narrow casting but I think it makes the meta a bit complicated for small accounts and new users.

which of these options would enable this

in

where is channel cross-posting on the roadmap @dwr.eth

1

None. It’s not about distribution.

1

1

say more sailor. surely baking channel functionality into the protocol could allow for this, no

2

1

Channels have never been a strong signal for content to boost.

1

1

if what you mean by boost is as an input to the home algo then we agree. whether a cast appears in a channel doesn't feel like it should be an input into the algo calculus what we're focused on is that alice, as a follower of a given channel, will receive delivery of something bob casts to that same channel. at least in a purely rev-chron view. in the future where channels are a primitive of the protocol, then anything casted to a channel ought to be delivered i.e. channels as rss feeds. let the user manage the noise coming off a given account, be that with no algo in place or an algo they can control

so in both approaches channels would simply be a text tag and not have any additional metadata like image and bio?

1

Not necessarily, but generally want to simplify as much as possible to decentralize them and let other apps extend.

1

1

yup understood. so i’m assuming channels (in both approaches) won’t have any owner and there would be no registry of channels. just permissionless text tags added to casts to simplify as much as possible?

1

I lean towards B that option feels more like subreddits or feeds built around specific topics/communities which feels more orderly and focused relative to the hashtag approach A feels more like you’re solving for topics whereas B feels more like you’re solving for niche communities/groups around a particular topic

2

12

B, it's part of what makes Farcaster special imo A should also happen but implicit (algo) vs. explicit

7

my initial reaction was B but now leaning toward A based on *feed is unique to each user's social graph* that sounds like a novel solution

1

6

I went through the same process.

Why_not_both.gif? - when you select a channel to cast to, your home feed becomes a toggle you can turn on or off. Narrowcasting, if you want it. Others can still just QC you into the algo anyway, but it gives choice (and neither option prevents this anyway). - users can adjust settings on their end for channels they

1

B, sometimes you wanna niche cast

3

B I feel is closer in spirit. Like little subreddits

1

B seems more intuitive - almost like sub reddit feel , closer to how i perceive channels as a niche interest group. Just have a negative psychological bias when it comes to hash tags - too farmed on X + primarily used to simply search

1

YES! option B it gives greater design surface for communities and form factors on the protocol. membership/moderation can easily be handled client side (we're building Cura to solve for this) we're happy to float a proposal and support implementation - we'll make all channel management functionality available on cura from day 1 of transition. - we'll ensure backward compatibility to preserve existing channels - we'll make it easy for channel related read/write happen on farcaster app through mini app rendering.

3

7