Farcaster Hubs as an Events Buffer for Social Applications #88
Replies: 5 comments 8 replies
-
|
Another pro to this approach is that the Application registry can be deployed to all kinds of L1s, L2s, or some future implementation of some distributed ledger without forcing a user migration. |
Beta Was this translation helpful? Give feedback.
-
|
Also, bots should be registered as applications, and distinguished from users. |
Beta Was this translation helpful? Give feedback.
-
|
a self-attestation for "automated account" would be a nice addition. is this what you were thinking of in terms of a solution? |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for writing this up - lots of great suggestions in here with different tradeoffs, so let me try to break them down and address them individually.
This is a great idea, and there are two ways we can do this. One is to have a distinct on-chain registry and the other is to just require each app to have an fid and a special message in its USER_DATA identifying it as an application. The former gives us a lot more flexibility in terms of charging fees the latter is simple and composable with the existing system.
Doing this at the message level might be tedious (2-way signing is just annoying in practice) but you have apps and users both co-sign the creation of a signer, and then you can assume that all messages from that signer came from the app and the user.
We've thought a lot about this, and its quite hard to do in practice. The purely off-chain approach doesn't work because how does a user know they can move an identify from one app to another? The multi-chain approach is appealing, but now applications must sync with N different blockchains to know the actual state of users. This is actually quite tedious in practice and there are lot of state management complexities both for hubs and applications. A much better approach is to have a singleton registry on a blockchain. |
Beta Was this translation helpful? Give feedback.
-
|
very supportive of that top-level goal, i've written down some thoughts about that here: https://hackmd.io/@farcasterxyz/Hyyt7NFb2 curious if you agree directionally with the proposed approaches |
Beta Was this translation helpful? Give feedback.
-
|
Also greatly supportive of that top level goal, and agree that the protocol seems like it might have to work pro-actively to materialize it, given what we're observing with the current client diversity. I think that your thinking is going in the right direction, and can be pushed.
I am pretty convinced that the vertex between two nodes (a node is a user, a vertex is a relationship, like "follow" or "amp"), is the key thing to get right, but I don't have a clear picture on what the solution space looks like for alternatives that support this. @varunsrin your article is right on the money. I got excited reading it!
I prefer "extendible" schemas that are simple, rather than flexible.
I think that it's one of the options but an another is a data referencing protocol, which decouples the storage from the protocol entirely.
I have some more thoughts about this, and working on something. |
Beta Was this translation helpful? Give feedback.
-
How about a system where the protocol auctions off blocks of FIDs to known apps to distribute? Like how ICANN or regional internet registries assign IP address blocks. Can elaborate on implementation if this sounds interesting ... |
Beta Was this translation helpful? Give feedback.
-
|
High level response is that if we make FID registration open on L1 (which we plan to by fall) then the auctioning blocks seems unnecessary? Anyone can just register directly with the blockchain. If I'm misunderstanding the proposal, an elaboration would be helpful |
Beta Was this translation helpful? Give feedback.
-
|
Social applications require existing users to invite new users for growth. Asking a new user to pay for something upfront is a non-trivial deterrent for growth. A lot of times, bursts of sign-ups can be attributed to momentary viral events and targeted marketing campaigns ... during these moments if it takes up to $20 for users to register an FID to onboard (variance due to gas price fluctuation), this will spell doom for a social application that might have worked. Also, popular consumer applications like Uber, Coinbase, etc. all implement growth strategies providing new user incentives. To date, I have yet to find a social app requiring paid-sign ups to reach meaningful network effects, so putting the cost of FID registration on the user seems very counterintuitive to me. Based on some quick stats from https://farcaster.network/, we can see that out of ~13k sign-ups, there are about ~3000 monthly active users. So around 1 out of 4 users who signed up to Warpcast really need an FID. Instead of having "anyone" register for FIDs on an L1, we should allow applications to purchase FIDs in blocks, and abstract away FID registration in a manner where
If we allow applications to bid on blocks of FIDs, applications can come up with their own FID distribution strategies. FID registration can be handled in the following ways:
|
Beta Was this translation helpful? Give feedback.
-
General feedbackI agree with the some things, but not all. I would frame it as: I think that it might be worth spending more time on the actual requirements, and then separate out the proposals (solutions) cleanly. Specifics
I disagree with this. I think that farcaster at its core is a social protocol, and shouldn't move away from that. What should happen is that it should become extendable in a way that you don't necessarily post "casts", but you can post "richCasts", and there should be ways for people to permissionlessly create a new richCast type (like Then, clients can chose which types they filter. You could have an app that filters only blob stuff, one that mixes text events and strava-like events, etc... Before this can happen though, I think there needs to be a better answer around the following graph, and if this is scoped to an application (like the ones you are thinking about with your registry) or global.
This sounds interesting and I need to think more about it. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for your feedback! I do realize the framing was a bit sporadic, so I gave it another try here: Based on the discussions here #85. It seems too early to decide on which social primitive the protocol should enforce:
(not on the team, my two cents aren't worth much here) Wanted to offer a different perspective on how we can look at the protocol, and perhaps come up with designs to place the protocol to support applications better :) |
Beta Was this translation helpful? Give feedback.
-
|
Application identifiers were proposed and merged as part of FIP-7, which addresses a large part of this proposal: #103 Thanks for starting the discussion around this @michaelhly! |
Beta Was this translation helpful? Give feedback.
-
Problem
Traditionally, application content and events exist within walled garden social platforms. For instance, a user’s achievements on Strava are by-default inaccessible to other social apps like Instagram and Twitter. In order to make user events or content available across applications, sharing functionality must be exposed through application-specific APIs or SDKs. Here are some examples:
Consuming developers must then install dependencies within their applications to enable users to publish content to each social platform. These SDKs may be poorly maintained [1][2], and in more extreme cases, these APIs can be shut off completely and break the developer’s application.
Farcaster renders this frustrating experience unnecessary; application events and content can be published and become easily accessible from Hubs.
However, a problem exists within the Farcaster ecosystem today. Most applications in the Farcaster ecosystem are first built with Warpcast APIs instead of Hub APIs. Warpcast APIs are very opinionated and specifically designed toward supporting a Twitter-like application and primarily serves a community of crypto/web3 enthusiasts. Applications in the Farcaster ecosystem all share one primary feature — allow users to publish tweet-like data to a
primary/masterdistributed data store and surface tweet-like content based on differing client logic.Motivation
To facilitate an ecosystem of diverse applications, applications must migrate off of Warpcast APIs. But to a further extent, the Farcaster “protocol” should be less opinionated and allow application developers to focus on developing “social” experiences for their users. For example, application developers should have the degree of freedom to choose if:
Stewards of the Farcaster protocol should focus on alleviating developers from writing + maintaining application-specific external APIs and SDKs. Farcaster, the protocol, should start off functioning more like a generic events buffer without imposing social primitives onto applications. Applications should also be encouraged to publish all kinds of content to Farcaster Hubs without affecting the user experience of another application.
Clients who wish to support content published by certain applications should read from hubs, verify that the published message was signed by an application against a cryptographic proof, and surface the message in their application appropriately.
Example:
Warpcast can also decide it does not like messages produced by the Blobs application and by default opt out of messages generated by Blobs and other unknown applications.
Proposal
2. Move FIDs off-chain- User identifiers should be moved off-chain but applications should still agree on a canonical standard for user identificationBeta Was this translation helpful? Give feedback.
All reactions