Brainstorming: Links, badges and other relationship types

[vrypan]

The following is triggered by a request to have some kind of badges that has been expressed in many occasions. I also think that Links can be used (or even extended) to express more relation types than "follow".

Treating badges as relationships.

A badge is a relationship between two entities. One entity offers the badge, and an other entity has to accept it in some way.

Using Links to express badges

One way to express this relationship on Snapchain, would be for

• FID1 creates a Link message with type="badge" and target_fid=FID2
• FID2 creates a Link message with type="accbadge" (accept badge) and target_fid=FID1

A client can represent this relationship as a badge, using FID1.USER_DATA_TYPE_PFP on the profile page of FID2.

This approach is simple, in the sense that it does not require changes to the protocol. It should also work with LinkCompactStateBody without changes.

The limitation is that each badge requires a separate FID that offers it. So if Farcaster wanted to offer two badges, for Pro and ProMax, each one of the badges would have to be offered by a separate FID.

However, many existing groups and teams on Farcaster could use this from day one. For example, Purple could offer a badge to all Purple holders, and update the badge status whenever the NFT is transferred.

Possible extensions

(less-than-half-baked ideas, that may or may not be applicable)

• Instead of type=badge, treat any type=badge* as a badge. This would allow a single FID to offer multiple badges, as badgepro, badgepro2, etc. But they will all have to be presented using the same icon (FID1.USER_DATA_TYPE_PFP)
• Extend the Link message to include an icon property that contains the URL of the badge. This can be very tricky, and increase storage requirements, sharing it in case it triggers more ideas.
• Alternative way to express multiple badges from a single FID: Interpret Link.type as type=badge<index> and introduce a new USER_DATA_TYPE_BADGES that accepts a list of image URLs.

[sanjayprabhu]

I'm not sure we should overload Links, esp. if the user has to "accept" the badge. This actually feels similar to open ended attestations instead of the fixed ones we currently have with #199.

One of the options we considered for attestations is to have it's own datatype (like Links or Verifications). With that you could do the required "counter-signature" from the fid providing the attesation/badge within the body of the same message.

[vrypan]

If badges are actually used, I expect users to add/remove them frequently (especially for things that are trending one day and are not so cool after a couple of days).

A separate datatype sounds great. (Over the last couple of years, I have developed this fear of suggesting anything that might require protocol changes, even if it makes sense, but that's a different discussion.) What would it look like?

[vrypan]

BTW, badges are not just for flexing/vibes. They can be used as attestations (so, you are right about approaching it as an attestation), that someone is for example, a member of a team: For example, @user123 reached out to me, and I can see that they are part of the Coinbase team, because they have the coinbase team badge, provided by the coinbase account.

[sanjayprabhu]

I think attestations as a fundamental protocol primitive makes sense. We could then have a new UserDataAdd type of BADGES which is an array of upto n attestations to show on your profile.

[vrypan]

The problem is that the current system allows attestations coming from FIDs that I have approved an appkey for. That's too restrictive for many (most?) use cases. Every miniapp for example, should be able to offer me a badge (supporter attestation, or top user attestation or top score attestation) without an appkey. Unless they work just like other messages, for example links or reactions.