What is /farcodes

Farcodes is a new set of frames to help you share your referral codes, and find your friend's codes - all in a way that reduces spam on your feed. You can try it out right now at the /farcodes channel.

Firstly find a referral program that's supported so far, you can find an exhaustive list in the /farcodes channel. For example you can try out the Uber Eats program here and paste the code from https://www.ubereats.com/invite.

And that's it! Your code is now logged in Farcodes. Now when a friend of yours - or even a complete stranger goes to find a referral code for Uber Eats, they might just see yours!

People typically only need one referral code from any given program, so whose codes get shown first? When you try to redeem a code farcodes will:

1. Try to find a referral code from one of your mutuals and show that

2. Otherwise, try to find a referral code from someone you follow

3. Otherwise, promote a referral code from anyone hopefully ordered in a way that promotes equitable access to referrals.

There's a lot of programs I need to add, so for the next while I'll just be adding them in daily. Make sure you follow the /farcodes channel or me for updates on programs as they stream in!

Which is great for Warpcast and not so great for everyone else. This isn't the end of the world, Warpcast deserve all the success in the world, but it would be better if there was a client agnostic way of prompting for a cast. There's some options that could be considered at the protocol level.

One approach could be supporting a new compose action type in frames. I.e. a frame implementor would nominate a button as a compose prompt, clicking the button would tell the client to begin composing a cast with the format text in the target.

<meta property="fc:frame:button:1:action" content="compose" />
<meta property="fc:frame:button:1:target" content="Sample text you want to prompt the user to share" />

This probably isn't the worst idea in the world, but the problem with this approach is it presupposes that the client that's showing the frame has permission to, or wants to cast on the user's behalf. I.e. this works for supercast.xyz but doesn't work for farcasteruserstats.com say.

If the client has to delegate that responsibility, then we're back to them just firing off to https://warpcast.com/~/compose?text=Blah

There's currently (afaik) only two Farcaster scheme URLs supported widely right now. farcaster://connect?channelToken={Token}&nonce={Nonce}&siweUri={Uri}&domain={Domain} and farcaster://fid/123.

We could introduce another one which matches the Warpcast scheme: farcaster://connect?text=Blah&embeds[]=google.com

This should probably be done too, but relying entirely on this would have it's downsides too. mailto:// works because there's very few contexts when it comes to email; basically just work or personal email.

But when it comes to Farcaster, in the not so distant future I might very well have a client for general posting, one for movie reviews, one for gaming, one for work, one for board games, and so on. I.e. farcaster://connect is a good idea, but always delegating to that will centralize too.

If you agree with the above, then I think the honest solution is that there needs to be some interpretation of user preferences at the application layer. This is not going to be easy going forward, and it's just won't be reasonable for individual frame developers or even SME-like Farcaster clients to build that infrastructure.

As time goes on it will get exponentially harder to support all the clients for all the primary Farcaster verbs (like compose), which will mean that we'll get pareto quickly via most implementers only supporting a "Compose via Warpcast" and "Compose via Supercast" etc. but not "Compose via App that was built 2 days ago".

It is also not reasonable to expect a frame developer, or a read-only client developer to know the user's preferences. These preferences might not be publicly inferable. You might for instance be able to infer that a user prefers to compose casts through Warpcast because their messages are usually signed by Warpcast. However, in the future it's more likely most apps will sign through some third party like Neynar which obfuscates the origin. Additionally if we find ourselves in a world where users self sign messages more frequently, (i.e. via self hosted applications) then we won't be able to infer this publicly.

Finally there are some user preferences that are just only knowable by the user. For instance, if I'm prompted to post a cast via a frame I saw in Warpcast, I might want to override and instead cast that via Supercast.

I've spent the last couple days building out https://composecast.xyz which I think is a good enough option for now to replace https://warpcast.com/~/compose links.

ComposeCast.xyz is fully MIT licensed and available here: https://github.com/0xSemicolon/composecastxyz. Feel free to self host it, add as a subdomain like compose.yourdomain.com and so on.

User preferences are stored on device only via IndexedDB. There is no backend and the application is purely static. This should mean it can survive for a while with no support. The configurations are Automerge CRDTs so in the future - with a bit more work - they could be synced via File Access APIs.

If you're already sending users to https://warpcast.com/~/compose?text=Blah&embeds[]=google.com you can update the URL to https://composecast.xyz?text=Blah&embeds[]=google.com.

In lieu of any information about a user's preferences, the clients presented to the user are randomized every session. As more clients get added this might need to be addressed but for now I think this is the fairest option.

When a user composes a cast through this platform they can nominate it as a preferred / starred client. On future sessions it will render as starred always at the top of the stack.

When the document.referrer or the query param referrer is a well known URL composecast.xyz will automatically pop up the client being referenced. Users can additionally set to automatically redirect so that after the first use composecast.xyz will disappear when being used by that application.

Also the client being referred will be prioritized in the list and very clearly highlighted.

If the developer who is creating the link has a preference of client that should be used for the post then they can nominate the clients they would prefer the user pick from via preferred[] query parameters.

For example, if a frame developer knows that only supercast.xyz and warpcast.com support a feature they need for the cast to be posted (maybe video, improved UI for some other primitive) then they can nominate them

1. document.referrer works but won't be present for most use cases, will probably need a composecast.xyz frame to get that working properly. In the interim clients could intercept composecast.xyz links and attach a referrer query param (or just go straight to their compose screen if they don't need to respect user preference).

2. This should really be a PWA and I haven't set that up yet, there's also a set of performance tweaks to do.

First of all thanks for getting this far. If you are you building a farcaster client, or you know someone who is, or you want to contribute, or you're just interested in this problem please DM me on FC and lets get it supported on composecast.xyz. Additionally PRs are open so have a go!

Long term we just need to support more clients. At the moment there's 5 clients supported, but only 1 of them actually supports instant fulfilment because only 1 actually has a /compose like route that accepts query params.

What I'd like to get done this year:

1. Double digit % of all farcaster clients supported

2. Self hosted clients supported

3. Neynar option added

4. Import / export preference configuration via file system access APIs

5. Frame to get document.referrer working in most cases

👋

There's currently no way of showing a dynamic experience in a frame without a user interacting with a frame. You could push details about the user in the first get, but it would make frames less indexable, and could leak session data without permission.

The idea is to add a new meta tag fc:frame:status which indicates the "status" that will be shown if a condition is met. Here's an example:

<meta property="fc:frame:status:✅" content="ERC721:0x123...:*" />

This would indicate that the frame for the current user should receive the status ✅ if the user has any ERC-721 from the supplied contract.

Another condition could be an individual token, ERC721:0x123...:1 or a range of tokens ERC721:0x123...:1-2,4-5. The client can then indicate on the frame that the status has been achieved. For example, Warpcast might choose to display the status this way:

Additionally, it might be useful to add additional metadata that could drive how certain states are interpreted by the client, for instance indicating which image should be displayed if a status has been achieved.

<meta property="fc:frame:status:✅:image" content="https://..." />

Unlike the first option this could leak some amount of information to the website, e.g. if I sent someone.eth the NFT 0x123...:1 and I was tracking views to the image specifically crafted for that NFT I would know at what point in time they saw the cast (or at least when a client claimed to have shown it). This might be something privacy focused users opt out of.

2) Why

1. Helps indicate state without having to interact with the frame:

   1. Check if I still have my tamagotchi 👾, does it need cleaning 💩 or is it dead 💀

   2. Have I already won 👑 or lost 😭 the game someone started with me

   3. Am I currently holding the hot potato or has it exploded 💣

   4. Have I already completed this task ✅ (Mint, Survey, whatever - i.e. POAP)

2. Think Frame Friday showed how creative people can be, these are just some ideas but I'm sure smart people could come up with a million more.

3. Might help frame spam, i.e. I can see on the frame I've successfully interacted with the frame that minted the token.

4. There's even space for some real-time component to this in the far future, e.g. if the client is listening for changes to the user's NFT wallet both the utf-8 icon statuses and even the images could be updated accordingly.

5. It's extensible I've so far only discussed the condition name ERC721, however clients could converge on other conditions such as Liked:<Cast>, Retweeted:<Cast> etc.