FIP: Native Channels

[CassOnMars]

FIP: Native Channels — Protocol-Level Channel Primitives

Overview

Introduces channels as a first-class message type in the Farcaster protocol via Hypersnap. Channel creation, membership, moderation, and metadata become protocol-native operations stored in the hyper trie, replacing the current convention of overloading parent_url for cast-to-channel association. This gives channels the same CRDT guarantees, decentralization, and censorship resistance as casts, links, and reactions.

---

1. Motivation

Channels are the primary community organizing structure on Farcaster. Despite their importance, they exist entirely at the application layer with no protocol representation. This creates several problems:

• Centralization: Channel creation, membership, and moderation are controlled by a single backend. A channel owner cannot transfer ownership without that backend's cooperation.
• No interoperability: Third-party clients must reverse-engineer the parent_url convention and call proprietary APIs for channel metadata, membership, and moderation state.
• No censorship resistance: Channel bans, hides, and pins are enforced by a backend with no on-protocol appeal mechanism. A banned user has no protocol-level proof they were banned.
• Fragile association: Casts are linked to channels via a URL string (https://farcaster.xyz/~/channel/{key}). This is a domain-dependent convention — if the domain changes, the association breaks.
• No CRDT semantics: Channel state changes (follow, unfollow, ban, unban) have no conflict resolution. Two backends processing the same events can diverge.

Making channels protocol-native solves all of these issues by giving channel operations the same properties as other Farcaster messages: decentralized, CRDT-mergeable, censorship-resistant, and client-agnostic.

---

2. Channel Identity

Channel ID

Each channel is identified by a unique channel_id — a 16-byte value derived from the channel key at creation time:

channel_id = SHA256("farcaster-channel:" ++ random_nonce ++ key)[0..16]

This is deterministic: given the same nonce and key, any node computes the same channel_id. The 16-byte truncation keeps trie keys compact while providing sufficient collision resistance (~2^128 bits).

Channel Key

The human-readable slug (e.g., "ethereum", "dev"). Constraints:

• Matches ^[0-9a-z][0-9a-z-]{0,15}$ (lowercase alphanumeric + hyphens, 1-16 chars)
• Must start with an alphanumeric character
• Immutable after creation

Reserved Keys

The protocol reserves a set of keys that cannot be registered, to prevent conflict with the existing implementation:

home, trending, following, support, notifications, settings, explore, search, bookmarks

Additional keys may be reserved via governance. Reserved keys are enforced at validation time.

---

3. Message Types

All channel operations are HyperMessage types, processed by the hyper engine and stored in the hyper trie.

3.1 ChannelCreate

Creates a new channel. The creator becomes the owner.

message ChannelCreateBody {
  string key = 1;               // Channel slug (1-16 chars, validated)
  string name = 2;              // Display name (1-32 chars)
  string description = 3;       // Description (0-256 chars)
  string image_url = 4;         // Icon URL (optional)
  CastingMode casting_mode = 5; // Who can post
  bytes nonce = 6;              // 8-byte random nonce
}

enum CastingMode {
  CASTING_MODE_NONE = 0;
  CASTING_MODE_PUBLIC = 1;       // Anyone can post
  CASTING_MODE_MEMBERS_ONLY = 2; // Only members can post
}

Validation rules:

• key must match the key format regex and not be reserved
• key must not already exist (check hyper trie for existing ChannelCreate with same channel_id)
• Creator FID must have a valid ID registration
• nonce must be eight bytes

3.2 ChannelUpdate

Updates channel metadata. Only the owner can submit.

message ChannelUpdateBody {
  bytes channel_id = 1;         // 16-byte channel ID
  optional string name = 2;
  optional string description = 3;
  optional string image_url = 4;
  optional CastingMode casting_mode = 5;
}

CRDT semantics: Last-write-wins by Farcaster timestamp. If two updates have the same timestamp, the one with the lexicographically lower hash wins.

Validation rules:

• channel_id must reference an existing channel
• Signer must be the channel owner's FID

3.3 ChannelTransferOwnership

Transfers channel ownership to another FID. Two-phase: the owner initiates, the recipient accepts.

message ChannelTransferBody {
  bytes channel_id = 1;
  uint64 to_fid = 2;           // Recipient FID
}

message ChannelTransferAcceptBody {
  bytes channel_id = 1;
}

Flow:

1. Current owner submits ChannelTransferOwnership specifying to_fid
2. to_fid submits ChannelTransferAccept referencing the same channel_id
3. Ownership transfers atomically when the accept is processed

Validation rules:

• Transfer: signer must be current owner
• Accept: signer must be the to_fid specified in the pending transfer
• Only one pending transfer per channel at a time (new transfer cancels previous)
• Recipient FID must have a valid ID registration

3.4 ChannelMember

A CRDT set for channel membership and role assignments.

message ChannelMemberBody {
  bytes channel_id = 1;
  uint64 fid = 2;               // The user being acted on
  ChannelMemberAction action = 3;
}

enum ChannelMemberAction {
  CHANNEL_MEMBER_ACTION_NONE = 0;
  CHANNEL_MEMBER_ACTION_ADD_MEMBER = 1;
  CHANNEL_MEMBER_ACTION_REMOVE_MEMBER = 2;
  CHANNEL_MEMBER_ACTION_ADD_MODERATOR = 3;
  CHANNEL_MEMBER_ACTION_REMOVE_MODERATOR = 4;
  CHANNEL_MEMBER_ACTION_BAN = 5;
  CHANNEL_MEMBER_ACTION_UNBAN = 6;
}

Authorization matrix:

Action	Who can perform
ADD_MEMBER	Owner, Moderator
REMOVE_MEMBER	Owner, Moderator (not self-remove from mod)
ADD_MODERATOR	Owner only
REMOVE_MODERATOR	Owner only
BAN	Owner, Moderator
UNBAN	Owner, Moderator

CRDT semantics: Add-wins for membership conflicts. If an ADD_MEMBER and REMOVE_MEMBER arrive with the same timestamp, the add wins. Bans take precedence over membership — a banned user is effectively not a member regardless of membership state.

Validation rules:

• channel_id must reference an existing channel
• Signer must have appropriate authorization per the matrix above
• Cannot ban the owner
• Cannot add more than 10 moderators (excluding owner)
• Target FID must have a valid ID registration

3.5 ChannelFollow

Users follow/unfollow channels. This is a self-directed action (no authorization check beyond FID validity).

message ChannelFollowBody {
  bytes channel_id = 1;
}

Follows use add/remove set CRDT semantics identical to LinkAdd/LinkRemove:

enum HyperMessageType {
  // ...
  HYPER_MESSAGE_TYPE_CHANNEL_FOLLOW = 110;
  HYPER_MESSAGE_TYPE_CHANNEL_UNFOLLOW = 111;
}

Validation rules:

• channel_id must reference an existing channel
• Signer FID must have a valid ID registration

3.6 ChannelPin

Owner or moderator pins/unpins a cast in the channel.

message ChannelPinBody {
  bytes channel_id = 1;
  bytes cast_hash = 2;          // Hash of the cast to pin
}

enum HyperMessageType {
  // ...
  HYPER_MESSAGE_TYPE_CHANNEL_PIN = 112;
  HYPER_MESSAGE_TYPE_CHANNEL_UNPIN = 113;
}

Only one pinned cast per channel at a time. A new pin replaces the previous one.

Validation rules:

• Signer must be owner or moderator
• cast_hash must reference a cast that has channel_id as its parent (validated against the shard trie)

3.7 ChannelModerate

Owner or moderator hides/unhides a cast in the channel.

message ChannelModerateBody {
  bytes channel_id = 1;
  bytes cast_hash = 2;
  ChannelModerateAction action = 3;
}

enum ChannelModerateAction {
  CHANNEL_MODERATE_ACTION_NONE = 0;
  CHANNEL_MODERATE_ACTION_HIDE = 1;
  CHANNEL_MODERATE_ACTION_UNHIDE = 2;
}

enum HyperMessageType {
  // ...
  HYPER_MESSAGE_TYPE_CHANNEL_MODERATE = 114;
}

Validation rules:

• Signer must be owner or moderator
• cast_hash should reference a cast in this channel

---

4. Cast-Channel Association

Semantics

Using the parent_url in a cast, channel root casts should refer to it by farcaster://channel/{key}

Validation

• If a channel reference in parent_url is set, the referenced channel must exist in the hyper trie
• If the channel's casting_mode is MEMBERS_ONLY, the cast signer must be a member (checked against hyper trie)
• Banned users cannot post to the channel regardless of casting mode

---

5. Storage

Hyper Trie Keys

All channel data is stored in the hyper trie (prefix 23), not the snapchain trie (prefix 8).

Channel metadata:
  [channel_id] ++ [0x01] -> ChannelState (serialized)

Channel members/roles:
  [channel_id] ++ [0x02] ++ [fid_bytes] -> ChannelMemberState

Channel follows:
  [channel_id] ++ [0x03] ++ [fid_bytes] -> 1 (exists = following)

Channel pin:
  [channel_id] ++ [0x04] -> cast_hash

Channel moderation:
  [channel_id] ++ [0x05] ++ [cast_hash] -> ChannelModerateAction

Pending ownership transfer:
  [channel_id] ++ [0x06] -> ChannelTransferState

Channel key -> ID index (for lookup by key):
  [0xFF] ++ SHA256(key)[0..16] -> channel_id

ChannelState

message ChannelState {
  bytes channel_id = 1;
  string key = 2;
  string name = 3;
  string description = 4;
  string image_url = 5;
  uint64 owner_fid = 6;
  CastingMode casting_mode = 7;
  uint64 created_at = 8;        // Farcaster timestamp
  uint64 updated_at = 9;
}

ChannelMemberState

message ChannelMemberState {
  uint64 fid = 1;
  bool is_member = 2;
  bool is_moderator = 3;
  bool is_banned = 4;
  uint64 member_since = 5;       // Farcaster timestamp, 0 if not member
  uint64 moderator_since = 6;    // Farcaster timestamp, 0 if not mod
  uint64 banned_at = 7;          // Farcaster timestamp, 0 if not banned
}

RootPrefix Values

pub enum RootPrefix {
    // ... existing values ...
    // No new RootPrefix needed — channel data lives in the hyper trie (prefix 23)
    // using channel_id-prefixed keys within the trie's key space.
}

Channel data does not need a new RootPrefix — it lives within the hyper trie's existing key space (prefix 23), distinguished by channel_id prefixes.

---

6. Processing Flow

HyperEngine Integration

Channel messages are processed in HyperEngine alongside existing hyper signer messages. The processing flow:

1. Channel message arrives via hyper gossip topic
2. HyperEngine::propose_state_change() picks it up from the mempool
3. Validation checks (authorization, channel existence, member state) are performed against the hyper trie
4. On success: hyper trie is updated with new channel state, HubEvent is emitted
5. Immediate commit (same pattern as hyper signer messages — separate from snapchain)

Store: ChannelStore

A new store for channel operations, analogous to OnchainEventStore but for channel state:

pub struct ChannelStore {
    db: Arc<RocksDB>,
}

Methods:

• create_channel(msg, trie, txn) — validate + insert channel state
• update_channel(msg, trie, txn) — validate ownership + update fields
• set_member(msg, trie, txn) — validate authorization + update member state
• set_follow(msg, trie, txn) — insert/remove follow key
• set_pin(msg, trie, txn) — validate authorization + update pin
• moderate_cast(msg, trie, txn) — validate authorization + set moderation action
• transfer_ownership(msg, trie, txn) — initiate transfer
• accept_transfer(msg, trie, txn) — complete transfer
• get_channel(channel_id) — read channel state from trie
• get_member(channel_id, fid) — read member state
• is_following(channel_id, fid) — check follow status
• get_channel_by_key(key) — look up channel_id from key index

---

7. API Endpoints

Channel CRUD

GET /v1/hyper/channel?key=<key>
GET /v1/hyper/channel?channel_id=<hex>

Returns ChannelState for the given channel.

Channel Members

GET /v1/hyper/channel/members?channel_id=<hex>&page_size=<n>&page_token=<token>
GET /v1/hyper/channel/member?channel_id=<hex>&fid=<fid>

Returns member list or individual member state.

Channel Followers

GET /v1/hyper/channel/followers?channel_id=<hex>&page_size=<n>&page_token=<token>

Channel Moderation Log

GET /v1/hyper/channel/moderation?channel_id=<hex>&page_size=<n>&page_token=<token>

User's Channels

GET /v1/hyper/channels/by-fid?fid=<fid>&role=<owner|moderator|member|following>

---

8. Storage Limits

Channel operations consume hyper storage, not snapchain storage. Limits per FID:

Operation	Limit
Moderator slots per channel	10 (excluding owner)

These limits are enforced by counting keys in the hyper trie prefixed by the FID's channel operations.

---

9. Implementation Phases

Phase 1: Channel Creation + Metadata

• Add ChannelCreate, ChannelUpdate message types to hyper.proto
• Implement ChannelStore with create/update/get
• Add parent_url schema awareness to CastAddBody (backward-compatible — optional field)
• Add validation for channel existence on cast submission
• Add GET /v1/hyper/channel endpoint

Phase 2: Membership + Follows

• Add ChannelMember, ChannelFollow/ChannelUnfollow message types
• Implement member/follow CRDT logic in ChannelStore
• Add casting mode enforcement (members-only channels)
• Add member/follower query endpoints

Phase 3: Moderation

• Add ChannelPin/ChannelUnpin, ChannelModerate message types
• Implement ban enforcement on cast submission
• Add moderation query endpoints

Phase 4: Ownership Transfer

• Add ChannelTransferOwnership, ChannelTransferAccept message types
• Implement two-phase transfer logic

Phase 5: Migration

• Backfill existing channels from application-layer data into hyper trie

---

10. Open Questions

1. Channel deletion: Should channels be deletable? If so, what happens to casts that reference the channel_id? Options: soft-delete (mark inactive), hard-delete (orphan casts), or channels are permanent.

2. Channel key transferability: Should the key be transferable separately from the channel? E.g., if someone creates "ethereum" and transfers ownership, the new owner keeps the key. But what if someone wants to "rename" a channel — should they be able to release the key?

3. Invite flow: The current system has a two-phase invite flow (invite + accept) for membership. Should the protocol support this, or should membership be a direct action by authorized users? Direct is simpler but removes consent.

4. Storage cost model: Should channel creation cost storage units (reducing available message storage), or should there be a separate channel-specific allocation?

5. Channel discovery: Should the protocol provide a way to enumerate all channels (e.g., a global channel index in the trie)? Or is discovery an application-layer concern?

6. Moderation appeals: Should the protocol support an appeal mechanism for bans/hides? E.g., a ChannelAppeal message that the owner must explicitly reject to maintain the ban.

7. Rate limiting: How to prevent spam channel creation/squatting? Should there be a cooldown period between channel creations per FID?

---

11. New Proto Additions Summary

File	Addition
hyper.proto	CastingMode enum
hyper.proto	ChannelCreateBody message
hyper.proto	ChannelUpdateBody message
hyper.proto	ChannelTransferBody message
hyper.proto	ChannelTransferAcceptBody message
hyper.proto	ChannelMemberBody message
hyper.proto	ChannelMemberAction enum
hyper.proto	ChannelFollowBody message
hyper.proto	ChannelPinBody message
hyper.proto	ChannelModerateBody message
hyper.proto	ChannelModerateAction enum
hyper.proto	ChannelState message
hyper.proto	ChannelMemberState message
hyper.proto	HYPER_MESSAGE_TYPE_CHANNEL_CREATE = 104
hyper.proto	HYPER_MESSAGE_TYPE_CHANNEL_UPDATE = 105
hyper.proto	HYPER_MESSAGE_TYPE_CHANNEL_TRANSFER = 106
hyper.proto	HYPER_MESSAGE_TYPE_CHANNEL_TRANSFER_ACCEPT = 107
hyper.proto	HYPER_MESSAGE_TYPE_CHANNEL_MEMBER = 108
hyper.proto	HYPER_MESSAGE_TYPE_CHANNEL_FOLLOW = 110
hyper.proto	HYPER_MESSAGE_TYPE_CHANNEL_UNFOLLOW = 111
hyper.proto	HYPER_MESSAGE_TYPE_CHANNEL_PIN = 112
hyper.proto	HYPER_MESSAGE_TYPE_CHANNEL_UNPIN = 113
hyper.proto	HYPER_MESSAGE_TYPE_CHANNEL_MODERATE = 114

[vrypan]

Side-note:

I like the use of farcaster:// URI schema. However, before we start using it, it would be good to define it, to ensure that future extensions will follow a consistent pattern.

I had submitted an FIP here farcasterxyz/protocol#123 and while it is outdated, I think it captures a number of concerns and ideas that should be considered.

• Which are the resources we would like to address? Seems like user, cast and channel are good candidates for now, but maybe they can be extended with parent and other entities.
• How do we address these resources? A decent answer is probably use the protocol-level id of the entity (for example fid and not fname).
• How do we format ids (above)? In some cases we are used to decimal format (fids) and in other cases hex (cast hash). Do we keep this per case? Do we allow both and let consumers decide based on the presence of 0x or not?
• Do we (need to) keep fid/hash to identify casts, or is it ok to use hash? It seems to me that the use of fid is more about allowing efficient lookups and less about identifying the resource -I may be wrong.

An other question is if we design farcaster URIs to also describe intents (like castAdd, reactionAdd, etc).

[CassOnMars]

I agree that is useful to define. To answer the questions:

• specifically this FIP was only prescriptive of channel addressing, but it's certainly possible to do them all in one shot
• agree that ID should always be preferred
• ID formatting should probably follow the convention of its underlying type. A byte slice or array should be hex, signed or unsigned ints should be decimal.
• The fid/hash combination is especially important for two reasons: the hash identifier alone can conflict given truncation, and fid identifies the shard the data lives in

I would consider intent URIs to be out of scope, but worthy of a full FIP. btw, please import your FIP!

[shazow]

My one fantasy for channels from a couple years ago is to have them owned and moderated onchain: https://farcaster.xyz/shazow.eth/0x1d3eaa58

1. Create a channel by calling a contract to register a namespace and set the moderator contract. By default this contract can be a WarpcastOracle singleton or something, which delegates mod decisions to come from a Warpcast signer.
2. Moderator actions/permissions are evaluated by hubs offchain but against onchain code (ERC-1271, isValidSignature).
3. Channel settings is easiest to imagine for onchain, but I think we could have programmable ACL onchain too. For example: Imagine writing a Channel.can_write(signature, {other context}): boolean function which just returns true on Mondays and false on other days. Again, evaluated offchain, but deployed as a contract onchain then assigned as the permission oracle for that channel onchain.

This would allow for more sovereign ownership, more experiments around governance/moderation, and possibly serve as a multi-protocol nexus (not just for Farcaster) for a channel.

I get the sense there's no appetite for moving more of these kinds of things onchain at this point but thought I'd throw it in anyway.

[CryptoExplor]

this is the FIP I've been hoping would get written. channels being entirely at the application layer is the single biggest friction point when building mini-apps — you can't reliably query "is this user a member of this channel" or "is this cast in this channel" without hitting proprietary APIs. protocol-native channels fix that.

on the farcaster:// URI spec — vrypan's point is important and worth resolving before this ships. the farcaster://channel/{key} convention in this FIP is straightforward, but if we're also eventually doing farcaster://cast/{fid}/{hash} and farcaster://user/{fid} then they should all come from the same spec pass. CassOnMars' answers on ID formatting make sense (bytes=hex, ints=decimal). I'd add: lock the scheme now, even if the full spec is a separate FIP, so client implementations don't diverge.

on shazow's onchain ACL idea — programmable can_write(signature, context) via ERC-1271 is genuinely compelling for advanced use cases, but I think it's a different FIP. the proposal here gives us 95% of what we need (decentralized ownership, CRDT-mergeable state, censorship-resistant bans) without the complexity of onchain execution for every permission check. ship this, let the ecosystem see what breaks, then layer in programmable ACL once there's a concrete use case that needs it.

on open question #7 (channel squatting) — this is going to be a real problem. popular key names like "dev", "nft", "base" will get grabbed immediately. a few ideas: require a small storage fee for channel creation (burns or goes to treasury), implement a brief claim window where existing Warpcast channel owners get first claim during migration, or use a time-decay mechanism where unclaimed squatted channels can be challenged after 90 days of inactivity.

on open question #3 (invite flow) — direct action by authorized users is cleaner. the two-phase invite with accept adds complexity for a case that's probably rare. if consent is needed, clients can implement it at the UX layer ("you've been added to X channel, accept?") without baking it into the protocol.

on open question #1 (channel deletion) — channels should probably be permanent (non-deletable) at the protocol level, similar to how FIDs can't be deleted. soft-delete is the practical answer: mark inactive, stop enforcing casting mode, orphaned casts just have a dead parent reference. hard deletion would break any client that cached the association.

overall the phased implementation plan looks right. phase 1 (create + metadata) gives immediate value and lets client teams start integrating before the full membership system lands.

[arcabotai]

This is one of the most important Hypersnap FIPs because channels are where social reality actually happens, and today that whole layer is too backend-shaped.

The core split I'd preserve is: channel identity/membership/follows should be protocol-native, while more experimental moderation policy can stay pluggable later. That gets you portability and CRDT semantics now without turning the first version into a governance language for every possible ACL idea.

Two implementation details feel especially important:

1. existing channel owners need a first-claim / migration window or the legitimacy fights around key squatting will be immediate
2. deletion should be soft-delete only. Breaking historical cast->channel references would create more problems than it solves.

The farcaster:// direction is also the right one. I agree it should be part of a broader URI spec pass, but locking the addressing pattern early will save clients from inventing incompatible conventions.

— Arca

[arcabotai]

After rereading the current version, I think the main thing to tighten is the canonical identifier story.

If channel_id is derived from the initial key, then farcaster://channel/{key} is fine as a human-readable alias, but I would not make it the canonical cast parent. Historical cast-to-channel references should probably point at the stable channel_id, e.g. farcaster://channel/<hex_channel_id>, with clients resolving/displaying the current key. That preserves vrypan's “prefer protocol IDs over names” point and keeps future rename/release decisions from silently changing what old casts mean.

Two invariants I would spell out before implementation:

• ChannelCreate should atomically reserve both the key and derived id in the same state transition, with a deterministic conflict rule for simultaneous creates of the same key. Otherwise squatting/race behavior gets pushed into node ordering.
• channel key migration should be explicit: existing app-layer owners get a claim window, unclaimed keys become available, and scarce/generic keys need a cost or cooldown. Per-FID cooldown alone will not stop distributed squatting.

The phase split still looks right. I would just make “channel id is the durable reference; key is a display/resolution handle” a hard rule now, because every client that stores parent references will inherit this choice.

— Arca

[arcabotai]

One implementation invariant still looks underspecified: cross-domain ordering.

Section 4 validates a shard cast against channel membership/ban state in the hyper trie, while Section 6 says channel operations commit through HyperEngine separately from snapchain. If a ChannelMember/ban update races a CastAdd, two nodes can observe the operations in different orders unless the cast validity rule names an exact Hyper state snapshot. The same boundary appears when ChannelPin or ChannelModerate validates a cast stored in a shard.

I would make one of these rules explicit before Phase 1:

• channel-sensitive casts carry or derive a finalized Hyper height/root, and authorization is evaluated at that snapshot; or
• shard blocks evaluate against a protocol-defined Hyper checkpoint with a fixed delay.

Then specify reorg behavior and what happens when the referenced channel/cast data is not locally available. For moderation, recording a dangling cast reference as inert until inclusion is proven may be safer than making Hyper validity depend on a live cross-shard lookup.

Without a deterministic snapshot rule, the CRDT behavior inside each store can be correct while cross-store message validity still depends on arrival order.

— Arca

[almithani]

From a user perspective, I think this FIP is extra important in the wake of Neynar looking for a buyer. We have dozens of curated channels that could be lost if we don't adopt channels on protocol.

Channels are a unique primitive that require exploration. This will only happen when they are on protocol instead of client.

I don't believe FC can reach its full potential without on-protocol channels.

[arcabotai]

The risk here is not just losing channel names; it is losing authoritative state during a backend transition.

Phase 5 should define a migration artifact that independent hubs can verify: snapshot time/height, channel_id ↔ key mapping, owner/mod/member/ban state, provenance for the export, and deterministic conflict rules for changes after the snapshot. I would also require a public dry run plus a bounded delta-import window before cutover. Otherwise nodes can agree on the new protocol semantics while bootstrapping from different app-layer snapshots, recreating centralization at genesis.

The concrete question for this FIP: who authorizes the initial imported state, and what proof/challenge path does a channel owner have when that state is wrong?