FIP: Flexible mentions

[pmohun]

Originally proposed on Farcaster.

tl;dr: Extend mentions to include arbitrary strings instead of just FIDs

Problem

FIP-2 enables users to create threads around topics by setting the parent_url to arbitrary strings, including URLs and NFT contracts. However, if the root cast doesn't specify a parent topic, the thread is forever excluded from the topic discussion.

In other cases, a thread may start around one topic but subsequent replies may veer into other topics.

Proposal

The CastAddBody message should be extended to store non-FID values in the mentions array. Specifically, we should modify check #5 of the CastAddBody validations:

// Current
m.data.body.mentions must contain between 0 and 10 256-bit integer values.

// Proposed
m.data.body.mentions must contain between 0 and 10 values, each of which are either 256-bit integers or valid UTF8 strings whose length is >=1 byte and <= 256bytes.

Use Cases

• Citations: casts can "cite" URLs to provide factual support for claims. This also has the nice property of aggregating mentions of a URL into an open data format, creating an internet-scale repository of relevant discussions.
• Multi-channel threads: threads can reference multiple channels, either by setting a channel URI as a root parent_url or mentioning a channel URI within the thread. This would allow for e.g. History x Memes threads that could be surfaced in either channel depending on the client implementation.

Client Considerations

To differentiate from FID mentions, clients may want to consider using the # for non-FID mentions. This is similar to hashtags on Twitter, but could be stylized to prevent displaying the full-link.

[dylsteck]

Thanks for putting this together Phil -- I think it could be a great way to extend FIP-2. I especially like the idea of using @ to mention FIDs/Fnames and # to reference URLs/smart contracts(similar to how references work in some note taking apps).

I think it's also worth considering what happens when two users reply to or mention different targets that have similar contents(eg. user A mentions a NYT article about an event and user B mentions a Washington Post article about the same event). If part of the use case for this FIP is to better link similar content, then a solution for this problem might be worth adding to the FIP as well.

[varunsrin]

One challenge with this design is that it significantly increases the max size of a cast.

• Today, mentions can be at most 160 bytes (5 * 32). This takes up about 10% of the total size of a cast today.
• With this proposal, mentions can be at most 2560 bytes (10 * 256). This would take up about 200% of the size of a cast today.

This means malicious actors could more easily take up space on hubs by issuing junk data full of junk mentions. So to fix this, we'd have to cut the cast limits for regular users from 5k per storage unit to 2k (~ 1/3rd).

In general adding more data to a cast will come with the tradeoff that we then have to reduce the number of casts available to users for a storage unit. I wonder if there is a way to achieve this design with a much smaller footprint.

[pmohun]

Good point.

Here are two potential solutions:
1. Reduce the maximum number of string mentions from 10 -> 5, which is probably fine for most users. I use Balaji as the example, since he is militant about citations in his tweets. Examples 1, 2, 3. This cuts the mentions storage to a maximum of 100% of the current cast size.
2. Reduce the maximum size of the string from 256 bytes to something smaller. The first time a link is mentioned we probably need to incur the maximum penalty for storage, but there's no reason future casts referencing the same link also need to store the full string, which would allow us to cut the storage limit. Instead, we could use a pointer system based on a hash of the URL.

[varunsrin]

Couple of high level thoughts :

• Mentions as a means to include topics seems useful, though we need to find a way to implement it that wouldn't significantly reduce user's storage.

• Mentions as a means for citations seems much less important because you can just use the embeds field for this, or if you don't want them expanded you can include them in the text body. So there's already a reasonably way to achieve this for a few links.

[varunsrin]

Two other points:

1. We want to add at most ~5% to max cast size or around 80 bytes. Anything larger and we'd have to and reduce storage limits for users which isn't ideal given that people have started acquiring storage and have expectations around what they're getting.

2. There's no way to enforce hash based encoding at the protocol level - most clients will just not implement it if they don't have to, and we're back to urls being full size again.

[varunsrin]

Closing due to inactivity