There's a low impact (for now) centralizing force in the Farcaster ecosystem. I had this realization when building the https://far.date frame recently - a good number of frames need to be able to prompt a user to make a cast. Additionally many Farcaster ecosystem applications/clients are read-only by design. The only way for these applications and frames to write a cast is by sending the user to: https://warpcast.com/~/compose?text=Blah
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
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).
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:
Double digit % of all farcaster clients supported
Self hosted clients supported
Neynar option added
Import / export preference configuration via file system access APIs
Frame to get document.referrer working in most cases
👋
<100 subscribers
