Every protocol has it's own URI scheme. It's the map to navigate the protocol's resources.
For example you know that web URIs start with http:// or https:// And when you click a "link" (i.e. an HTTP URI) in an application (such as an email client or a PDF viewer), your operating system knows that there is a certaing application that can handle this URI: your browser.
On the other hand, if you click on an ftp:// URI, an other application may open up -or maybe your browser again, depending on your configuration.
Well-defined protocols come with well defined URI "schemes", i.e. a very specific syntax that a URI must follow. For example, after https:// comes the server name or its IP, and then a "path". So, when an application reads https://test.com/demo/1.html it knows that it should connect to the server test_dot_com and use the HTTP protocol to request the page /demo/1.html.
One of the nice things with protocol URIs is that they do not depend on the specific application you use. You can switch your default browser, or install a new ftp client and they will still work -they will just open in a different app.
At the moment, we don't have a well-defined URI scheme for Farcaster.
As a result, when a user wants to link to their Farcaster profile, they use the URI provided by a specific client, usually Warpcast -something like https://warpcast.com/vrypan.eth. When they want to share a link to a cast, they use again the URI provided by a client, like https://warpcast.com/vrypan.eth/0x7fb548. Similarly, if you click on the share button at the end of this post, you will open a link that looks like https://warpcast.com/~/compose?embeds...
All of the above work. But they create an unhealthy ecosystem:
First of all, the dominant client (Warpcast at the moment) is not only favoured, but also creates a moat around it. If every Farcaster-related interaction points to warpcast.com, most probably, this will be your client.
We also rely on an infrastructure we (as a community) don't control and we shouldn't have to, like DNS. If Warpcast (or any other client) lost their domain next year, all these links would break.
We introduce a centralisation vector: If everyone uses a specific web client to point to Farcaster resources (casts, profiles, etc.), if the client is forced to censor some of them, this will affect (in practice) the whole ecosystem.
The solution is to define a farcaster:// URI scheme that any farcaster client can implement. This would allow us to link to farcaster resources using URIs like
farcaster://user/vrypan.ethfarcaster://cast/vrypan.eth/0x7fb548
and they would trigger your farcaster client to jump to the specified resource, just like clicking a mailto: URI opens your email client or an http:// URI opens your browser at the specific address.
These URIs don't depend on, or favour any, specific client or site. They don't even need DNS to work. They only require farcaster clients and farcaster hubs.
If you are a developer, please check out the corresponding FIP. It will take some serious brain power and expertise to define something that is both useful and elegant and will be able to withstand the test of time. Your comments are needed.
If you are an end-user, you can advocate for the need of a farcaster: URI scheme.
Note: There is a long, decades-old, discussion about URIs (Uniform Resource Identifiers) vs URLs (Uniform Resource Locators). I decided to use the term URI in this article. If you're into these things, feel free to mentally replace URI with URL wherever you think it's appropriate :-)
- Loading comments...