FIP: Direct Casts

[varunsrin]

FIP: Direct Casts

Title: Direct Casts
Type: Implementation FIP
Authors: @ashoat, @deodad , @v

Abstract

TBD

Problem

Users on public social networks often want to start private conversations within their apps. Networks like X and Instagram have their own in-built messaging system even though general purpose systems like Whatsapp and Signal exist. The simplicity of being able to tap a profile and send a message to someone without switching to a different app or network is important.

Warpcast has a direct messaging system built into its app that uses the Farcaster social graph. It would benefit the ecosystem if this was interoperable so that other clients could easily integrate it into their applications. It would also be useful if this messaging layer was programmable so that developers could easily build agents that can communicate directly with users without having to go through the public messaging layer.

End-to-end encryption and decentralization are out of scope for the initial version of the protocol and will be considered in the next version. While Farcaster users want e2e encryption and decentralization, interoperability and programmability are by far the most important priorities. Trying to achieve all four goals will significantly slow down the release of this protocol and may even make some features impossible to build or difficult to implement in a user friendly way.

Proposal

Farcaster operates a direct cast server which lets apps send and receive messages on behalf of their users. A user must authorize an app by signing a message from their custody address, which then allows that app to fetch messages on their behalf. This is similar in architecture to the fname server which handles off-chain fname registrations.

Authentication

Users sign an ECDSA EIP-191 signature from the custody address. It includes a nonce, timestamp and application url to prevent replay attacks.

Grants access to your Farcaster Direct Casts.

DC authorization for Farcaster FID 6841

URI: https://dc.farcaster.xyz/authorize-app
Version: 1
Chain ID: 1
Nonce: 32891756
Issued At: 2021-09-30T16:25:24Z

The application relays this signed message to the DC server, which returns a shared secret that can be used to fetch messages. All further request to the DC server are performed using this message. The user can also produce a revocation signature which removes the app’s permissions to keep fetching messages.

APIs

The Direct Cast server exposes APIs for all functionality like sending messages, fetching an inbox and searching through messages. Most endpoints will provided as HTTP endpoints except for receive message and notification count endpoints which use websockets.

Apps will need to build their own UI for displaying messages and systems for sending push and in-app notifications to their users when new messages are received.

Lifecycle: adding a new client and sending messages

1. Alice, who is a Warpcast user, also decides to start using Foocaster.
2. Alice imports her custody address via its seed phrase into the Foocaster.
3. Foocaster backend asks the DC server for a nonce and timestamp.
4. Foocastee backend asks its client that Alice is using to sign the auth message with her custody address.
5. Foocaster backend delivers this signature to the DC server which returns a secret token.
6. Foocaster backend uses the secret token to auth HTTP requests and fetch Alice’s inbox.
7. Foocaster also opens websocket connections to stream in new messages.

Security

• Rate limits — the server will implement per user and possibly per app rate limits to protect against accidental or intentional DDOS attacks.

• Encryption at rest — messages are encrypted at rest on the dc server to protect against a compromise of the database or its backups.

• ECDSA authentication — access to messages requires authentication from the user controlled ECDSA keypair which prevents any app from getting access to direct messages without explicit permission from the user’s device.

• Allowlisted access — access to the DC server will be allowlisted in 2025. this prevents a malicious app from tricking a user into importing their seed phrase and then being able to access all their group chat messages. we plan to open this up in 2026.

Rationale

Why not users signers to fetch messages?

Existing signers cannot be used since users have already authorized many without the expectation that they can read private messages. A new class of signer could be introduced but we propose using custody addresses and [auth addresses](#225) instead since they are more likely to be treated securely by users.

Why is this not end-to-end encrypted?

Adding end to end encryption slows down the pace at which we can ship features and makes some features quite challenging or impossible to build. The large feature gap between telegram and signal is indicative of this challenge, and the majority of farcaster users have indicated that they want to prioritize usability and crypto forward features over end-to-end encryption.

Why is this not decentralized?

Decentralized messaging requires a network of servers and would require e2e encryption to be implemented first. It’s not a priority for most users relative to interoperability and programmability.

Release

• The initial version (v0) of the DC server will implement most of this specification and be embedded in Warpcast’s backend. This will likely ship in April or May 2025.

• The next version (v1) will have a standalone server and will likely ship closer to the end of 2025.

[zingerj]

Small typo in title FYI ("Auth Addresses")

[nounder]

A suggestion that metadata keys should use hyphen instead of space, like so:

Chain-ID: 1
Issued-At: 2021-09-30T16:25:24Z

PGP, HTTP, MIME follow same convention. Reason being that these symbols are often hardcoded in a source code where string whitespace can cause subtle bugs.

[SamuelLHuber]

Will the API endpoints be similar to the existing Warpcast specific API Spec?

[varunsrin]

Will share more details soon, there will be some changes due to the auth mechanism changes.

[i001962]

https://warpcast.com/kmacb.eth/0x2f756727

[andrei0x309]

It techincally looks good, probably the allowlist is the only thing that is proposterous, there's no reason to have that because if users sign willy nilly with custody account, then they can lose the account itself very easy, anyone can make such a malicious page today to lose the account if you just sign anything.

Which means the allowlist is not justified, it doesn't make sense, the allowlist represents just bad optics, it should be completely open from the start to better measure the demand, because it makes sense to not decentralize the compute of DC if there is low demand anyway.

Allowlists are what kill any kind of "WEB3" vibes, I mean you put a wallet in the app, enabled by default, but you expect that people can be easily tricked, even if the allowlist will be eventually removed, then what's the sense to have it in the first place? Will the users be 3x times wiser after a year?

The allowlist logic is just flawed.

[andrei0x309]

@cboscolo
Pretty much, a whitelist won't prevent malicious actors, we don't even know the mechanism of enforceability, other whitelists in the past were pretty easy to bypass by either spoofing or using Warpcast infra.

The bottom line without proper justification whitelists represent just gating and bad optics. I fail to understand why a whitelist is useful anyone can look at the dev call and discussion here and decide for themself if proper justification was provided, IMO not at all.

[cboscolo]

Got it. I agree on the whitelist point. (seems like unnecessary additional work to me, but I don't pay the bills at Merkle.)

I'm also trying to raise awareness to Varun's original point that that different clients may have different privacy implementations. For example, a client distributed in the UK may be forced to allow backdoor access to messages. We can kick this can down the road, but I think it would be helpful to at least give it some considerations now.

[varunsrin]

I'm also trying to raise awareness to Varun's original point that that different clients may have different privacy implementations. For example, a client distributed in the UK may be forced to allow backdoor access to messages. We can kick this can down the road, but I think it would be helpful to at least give it some considerations now.

One approach is similar to email - assume no expectation of privacy and just say everyone is allowed to integrate, but your group chat's security is only as good as the weakest member, and there's no real way for you to audit it.

The other approach is more like a consortium - say that the direct cast protocol is a consortium of people who commit to strong security/privacy guarantees and that the user does not have to underwrite each person they correspond with as long as they are using the direct cast system.

It's not clear which side we should land on, and it has important implications for things like end to end encryption. How useful is end to end encryption if you can't really know whether the app on the other side has implemented it correctly or is snooping on your messages?

[cboscolo]

fwiw, Signal is considered the gold standard for e2ee and there is no guarantee that everyone in a Signal group chat is using an official Signal client. (eg. a couple years ago we used to distribute a Signal client that had a feature to lookup users via ENS.) The reality is that it is extremely difficult to enforce clients without gate-keeping access to the network, which is basically what a consortium approach would end up doing. Who is going to police the consortium members to ensure they don't build clients that violate some set of privacy standards?

Ultimately, for small groups or DMs, it boils down to human trust. For large groups, I think any privacy assumptions are already tenuous. This wouldn't be any worse than Telegram...

If you assume that the humans in a group are trust-worthy, and that this trust extends to them choosing to use clients that are honest actors, then the best approach is for each client to declare what it's privacy stance is (or uses a user agent as a proxy for this). This way, using my earlier example, if the counter party you are messaging with is using a client that must adhere to the UK Gov rules, you have agency on how you want to proceed.

[andrei0x309]

@cboscolo

Pretty much nailed it, E2E is mainly useful in 1-to-1 chats, for large groups especially you must be naive to assume that you have any privacy guarantees. I pretty much typed this in the dev call, this is another reason why whitelists don't make sense.

Large groups where people are invited randomly should be considered public, even if they work based on invitation.

[manan19]

Foocaster backend delivers this signature to the DC server which returns a secret token.

Does the token expire and need to be renewed periodically? Would renewals require a signature from the custody address's seed phrase? Asking to confirm how long Foocaster needs access to the imported custody seed phrase for.

Alice imports her custody address via its seed phrase into the Foocaster.

Is this the only mechanism or will a deeplink based signed message from Warpcast also be supported?

[vrypan]

I read the discussion and it seems to me that each person is talking about this FIP having their own use case in mind and each case has very different security profiles and expectations.

• 1-1 DCs between two trusted parties, that expect E2EE and an 100% open protocol.
• Open, join-my-token-lanch-tg-style groups with 100s or 1000s of participants, and zero privacy expectation.
• The small group of 10 or 20 friends or parents from your kid's school, that exchange photos, trust each other, but don't want in any way any other party (ex. friend of a friend, or the server hosting the conversations) to have access to their messages.
• Probably many other cases, such as business chat, flirting, etc.

What are we trying to solve? There is no way to agree, unless the top use case is clearly defined. There is no gold standard for all of them together.