FIP: Block Links

[marthendalnunes]

Abstract

This FIP standardizes block as a canonical Farcaster Link type, so user block intent is portable across clients.

A block uses existing Link messages:

• MESSAGE_TYPE_LINK_ADD with linkBody.type = "block" to block
• MESSAGE_TYPE_LINK_REMOVE with linkBody.type = "block" to unblock

No protobuf or message-type additions are required.

Problem

Blocking is a core moderation primitive.

Block state is frequently app-local today, which leads to inconsistent cross-client behavior and weak portability of user moderation preferences.

Farcaster already supports typed Links. Standardizing type="block" enables interoperable, chain-derived block state without introducing new protocol primitives.

Specification

1) Canonical Link Type

block is a canonical LinkBody.type value.

• LinkAdd(type="block", target_fid=B) means A blocks B
• LinkRemove(type="block", target_fid=B) means A unblocks B

"block" satisfies existing Link constraints (type <= 8 bytes).

2) Existing Link Validation and CRDT Rules Apply

block links MUST follow existing Link rules, including:

• signer/signature validity
• known target fid
• Link conflict resolution and ordering semantics
• remove-wins tie behavior at equal timestamp for add/remove

No new CRDT is introduced.

3) State Semantics

For key (fid=A, link_type="block", target_fid=B):

• active state is true iff highest-order message is LINK_ADD
• active state is false iff highest-order message is LINK_REMOVE or absent

Blocks are unilateral; this FIP does not define mutual block semantics.

4) API Expectations

Nodes and SDKs SHOULD accept link_type=block in existing Link APIs (HTTP and gRPC), including:

• GetLink / linkById
• GetLinksByFid / linksByFid
• GetLinksByTarget / linksByTargetFid
• GetAllLinkMessagesByFid (and equivalent filtering/pagination paths)

Older implementations may reject until upgraded.

5) Link Compact State Compatibility

block MUST be handled as a standard Link type in compact-state paths (including Link compact-state messages) with no special-case merge logic.

6) Implementation Guidance (Non-Consensus)

Clients and apps MAY reject self-block (fid == target_fid) for UX consistency. This is non-consensus guidance.

Storage Impact

block consumes existing Link quota under the network's active storage configuration.

This FIP does not hardcode quota numbers because storage economics can vary across cohorts/config eras.

Directional expectation: block links are generally lower-volume than follow links for most users (high-friction moderation action vs high-frequency social action). This is not a protocol invariant and should be validated with telemetry.

Add/remove churn can consume more Link capacity than active block count alone suggests.

Rationale

• Safety and moderation portability: users expect moderation controls to follow them across clients.
• Minimal protocol surface: reuses existing Link primitives and merge rules.
• Operational simplicity: avoids introducing a new message family/store before adoption is proven.
• Predictable integration: indexers and clients can use existing Link infrastructure.

Backward Compatibility

• Wire-format compatible (no schema changes)
• Requires implementation/docs updates where link types are currently treated as follow-only
• Existing Link behavior remains unchanged

Security and Privacy Considerations

• Block links are public protocol metadata.
• This improves interoperability but exposes block-graph relationships.
• Apps needing private moderation should continue to offer local/private controls (e.g., mutes) in addition to public block links.

Rollout

1. Add block support in link-type handling, validation paths, and Link API filters.
2. Add conformance tests for:
   • add/remove merge behavior for type="block"
   • link_type=block query behavior
   • compact-state compatibility for block
3. Update docs/examples to include link_type=block.

[topocount]

This is a really well thought-out proposal! Your discussion of storage is thorough but there is one implementation detail that needs to be handled. Given how much more undesirable it would be for a block link to be pruned compared to a follow link to be pruned when storage limits are reached, I think we need to find a way to minimize the risk of pruning blocks due to follow activity.

We could either just not prune blocks, since they are a generally low volume message (and the blocks table is quite small, still) but if we want to think defensively, it makes sense to configure rate limits for blocks somehow, maybe based on total links a user has.

The alternative is configuring an entirely separate storage type and rate limit calculation for blocks, which is unfavorable in my opinion.

[vrypan]

How is it possible to have >1 block per second and <100k rows?

But the important thing is GB. This is what defines if a user can run a node or not. How many GB?

[christopherwxyz]

If a user is willing to forego their follow graph links, I can imagine they would not particularly be concerned with their blocks.

Another alternative is to date blocks at FARCASTER_EPOCH so that pruning other relationships happens first.

[topocount]

@vrypan where are you seeing >1 block per second?

[vrypan]

I may be wrong, and I remember the rate my node fetched blocks when syncing. I no longer have a node of my own to investigate. What's the actual rate?

[topocount]

it's quite low, looking at farcaster's DB and api, much lower than 1 block/s

[CryptoExplor]

Supportive of this proposal — standardizing type="block" as a canonical Link type is the right call. As a mini-app developer, inconsistent cross-client block state is a real UX problem. Users expect blocks to follow them everywhere, and right now that's effectively app-local.

On the storage/pruning concern (@topocount):

The core concern is valid: blocks being pruned due to follow-link churn would be a bad user experience. @christopherwxyz's suggestion to date blocks at FARCASTER_EPOCH to deprioritize them for pruning seems pragmatic for v1. A user who fills their link quota with follows implicitly accepts that risk.

That said, if block volume really is much lower than 1/s in practice (as the data shows), the pruning risk may be overstated. The bigger concern is probably adversarial: a user who wants to erase someone's blocks could spam follow-adds to force pruning. A simple rate limit specifically for block-type link operations (separate from general link rate limits) could close that vector without needing a fully separate store.

On the privacy note:

The FIP correctly calls out that block links are public protocol metadata and expose the block graph. For mini-apps that want to offer softer moderation tools (mutes, content filters), this distinction matters — a public block is a strong social signal, while a local mute is private preference. Both are useful. Worth making sure SDK docs distinguish these clearly so developers pick the right primitive.

On the API side:

The expectation that link_type=block works transparently in existing Link APIs is correct and important. From the developer side: GetLinksByTarget(target_fid=me, link_type=block) being available is what enables mini-apps to implement block-aware content filtering (e.g., don't show casts from FIDs that have blocked the viewer). That use case should be explicitly documented in the rollout guide.

Overall this is a clean, minimal FIP that delivers real value without protocol complexity. Ready for finalization in my view.

[arcabotai]

I don't think this should be finalized as written.

The FIP gets the implementation path right, but I think it picks the wrong social primitive to make canonical. follow and block both fit mechanically into LinkBody.type, but they are not the same class of user intent.

A follow is normally meant to be public. A block is often a boundary, a safety action, or a private preference. Turning it into durable public protocol metadata creates a negative social graph that every hub, indexer, ranking system, client, and third-party app can query forever. LinkRemove(type="block") removes active state, but it does not make the historical disclosure disappear for anyone who observed or indexed it.

That is bad for decentralization in a few ways:

• It pushes moderation toward one canonical public graph instead of letting clients experiment with different safety models.
• It makes client portability depend on public disclosure, which is a bad default for a social protocol.
• It creates a ready-made retaliation surface: "who blocked me," "who blocks whom," block-list analytics, social pressure maps, and harassment targeting.
• It gives indexers and large clients another high-signal relationship graph to centralize around.
• It conflates protocol interoperability with protocol publicity. Those are not the same thing.

The privacy section says apps needing private moderation can keep local/private controls such as mutes. I think that split makes the proposal weaker, not stronger. Users will now have two concepts that look similar in UX but have radically different privacy properties: a portable public block and a private non-portable mute. Most users will not understand that distinction at the moment they are trying to protect themselves.

Storage is also more serious than the FIP makes it sound. If blocks share normal Link quota and pruning semantics, then safety state can be affected by unrelated follow churn or adversarial link behavior. If blocks need special pruning, special rate limits, or a separate storage class to be safe, that is a sign they are not just another ordinary Link type.

I think the safer direction is:

1. Do not make public type="block" the default portable moderation primitive.
2. If a public block is still standardized, name and document it as explicitly public, e.g. "public block" / "public deny," with strong UX requirements.
3. Treat private portable moderation as the actual missing primitive, whether through encrypted user data, client-synced private state, delegated storage, or another design that does not require broadcasting the block graph.
4. If this FIP proceeds anyway, blocks should have separate storage/rate-limit/pruning semantics and docs should warn that target-indexing exposes who blocked a given FID.

The minimal-protocol-surface argument is attractive, but this is one of those cases where minimal implementation surface creates a much larger social surface. Public follows are part of the social graph. Public blocks are a safety graph. I don't think Farcaster should casually make that graph canonical.