Submit

Best of github.com/farcasterxyz on Kiwi News

farcasterxyz on GitHub · Most upvoted by Kiwi News readers

19 stories by farcasterxyz on GitHub have been shared on Kiwi News since 11 May 2023, with 46 upvotes and 12 comments in total. The latest was shared on 27 August 2026. They are listed below, most upvoted first.

Text under a title is an AI summary of the linked article.

  1. FC is gifting everyone a year of free storage
    5 upvotes · 2 comments · · original on github.com

    Farcaster's proposal (FIP) would give existing users one extra year of free storage so their casts, reactions and links are not removed when storage expires, with the first units set to expire on Aug 28, 2024. The authors are @danromero, @horsefacts, @sanjayprabhu and @varunsrin. To offset the load on hubs, storage units rented on or after Aug 28, 2024 would be valid for one year instead of two, with message limits 60% lower and the cost reduced from $3 to $2. The proposal says the impact on new users may be slightly negative because of the smaller limits, and it says hub storage should not change much over the long term.

  2. FIP: Opportunity For Another Consensus · farcasterxyz protocol · Discussion #257
    5 upvotes · 1 comment · · original on github.com

    A hybrid model combining a protocol treasury with optional validator cost-cover fees is proposed as a robust, low-risk alternative. A fixed share of Pro subscriptions, 30% in the example, would fund a treasury distributed monthly to active validators according to the read/write traffic they serve and a cryptographic check that they store all data. Validators could also charge minimal micro-payment fees for complex or high-volume writes, mainly paid by commercial applications or bots, while regular users would pay nothing for normal actions. The proposal claims this would be sustainable, fair, and resistant to capture by a single entity.

  3. Farcaster Collectible Casts
    5 upvotes · 0 comments · · original on github.com

    Farcaster has introduced Collectible Casts, which let users collect any cast as an ERC721 NFT through an ascending USDC auction on Base. The winning bidder receives the token in their wallet, with 90% of the winning bid going to the creator and the remaining 10% going to the protocol treasury for growth incentives. Bidding is restricted to Farcaster users through an offchain authorizer signature, and the auction can be extended when bids arrive near the end. The backend signer can cancel auctions if a cast is deleted or a user opts out, and an owner-only recover function serves as an escape hatch for stuck auctions.

  4. FIP: Direct Casts
    5 upvotes · 0 comments · · original on github.com

    This Farcaster draft proposes moving Direct Casts, the existing Warpcast messaging feature, onto hubs while retaining privacy and secrecy guarantees. It adopts the asynchronous Triple-Ratchet Protocol for per-device-per-application messaging, with users able to revoke access to a given device or application for later messages. The draft adds two new stores, Keys and DirectCasts, each with its own message types and CRDT rules. Keys have a per-user size limit of 200 and a cutoff one year after release unless extended in a new FIP, while Direct Cast Requests have a per-user limit of 200.

  5. FIP: Social Attestations
    4 upvotes · 2 comments · · original on github.com

    Farcaster's proposed FIP would let users verify Github and Twitter/X accounts through a social attestation system, with a standard extensible to other platforms later. An app such as Warpcast would verify ownership via OAuth and publish a UserDataAdd message of the matching type, signed by an app key registered to the app's fid. The proposal states that attestations are not verified by the protocol, not unique per fid, and strongly typed, and that Warpcast plans to display its attestations only on user profiles because they can be spoofed. Warpcast has begun verifying Twitter/X accounts, with Github support possible later and no timeline set.

  6. Snapchain v0
    3 upvotes · 0 comments · · original on github.com

    Snapchain is an open-source, canonical implementation of the data storage layer for the Farcaster social protocol, described as a blockchain-like decentralized p2p network that stores data created by Farcaster users. The project states goals of processing at least 10,000 transactions per second, written in Rust, and running for under $1,000 per month with real-time access to user data. Running a node requires 16 GB of RAM, 4 CPU cores or vCPUs, 1.5TB of free storage, a public IP address, and ports 3381 to 3383 open on TCP and UDP. The document also describes an admin-gated mesh topology endpoint at GET /v1/mesh and says the project is currently in its migration phase.

  7. FIP: External cast data
    3 upvotes · 0 comments · · original on github.com

    FIP "External cast data" by @vrypan and @davidfurlong proposes enabling long casts by storing their content at an external URI rather than on Farcaster hubs, and embedding it using Embed.url. The proposal supports only plain text long casts and is designed to be extended later to other data types such as location, audio and events without hub changes. Long-cast JSON-LD payloads can be embedded in an HTML page or hosted stand-alone under an fc: URI scheme, and the payload must be less than 32kb. The authors state that the 32kb limit allows content publishable as a 25,000-character long tweet, and hub requirements and storage requirements are unchanged.

  8. FIP: Onchain Signers
    3 upvotes · 0 comments · · original on github.com

    Farcaster's proposed FIP would track app signers onchain in a Key Registry on an L2 contract instead of in the current offchain CRDT, to avoid usability problems. The proposal maps keys to fids rather than custody addresses, so the signer relationship persists when an fid changes custody, and onchain storage avoids the CRDT's signer limit, where adding a signer past the cap removes the earliest one. Under the proposal, the Key Registry is deployed to the L2 at a stated address, and after a migration timestamp is set, hubs will reject offchain signers created at or after that timestamp.

  9. farcasterxyz/client: Snapshot of the Farcaster client monorepo
    2 upvotes · 0 comments · · original on github.com

    This GitHub repository is a snapshot of the Farcaster client monorepo, without the Farcaster Wallet implementation, intended as a reference for building a social client on the Farcaster protocol. Both the mobile and web clients run locally and point to Farcaster's current production API. Setup involves running pnpm install and pnpm watch in the project root, then launching either the mobile app with pnpm ios or the web app with pnpm start. The repository is a one-way, automatically generated snapshot, so pull requests and issues opened here cannot be merged or tracked, and each update replaces main with a single fresh commit.

  10. FIP: Introducing Ordering
    2 upvotes · 0 comments · · original on github.com

    Farcaster's engineering team proposes "Account Ordering," a partially ordered sequence-number scheme for user data, as a fix for hubs drifting out of sync. The article says sync has slowed as the network passed 500M messages, and that per-hub rate limits, missing onchain state, gossip failures and pruning all compound the drift. Under account ordering, each user's app key gets its own sequence chain, which the article estimates would make sync 10x to 100x faster and reduce rate-limit collisions. The article also describes a Global Ordering alternative using a sequencer and blocks, which it calls cleaner but with a single point of failure and a harder rewrite. Commenters suggested per-signer ordering, and one proposed Rate-Limiting Nullifiers as a way to move rate-limit enforcement to clients.

  11. Farcaster added Solana verification support
    1 upvote · 4 comments · · original on github.com

    This article is a code diff from the Farcaster hub software, not a news report or essay about Solana verification. It updates FARCASTER_VERSION from "2023.12.27" to "2024.2.7" and adds a version schedule entry for "2024.2.7" that expires at 4/3/24 00:00 UTC. It also removes the earlier "2023.12.27" constant and adds the matching schedule entry, which expires at 2/21/24 00:00 UTC. The diff itself does not mention Solana verification, so that claim cannot be confirmed from the text.

  12. Farcaster Frames v2 demo
    1 upvote · 3 comments · · original on github.com

    This article is a tutorial for building a Farcaster Frames v2 demo app in NextJS, TypeScript and React, using the official @farcaster/frame-sdk and Wagmi. It walks through installing dependencies, creating a custom Wagmi connector for the user's Farcaster wallet, and configuring Base as the connected network. It also covers calling sdk.actions.ready() to hide the splash screen and reading sdk.context for the current user's profile. The author notes that context data is unauthenticated during the Framesgiving developer preview and should be treated as spoofable.

  13. Add GNU GPL v3 license by sanjayprabhu
    1 upvote · 0 comments · · original on github.com
  14. FIP: Farcaster "Quick Auth" server protocol discussion #231
    1 upvote · 0 comments · · original on github.com

    This FIP proposes a "Quick Auth" server that verifies Sign In with Farcaster (SIWF) credentials and issues signed JWTs, so developers avoid handling nonces, RPC state checks and session logic themselves. The article says integrating SIWF is significantly harder than integrating providers like Sign In with Google, which return a JWT that can be validated against the provider's server. The proposed open-source service would expose four endpoints: POST /nonce, POST /verify-siwf, GET /verify-jwt, and GET /.well-known/jwks.json for local verification. Tokens would carry the user's FID, the valid domain, the issuer and an expiration time, and the service could be hosted publicly at auth.farcaster.xyz or self-hosted. Its use would be optional.

  15. FIP: Auth Addresses · farcasterxyz protocol · Discussion #225
    1 upvote · 0 comments · · original on github.com

    Authors @v, @horsefacts and @sanjay propose "auth addresses," a new Key Registry key type that lets an Ethereum address sign in on behalf of a Farcaster user without sharing custody credentials. A custody address adds an auth address to the registry, after which apps performing Sign in With Farcaster should accept its signatures for that fid. The article's example has Coinbase Wallet generate an ECDSA auth address and an Ed25519 signer, then add both in a single transaction. Auth keys cannot add signers onchain for now, and revoking an auth address is permanent. Transferring an fid does not revoke its auth addresses.

  16. FIP: Reduce Storage Limits
    1 upvote · 0 comments · · original on github.com

    Farcaster proposes lowering per-unit storage limits for casts, reactions and links without changing storage unit prices, to slow the growth of hub data. Hub data is about 140GB today and grows 1GB/day, with a soft cap at 7 TB where high-performance NVMe disks tap out. Casts would drop from 5000 to 4000, and reactions and links from 2500 to 2000, an estimated 5% reduction in hub data size. About 1% of accounts, mostly programmatic ones, would lose casts and links, and about 5% would lose reactions; the new limits take effect 2024.08.08, one week after protocol version 2024.07.24.

  17. FIP: ENS Support in Hubs
    1 upvote · 0 comments · · original on github.com

    Farcaster's FIP "ENS Usernames" proposes a two-tier naming system in which users choose between a free off-chain ENS name (fname) moderated by the Farcaster team or a decentralized on-chain ENS name that costs gas. Fnames are issued under the fcast.id ENS namespace via CCIP by a nameserver at fnames.facaster.xyz, and users can claim one by submitting an EIP-712 signed message proving ownership of an fid. Hubs will track valid usernames, re-validate ownership, and emit events when usernames change, and a validation job runs at 2am UTC to revoke USER_DATA.USERNAME messages that are no longer correctly owned.

  18. Farcaster Proposals List
    1 upvote · 0 comments · · original on github.com
  19. Farcaster Improvement Proposal: Links
    1 upvote · 0 comments · · original on github.com

    Farcaster Improvement Proposal "Links" by Varun Srinivasan and Cassandra Heart proposes a new message type that stores long-lived, directed, typed relationships between users, such as follows, so that they can be kept on Hubs and make switching applications easier. Each user can store 2,500 links, a limit chosen after analysis of Warpcast follow data, and a Link message is at most 164 bytes, adding up to 382 GB per million users. The proposal says Links will be included in the 2023.5.31 protocol release, and Hubs must not accept Link messages until 2023.6.14 (1686700800000 in unix epoch), when older versions are shut down.

Most discussed

  1. Farcaster added Solana verification support · 4 comments
  2. Farcaster Frames v2 demo · 3 comments
  3. FC is gifting everyone a year of free storage · 2 comments
  4. FIP: Social Attestations · 2 comments
  5. FIP: Opportunity For Another Consensus · farcasterxyz protocol · Discussion #257 · 1 comment