FIP: Channels on Snapchain

[topocount]

Abstract

Channels today live entirely inside clients and their backends. They are not part of the protocol. Ownership, configuration, membership, moderator roles, and moderation all sit in one operator's database, so any client, indexer, or app that wants to build on channels has to call that operator's private API instead of reading protocol state everyone can see.

This proposal moves the existing channel feature set onto snapchain, so channels work the way casts, links, and reactions do today: anyone can read and write them without going through a specific operator. It standardizes what channels already do rather than adding new behavior, which also gives the community a base to propose new channel-management models against through the FIP process. It has two halves:

1. Ownership lives onchain in a stock Basenames registry (an ERC-721 name registry with paid registration and expiry). Registering the channel key establishes ownership, renewing extends the expiry, and if it lapses ownership follows the usual ENS path of expiry → grace → release.
2. Everything else is a signed Farcaster message: configuration, members, moderators, followers, pins, and cast-level moderation.

Put together, a channel's full state can be rebuilt from onchain events and signed messages, with no operator in the trusted path. Anchoring ownership in a name registry buys one more thing the current setup lacks: names expire. That is a squatting control (see Motivation), and it touches channel management only. Casting into a channel is never affected by expiry, because casting is not gated by channel state at all (see Rationale).

Motivation

Channels are one of Farcaster's most-used surfaces, but they are not part of the protocol. They live in client and backend databases. Three things motivate moving them:

• You can't build on them. Because channel state is a private database, every client, indexer, or app that uses channels has to integrate against one operator's API and trust it. As standard snapchain state (onchain ownership plus signed messages), channels become something any implementation can read and write, the same as casts, links, and reactions.
• It puts today's functionality on the protocol. This doesn't change how channels behave. It standardizes what they already do (ownership, config, members, mods, followers, pins, moderation) as protocol messages, and moves the current feature set onto a shared substrate without changing how owners manage their channels.
• It gives future models somewhere to start. Once channels are defined at the protocol level, new management models such as different membership schemes, delegation, or richer moderation can go through the FIP process instead of living inside one operator's implementation.

Anchoring ownership in a name registry has a secondary benefit: expiry. Channels already cost $25 to create, but that is a one-time payment with no expiry, so a squatter can hold a name forever. A registry charges for registration and renewal and lets names lapse, so an unused name returns to the pool. That turns the fee people already pay into a squatting control without adding a new fee. (Amount and term are in Open Questions.) Like everything about expiry, this affects management, not casting.

This proposal deliberately does not enforce casting permissions at the protocol level (see Rationale). It standardizes membership and ownership, and leaves posting policy where it is today, in clients and backends.

Specification

1. Onchain channel registry

Channel ownership is recorded by a stock, unmodified Basenames deployment. The spec assumes Base (chain id 8453) as its working default, but the target chain — Ethereum L1 vs Base — is itself an open question (see Open Questions); the Basenames contracts deploy unchanged on either:

• BaseRegistrar — an ERC-721 registrar; each channel is a token. Standard expiry + grace period.
• RegistrarController — paid register / renew priced in ETH via an IPriceOracle.

No contract fork is required. Target chain, registration amount, term, and grace period are deployment parameters (to be finalized, see Open Questions).

Channel key ↔ name. The existing channel key format ^[0-9a-z][0-9a-z-]{0,15}$ maps directly onto a registrar label. The registrar events carry the plaintext name, so no reverse resolution is needed.

Channel onchain identity. A channel is addressable as chain://eip155:<chainId>/erc721:<registrar>/<tokenId> (working default chainId = 8453, pending the chain decision), tying channel identity to its ownership source.

Relevant stock events observed by nodes:

NameRegistered(string name, bytes32 indexed label, address indexed owner, uint256 expires)
NameRenewed(string name, bytes32 indexed label, uint256 expires)
Transfer(address indexed from, address indexed to, uint256 indexed tokenId)   // ERC-721

where label = keccak256(name) and tokenId = uint256(label).

2. Registration ingestion as an onchain event

Nodes ingest channel registration exactly as they ingest tier purchases today (TierPurchase is the precedent: a paid, time-bounded event on Base). A new onchain event type is added:

enum OnChainEventType {
  // ... existing ...
  EVENT_TYPE_CHANNEL_REGISTER = 6;
}

enum ChannelRegisterEventType {
  CHANNEL_REGISTER_EVENT_TYPE_NONE = 0;
  CHANNEL_REGISTER_EVENT_TYPE_REGISTER = 1;
  CHANNEL_REGISTER_EVENT_TYPE_RENEW = 2;
  CHANNEL_REGISTER_EVENT_TYPE_TRANSFER = 3;
}

message ChannelRegisterEventBody {
  string channel_key = 1;                   // plaintext name; set on REGISTER/RENEW, empty on TRANSFER
  uint64 expiry = 2;                         // absolute seconds since epoch; set on REGISTER/RENEW
  bytes  owner_address = 3;                  // 20-byte address; REGISTER owner / TRANSFER `to`
  ChannelRegisterEventType event_type = 4;   // discriminates REGISTER / RENEW / TRANSFER
  bytes  label = 5;                          // keccak256(name) == tokenId == channel_id; join key, set on ALL
}

message OnChainEvent {
  // ... existing ...
  oneof body {
    // ... existing ...
    ChannelRegisterEventBody channel_register_event_body = 16;
  }
}

The body mirrors IdRegisterEventBody (a stable-identifier + event_type discriminator union): a raw ERC-721 Transfer carries only tokenId, so label (= keccak256(name) = tokenId = channel_id) is the one key present on every event kind and is what joins a transfer or renewal back to its channel. Field numbers are frozen once shipped.

Owner address → fid resolution. The registrar events carry an address, not an fid, so ownership is resolved to an fid at read time: a channel-owner read joins the stored owner_address against verification state to find the fid that currently controls the address. Resolution follows last-write-wins — the most recent VerificationAdd for the address wins, and if that verification is removed, ownership falls back to the next-best verifier or to unresolved. Resolution is deliberately not done at ingest: verifications live on their author's shard and never reach shard 0 (where the register event lands), so a merging node can't see enough to attribute an fid deterministically. The event therefore stores the address with no fid (fid = 0), and attribution is computed fresh on each read. Until some fid has verified the owner address the channel resolves to no owner and channel administration isn't possible; it becomes administrable the moment a verification links the address to an fid.

Ownership-change events. Because attribution is read-time, an ownership flip has no merge of its own to hang an event on. So that consumers don't have to join the verification and channel streams themselves, nodes emit a HubEvent whenever a channel's resolved owner changes — whether from a VerificationAdd/VerificationRemove that moves the binding, or an onchain Transfer. Shuttle- and indexer-type consumers can then track ownership on a single stream.

Transfer. An ERC-721 Transfer arrives as a CHANNEL_REGISTER event with event_type = TRANSFER, carrying the new owner_address and the label (it has no name); it updates the stored owner address, the owner fid re-resolves at read time, and an ownership-change HubEvent is emitted.

Expiry / renewal. A RENEW event (event_type = RENEW, from NameRenewed) extends the stored expiry. Nodes follow ENS semantics: active → grace → released. Once a channel is past expiry (in grace), permissioned management writes freeze (§4) until a renewal reactivates it. Casting is not affected. Because casting is never gated by channel state (§3), a lapsed channel keeps taking casts exactly like an active one; only owner and moderator actions freeze.

3. Channel messages

Every message references a channel by a 32-byte identifier:

channel_id = keccak256(name)

Message type	Number	Body (optional/repeated fields elided)	Author
ChannelUpdate	18	{ channel_id, name, description, image_url, header, rules, casting_mode, membership_mode }	owner
ChannelMember	19	{ channel_id, fid, action }	owner / moderator (per action)
ChannelFollow	20	{ channel_id } (+ remove)	self
ChannelPin	21	{ channel_id, cast_hash } (+ unpin)	owner / moderator
ChannelModerate	22	{ channel_id, cast_hash, action: HIDE|UNHIDE }	owner / moderator

ChannelUpdate carries two mode axes:

• casting_mode ∈ {EVERYONE, MEMBERS_ONLY, RECOMMENDED} is advisory metadata, not enforced by the protocol. The protocol accepts casts into a channel whatever the mode says; clients and backends honor it, as they do today. RECOMMENDED tells clients to apply their own discretion and moderation tooling (labels, user scores) when deciding what to surface.
• membership_mode ∈ {OPEN, APPROVAL} is protocol-relevant. It decides whether a self-authored join (ChannelMember{ADD_MEMBER, fid=self}) is valid: allowed on OPEN, rejected on APPROVAL.

ChannelMember action enum: {ADD_MEMBER, REMOVE_MEMBER, ADD_MODERATOR, REMOVE_MODERATOR, BAN, UNBAN}.

4. CRDT semantics and authority

• ChannelUpdate: last-write-wins by Farcaster timestamp (tie broken by lower message hash). Owner-only.
• ChannelMember: add-wins for membership, and a ban beats a membership add. Materializes to ChannelMemberState { fid, is_member, is_moderator, is_banned, member_since, moderator_since, banned_at }.
• ChannelFollow/Unfollow: add/remove-set CRDT identical to LinkAdd/LinkRemove.
• ChannelPin: single pin per channel; a new pin replaces the previous.
• ChannelModerate: cast-level HIDE/UNHIDE; advisory to clients.

Authority matrix (enforced when validating owner/moderator messages, on the read path):

Action	Authorized author
ADD_MEMBER / REMOVE_MEMBER, BAN / UNBAN	owner or moderator
ADD_MODERATOR / REMOVE_MODERATOR	owner only (max 10 moderators; owner cannot be banned)
self ADD_MEMBER on an OPEN channel	the joining fid itself
ChannelUpdate, ChannelPin, ChannelModerate	owner (pin/moderate also moderator)

Owner-dependent authority relies on owner attribution, which is resolved at read time (§2), so these checks run on the validation/read path rather than at merge. The materialized member/moderator set in shard 0 supplies the moderator side of each check. While a channel's registration is expired (in grace), the permissioned writes above are frozen. Self-directed follows still work, and so does casting (posting is never gated by channel state, so expiry can't stop casts).

5. Storage placement (sharding)

Channel state lives only in shard 0, and is not replayed:

• ChannelUpdate, ChannelMember (including self-join), ChannelPin, and ChannelModerate route to shard 0, next to the ownership event (§2) and the materialized owner/moderator set. Co-locating them puts the channel config, the register event, and the owner/moderator set the authority checks read in one place; owner attribution itself is resolved at read time (§2), and the shard-0 state supplies the config and moderator set those checks consult.
• Channel state is not copied onto fid shards. It is keyed by channel, not by user, and since casting_mode is advisory (§3), nothing on a fid shard needs it at cast-merge time. "Channels by fid" reads come from a by-fid index kept within shard 0.
• ChannelFollow and Unfollow are self-authored and need no channel config to validate, so they stay on the author's own shard and reuse the existing Link CRDT machinery.

ChannelMember (including self-join) is routed to shard 0 rather than the author's shard because validating a self-join against membership_mode requires the channel configuration, which lives only in shard 0.

6. Backfill / migration

Existing channels are seeded at migration:

• Ownership: the registrar contracts are seeded with existing (active) channels and their owners, so ownership arrives as ordinary onchain CHANNEL_REGISTER events through the normal ingestion path — no special route.
• Members, followers, moderator roles, and pins: these are signed-message state, so the contracts can't produce them. A dedicated one-time admin message route imports the legacy records (node-operator-attested; bypasses per-user signatures, acceptable for a migration) and is disabled once migration completes.

Rationale

Why a name registry for ownership (and the expiry it brings)? Ownership has to be anchored somewhere the protocol can read. An ERC-721 name registry fits: a channel key is a name, and it matches the way Farcaster already establishes ownership onchain. The expiry that comes with it closes a real gap. Channels already cost $25, but a one-time fee does nothing to stop squatting, since a squatter is happy to pay once and hold a key forever. Charge that same fee on a renewal cycle and an unused name eventually lapses back into the pool. Basenames gives us all of this (priced registration, renewal, expiry, grace) in audited contracts, which is why we use it unmodified instead of building our own. Again, this is a side benefit, not the point of the proposal.

Why keep create/transfer onchain? An ERC-721 name registry is a good ownership primitive: it matches the pattern Farcaster already uses to establish ownership onchain, and its built-in expiry adds squatting enforcement, all from audited stock contracts.

Why not enforce casting permission on-protocol? To enforce MEMBERS_ONLY at cast-merge, every fid shard that processes a cast would have to consult channel membership, which is channel-keyed state on shard 0. That means either cross-shard reads or replicating membership onto every shard, on the hot cast path. The payoff is low: casting policy is a client and backend concern today, and it works. Making casting_mode advisory removes the only thing on a fid shard that would ever need channel state, which is what makes the no-replay, shard-0-only design work.

Why shard 0 with no replay, rather than mirror-to-all-shards? Channel management state is low-volume and keyed by channel. Co-locating it in shard 0 puts the config and owner/moderator set in one place for the authority checks, which run on the read/validation path (owner attribution is resolved at read time). Replaying to fid shards would only pay off if something there consumed it, i.e. if casting were enforced on-protocol, and it isn't. Full mirroring would multiply writes by the shard count with no reader to justify the cost.

Why read-time address→fid resolution? The owner address isn't guaranteed to be linked to an fid at registration, and verifications don't live on the shard where the register event lands, so a node can't attribute an fid at ingest. Resolving at read time — last-write-wins over the address's verifications — keeps attribution correct as verifications change, and lets a channel registered before its owner is verified attribute automatically once the link appears.

Backwards Compatibility

• New message and event types only. No existing message type, CRDT, or onchain event changes shape; nodes that do not understand the new types ignore them, as with any additive message type.
• Payment is not new. Channels already cost $25 to create. What changes is the structure: instead of an EOA transfer, a channel's registration that has to be renewed. Existing channels are grandfathered in via backfill (§6) rather than made to re-register, but they join the same renewal cycle once their grandfathered term ends, so expiry eventually covers the existing namespace and not just new channels.
• Enum extensibility. casting_mode is defined with room to add tiers (e.g. RECOMMENDED) without a breaking change; message-type numbers are allocated from the next free protocol values.
• User preferences (subscribed, favoritePosition) and display/ranking fields remain client/backend concerns and are explicitly out of scope for the channel record.

Security Considerations

• Authority enforcement reads shard-0 state. The register event and materialized owner/moderator set live in shard 0, so the authority checks have a single place to read; owner attribution is resolved at read time (§2), so owner-dependent checks run on the validation/read path. Routing correctness (permissioned messages must reach shard 0) remains security-relevant.
• Expiry freeze. Permissioned writes freeze during grace to prevent a lapsed owner (or a party mid-transfer) from mutating a channel they no longer clearly control.
• Backfill trust. Ownership is seeded through the registrar contracts, so it arrives as ordinary onchain events with no signature bypass. Only the admin message route that imports members, followers, roles, and pins bypasses per-user signatures; it is a node-operator-attested, one-time migration path and should be disabled after migration.
• Address→fid binding. Ownership binds to the current best verifier of the owner address under last-write-wins (§2): a later verifier takes over, and removal falls back to the next-best verifier or to unresolved. Because a verification is itself proof of control of the address, this can only ever follow real control; implementers must still ensure a binding cannot be claimed by an address the registrant does not control.

Open Questions

• Chain: Ethereum L1 or Base. The spec assumes Base (eip155:8453) as its working default. Base aligns with the TierPurchase precedent — paid, time-bounded events are already ingested from Base — and keeps registration/renewal gas cheap, which matters because gas price is much lower. Ethereum L1 is the alternative: more credibly neutral for a naming namespace. The Basenames contracts deploy on either chain unchanged; on Base they are native, on L1 they sit under an ENS name. snapchain already watches L1, OP, and Base, so ingestion is not the deciding factor — the trade is Base's precedent plus low gas cost against L1's neutrality. The choice fixes the chain://eip155:<id> identity and the fee currency.
• Price (registration amount + renewal term). Pricing is USD-pegged — the amount is denominated in dollars and converted to ETH at registration time via a Chainlink ETH/USD feed, so the cost stays stable as ETH moves. That mechanism is settled; what's open is the dollar figure and the term over which it recurs. The existing $25 fee is the reference point, and was intended to be annually recurring. This is the protocol fee only; gas is separate.
• Grace period. Flagging the post-expiry grace window for awareness. When a registration lapses, ENS/Basenames semantics give a window in which the owner can still renew and the name is not yet released, before it returns to the pool. Basenames' stock GRACE_PERIOD is 90 days, and we plan to keep it. During grace, permissioned management is frozen (§4) while casting continues (§3); calling it out here so the timescale for a lapsed channel to free back up is explicit for reviewers.

[jdlewin]

first

[jdlewin]

lol

[jdlewin]

this is great work and we're excited to see it through. we've got many more questions but the first two things that jump out:

Chain: Ethereum L1 or Base

put another way this is a question about whether to bet the protocol on coinbase or on the evm, no?

Price (registration amount + renewal term)

is it worth considering a sliding scale based on name length, similar to ens?

[topocount]

put another way this is a question about whether to bet the protocol on coinbase or on the evm, no?

technically a coinbase-owned evm vs a credibly neutral evm, but the thrust of your clarifying question is definitely understood!

is it worth considering a sliding scale based on name length, similar to ens?

I considered this but don't think short names for communities are very valuable for the purposes of vanity. We have seen a lot of the valuable names get claimed already fwiw

[i001962]

Pins? On protocol with this FIP

[jdlewin]

say what now

[99darwin]

Chain: Ethereum L1 or Base.

I'd lean L1 for neutrality and durability. Not that Base is likely to disappear tomorrow, but Ethereum is more likely to remain for the long term. Base could change protocols (as has already been demonstrated), among other things.

Price (registration amount + renewal term)

$25 seems wildly high to register a namespace but I think it's worth looking at how other registrars apply their pricing methodology. Look at ENS, which is ~$5 by default but for more desirable names, the price increases. Taking over an ENS domain also works in a dutch auction style. Some similar methodology would likely work here. Default to low-cost, increase for high-value names, penalize for takeover with degrading cost basis. Or, if we want to look at web2, where a domain can be acquired for as little as $0.99 but, again, where a high-value namespace is priced accordingly. I don't think $25 as the default makes sense and acts more like a deterrent. Dynamic pricing should be considered.

Grace period

See above. Following ENS methodology here would make the most sense.

--
On ChannelUpdate:
I'm curious if it's worth addressing the bygone 'narrowcasting' capability as a protocol-enforceable primitive. Alongside the casting_mode convention, there could also be a cast_target that purely publishes the cast as a child hash to the channel rather than as a message to the entire network.

Disclaimer: apologies for any mistaken nomenclature. Doing my best to use the internal Farcaster vernacular.

[rubinovitz]

+1 eth mainnet if we can keep the price low eg $25

[atenger]

+1 on dynamic pricing

I also like narrow casting indicator too - advise clients that casts to the channel should never be shown on main feed, and only under the context of the channel (advisory only, up to clients to enforce)

[topocount]

I'm not opposed to narrowcasting narrowcasting making a comeback!

[topocount]

$25 is the current price, even if renewal isn't enforced. I doubt we will roll out with it that high.

[spengrah]

Everything else is a signed Farcaster message: configuration, members, moderators, followers, pins, and cast-level moderation.

This is great as long as there is first-class support for smart contract signatures. Enabling builder/experimentation flexibility is a big part of the value here, so it's important that arbitrary smart contracts be able to own and operate channels.

[jdlewin]

This is great as long as there is first-class support for smart contract signatures

say more sailor. explain this one like we're twelve

[shazow]

+1 to building around isValidSignature, I sketched a rough fantasy model for this here: https://farcaster.xyz/shazow.eth/0x1d3eaa58

[topocount]

smart contract signature validation exists in snapchain already!

[chejazi]

Ownership lives onchain in a stock Basenames registry (an ERC-721 name registry with paid registration and expiry). Registering the channel key establishes ownership, renewing extends the expiry, and if it lapses ownership follows the usual ENS path of expiry → grace → release.

Stock registry here is a redeployed registry, right?

I think it would be cool if channels lived in a subdomain of either chains most canonical name system, e.g. .farcaster.eth or .farcaster.base.eth

I could see communities more easily building treasuries this way, "our community accepts donations at football.farcaster.eth" and having day-1 interop w/ the rest of the ENS ecosystem. There's already example implementations of a subdomain registrar we could piggy-back off of: https://github.com/ensdomains/ens-contracts/tree/feature/subdomain-registrar/contracts/subdomainregistrar

[99darwin]

i like this. definitely not .base.eth though.

[jdlewin]

I think it would be cool if channels lived in a subdomain of either chains most canonical name system, e.g. .farcaster.eth or .farcaster.base.eth

I could see communities more easily building treasuries this way, "our community accepts donations at football.farcaster.eth" and having day-1 interop w/ the rest of the ENS ecosystem. There's already example implementations of a subdomain registrar we could piggy-back off of: https://github.com/ensdomains/ens-contracts/tree/feature/subdomain-registrar/contracts/subdomainregistrar

there's something to investigate in tightly coupling domain names and channel names. feels like there could be greater friction down the road

[CassOnMars]

IMO, hitching wagons to base like this is a bad move – it adds even more chain indexing requirements, bloats shard 0 (which ideally should be light as it needs to be present for the other shards when validating messages), doesn't solve squatting (it just moves the responsibility to fighting it out over basenames). Not to mention, base's contribution to farcaster was onboarding a million $BASE airdrop farmers then abandoning farcaster entirely.

If we're going to accept the cost of expanding shard 0 anyway, we should natively add channels to the protocol as a first class object. Channels should have unique identifiers by hash, but display names should be non-unique, which removes the name squatting issue entirely.

[rubinovitz]

This is my favorite proposal but I'm not well versed enough to know the trade offs of this vs the parent proposal.

It's unclear why channels aren't being added to the protocol itself like Cassie mentions.

[jdlewin]

Channels should have unique identifiers by hash, but display names should be non-unique, which removes the name squatting issue entirely.

how does a user reference a channel in a cast with this architecture?

[EoghanH]

Not to mention, base's contribution to farcaster was onboarding a million $BASE airdrop farmers then abandoning farcaster entirely.

Cassie gets it

Base were gifted a platform that somehow was literally full of builders and shockingly low on the crypto grifter ratio, yet still decided the best thing to do would be to sling shitcoin factorios at them and offer $5 weekly llm spam bonuses

So ye, proposal looking great but let's maybe start seeking out more neutral venues for new infra where we can

..wen 10k tps EVM compatibility on snapchain? 💀

[i001962]

Does renaming mean changing identity?

[jdlewin]

wdym

[daferna]

I agree with the idea that channels should be identified by a smart contract address, not by display name, something like an ERC-725 smart contract account would be a good example. One of the problems of the original channels experiment was people getting very high-value names and churning where the namespace becomes useless for everyone. For example, there can be multiple competing communities for /sf and the one with the highest Neynar score (by sum over members) should get top rank in the search results, or get to own the URL redirect on the primary client. It's also worth pointing out Bluesky is developing communities, so they will likely do a similar architecture where communities will be identified via a DID.

[jdlewin]

there can be multiple competing communities for /sf and the one with the highest Neynar score (by sum over members) should get top rank in the search results

there's an interesting idea here

[shazow]

keccak256(name) == tokenId == channel_id

There's a few issues with binding all actions to the channel_id which is derived from name:

1. If someone is squatting my name foo, can I register a foo2 and then someday rename to foo when it becomes available? No.
2. What happens when a name expires and someone else buys it? They take over the channel and all of its contents, this is bad.
3. What happens to my community when the channel name expires? In Ethereum-land, if I lose my ENS, I don't lose the wallet address it was pointing to. I should be able to continue the community with or without a name.
4. Can I have multiple names pointing to the same community? No.

Also it's not clear to me what the $25 registration is accomplishing. What is the goal? If the goal is to setup channels for success, why is $25 the best way to do this?

If names are purely cosmetic (IMO that's how it should be) then the $25 is less important -- I can start a community, and if it grows big enough to justify buying an ENS for it, then great.

Also, if the name is cosmetic, why not just use ENS (or even wei/gwei)? Is it important for this to be Farcaster's core competency?

[shazow]

you seem to be arguing for tightly coupling to ENS. are we reading that correctly? is there a particular reason in your view? how does the user experience benefit?

1. I am mainly arguing against farcaster tightly coupling to its own shittier version of ENS.
2. Farcaster already has coupling with ENS, my handle on Farcaster is shazow.eth after all. Why shouldn't channels work the same way? (Then I could have a musings.shazow.eth channel for my musings or whatever, like many people do.)

Generally I am tired of Farcaster The Protocol being more complicated than it needs to be. I've argued elsewhere that Snapchain was an unnecessary overcomplication just to achieve an ordering overlay which could have been merkle commitments on an existing chain. Why create this big distraction and compete poorly when you can leverage it? A lot of the drama around the credible neutrality of the protocol is downstream from these decisions, too.

There's already huge amounts of infrastructure around ENS (and even offshoots like wei and gwei), why compete with it when you can leverage it? Don't forget, this is the whole point of money-legos! Farcaster should leverage existing lego pieces to build something that other people would rather leverage than compete with.

(Maybe if Farcaster was going to pivot to being ENS competitor first and onchain social second, that's a different story.)

If I were building Farcaster, I'd try to be as surgical as possible about what I'm going to NIH/compete on vs what I'm going to leverage.

There is no successful collectively owned onchain community social infrastructure, this is a great thing to focus on and a great space to compete in (assuming we can find a version with PMF eventually). For everything else, the default should be to use something off the shelf until there's a very strong reason not to.

[EoghanH]

1&4: I don't think you should ever be able to re-name channels tbh; or have any sort of many-to-one relationship where foo2 can hit foo.

Channels should ideally always maintain their own distinct history, allowing for foo2 becoming foo would mean foo would suddenly be sending back foo2's history despite sending back foo's history for the past year. Along with the general human-centric "where tf my posts go" issues this would cause, it'd also be a mess for any automated systems

Lesser point then on the many-to-one relationship is you don't want people registering slur and pointing it at your channel.

2 is an excellent point, noted on it myself - could be an avenue for a malicious actor to "take over" a popular community, lock it up and fill it with spam or other unwanted content.

So yeah, I think the most realistic avenue here is to allow for channel creation which just assigns a hash to a community, and only allow the channel creator (or moderator?) to point an ENS-style channel name to that hash; this way, history is preserved at a minimum.

Adding mods to allowable grace list registration pool for expired names would also help prevent any sniping, but that's not without issues too; hard to say how this can be fully secured from bad actors without a centralised component. I guess it COULD be put back on the clients to allow for manual overrides to channel endpoints? Messy, tho

[shazow]

I don't think you should ever be able to re-name channels tbh

Why not?

Keep in mind, the cosmetic name of a channel does not need to be related to the actual channel id.

You can have internal consistency of what a channel is and all of its history, despite having multiple ENS-style names pointing to it.

Do you think Farcaster names should ever be renamed? Twitter names? Why is that different?

Lesser point then on the many-to-one relationship is you don't want people registering slur and pointing it at your channel.

I don't understand why that's a big deal? I can make a website on slur.com that redirects to your channel, so what? There's no obligation for Farcaster clients to surface it in discovery, simply let the channel owner choose the authoritative name which will get surfaced.

[topocount]

someone else being able to claim ownership of a channel after the prior community has stopped using it is the intention of this design. There are many dead channels on fc now and those names should be able to be re-used at some point. At the same time, naming mutability and collisions would be confusing for users.

If someone is squatting my name foo, can I register a foo2 and then someday rename to foo when it becomes available? No.

This is okay! It happens all the time on reddit, but often takes inordinately long and involves admins getting involved. This design aims to resolve this lifecycle more organically.

[shazow]

someone else being able to claim ownership of a channel after the prior community has stopped using it is the intention of this design. There are many dead channels on fc now and those names should be able to be re-used at some point.

This is okay! Let's design for that. What if you have a default setting where the channel name goes up for auction when it becomes inactive, alternatively the owner can pay more to retain the name past inactivity?

Or if we're just using ENS, this isn't really a problem, it can become normal to have subdomains as names (e.g. politics.shazow.eth) until it becomes huge then it can get a standalone primary domain.

Or you could do both, have some fancy auto-auction functionality for *.farcaster-channels.eth which get special treatment under the app (.farcaster-channels.eth suffix is hidden), but then normal ENS domains behave normally. This is something you can always add later, just by virtue of using ENS today.

At the same time, naming mutability and collisions would be confusing for users.

dwr changed his name to dwr.eth, then later changed his back to dwr. This broke farcaster search (surely we can figure out how to fix this?). Should this be allowed? Naming mutability is confusing for users.

This is not a real constraint, it's a UX decision that you can address however you want.

If someone is squatting my name foo, can I register a foo2 and then someday rename to foo when it becomes available? No.

This is okay! It happens all the time on reddit, but often takes inordinately long and involves admins getting involved. This design aims to resolve this lifecycle more organically.

Sounds like this is not okay? Sounds like you want to resolve this.

Personally I don't think reddit's subreddit takeover mechanic is okay, there's tons of contentious history of subreddits getting taken over by non-neutral parties, either sanctioned by reddit admins or not.

[EoghanH]

gm

eggman here, excuse the blank profile (I moved to gitlab like a hipster)

Firstly, extremely happy to see channels come back!

General thoughts:

1. v much like that we're sticking with signed snapchain messages for the basics like following a channel etc, got a bit of a fright when reading too fast and thought it was meant to be an on-chain tx. Leading me neatly into point 2..

2. I would strongly advocate for Ethereum over base. Base has been a bit of a shitshow the past while, left me with an impression that Jesse and co were farming fc to get Zora shitcoiners and then abruptly fucked off when they realised we weren't having it. Has made me want to see fc become a much more neutral ground in general, rather than being as closely tied to Base as it currently is.

3. Going a bit against the grain but I think $25 is a decent entry point to discourage mass squatting. Just don't want a repeat of the fiasco we saw with basenames.

4. I do think some channels should be fc-owned/run, or overseen to some extent to start. What would likely be important hubs like the crypto channel, dev/snaps/apps channels, probably the main news/politics channels etc. I know there's pre-seeding noted in here, but I'm unsure on if the owners of some likely popular channels are even still active on fc.

5. Channel renewals do leave a potential exploit gap open - if a channel owner left fc/decided not to renew a popular channel, it just gets landed back into the registration pool. This could allow bad actors to snipe a potentially popular channel and pack it with malicious content or otherwise. I'm not sure how to best resolve this without again having some "protected" status similar to the above "fc-owned/run" channels which itself would be quite centralised in nature. Maybe allowing first-dibs to moderators of the channel might mitigate this a bit?

Last tidbit, I'd be against any many-to-one relationship on names pointing at channels which has been mentioned as a detractor for the hash(channel) type storage. For all the good parts like having crypto and cryptocurrency just pointing to one channel, there'll also be people who just register slur and point it at your community.

A couple of difficult issues to tackle while wanting to avoid centralised components.

[topocount]

Really appreciate this thoughtful feedback eggman. We're working to find a good process wrt 4 but want to avoid injecting FC into any active channels where it isn't already

[topocount]

you raise a good concern on point 5. We do need something here before registrations expire at the very latest

[atenger]

Regarding Owner address → fid resolution, what is the user experience for someone who has verified an eth address to multiple FIDs, and they want the ownership to show as a different FID then the default of last verified?

is it this:

• log in to farcaster as FID you want to show as having ownership of channel
• in settings, remove address and then re-verify address

[topocount]

We're actually working to allow multiple FIDs to have the same address verified. shared ownership of a channel is worth supporting natively.