FIP: External cast data #171
Replies: 21 comments 91 replies
-
|
Hey @vrypan! I was going to write up a similar FIP along with Steve that suggested long casts be managed through an extension of the embeds array and uses IPFS protocol URIs. We'd like to throw our support behind this or something like it. Couple of questions for you that came up in our own internal discussions:
An alternative we talked through is less flexible but likely more performant: extend the embed array specifically for long casts and instead of pointing to a metadata file, you point directly to the long text content. Makes it as easy to render as it is to render images and videos today. Again, the big tradeoff is flexibility. Would love to hear your thoughts. |
Beta Was this translation helpful? Give feedback.
-
|
I suggested we follow the ERC-721 Metadata scheme for a number of reasons:
In case of long casts, this is a single request: Fetch the JSON and use The additional benefit of not using plain text URIs is that down the road we can have application-specific metadata. For example, events can finally get a timestamp property that lets clients present the event date in my local date/time. And I'm sure there are much more creative uses. |
Beta Was this translation helpful? Give feedback.
-
|
If client devs are OK with it, it would be great to implement the Enjin metadata suggestions, and let app/content devs go wild :-) |
Beta Was this translation helpful? Give feedback.
-
|
BTW, it also makes it so easy to mint this content as an NFT :-) Using something that's already widely used comes with a lot of benefits. |
Beta Was this translation helpful? Give feedback.
-
|
This makes a lot of sense. I like just having the text in the description field. How would a client know, though, if they are rendering an NFT and need the name/image fields vs rendering a long text where they just need the description? |
Beta Was this translation helpful? Give feedback.
-
|
They already know in advance. They fetch this URI because it was in a cast embed, not because it was the result of a |
Beta Was this translation helpful? Give feedback.
-
|
The metadata target is interesting. This could be done without a protocol change by following the frames playbook and just having a url include meta tag specifying |
Beta Was this translation helpful? Give feedback.
-
|
Maybe I'm not understanding the frames solutions, so correct me if I'm wrong. But it would look like:
Is that right? |
Beta Was this translation helpful? Give feedback.
-
|
Mostly right but there's no need for anything frame here:
This reason I mentioned frames is they follow a similar pattern to accomplish inject more complex, off protocol content into a cast:
This being said I'm a fan of the idea of using |
Beta Was this translation helpful? Give feedback.
-
|
Makes total sense. And I like the metadata prefix as well. The OG tag is a great alternative, but agree with the messiness of parsing HTML. Ideally, there is full client support for handling protocol URIs like |
Beta Was this translation helpful? Give feedback.
-
|
@deodad On the other hand, I would see this FIP as a way to support json frames at some point in the future. :-) Also, if we end up using a |
Beta Was this translation helpful? Give feedback.
-
yup :) |
Beta Was this translation helpful? Give feedback.
-
|
product UX questions:
|
Beta Was this translation helpful? Give feedback.
-
|
Mostly up to client devs to answer these. For v1, I would go with simple markdown which is readable even if rendered as text:
No, but I guess it's easy to create a md extension that will render @ mentions as links, and suggest that clients treat them as mentions when it comes to clicking on them. When posting, a smart client could parse the long cast text, identify mentions and put them in CastAddBody mentions.
I think no. But clients could render the
Markdown for v1. Would adding a spec version filed in the json schema make this more future proof? |
Beta Was this translation helpful? Give feedback.
-
|
@vrypan re: technical implementation - in simple terms the proposal is to have a pointer inside a cast on Hubble that points to something off Hubble. Could we point to a JSON representation of CastAddBody message but without the data size limitation on text?
It'd literally be a "Long" Cast. |
Beta Was this translation helpful? Give feedback.
-
|
Inception :-) And then long casts could embed other long casts that embed other long casts or frames. There's no reason to add so much complexity, IMHO. This was the reason markdown was removed, following @deodad's suggestion to keep it simple for v1. Also, CastAddBody is OK for long casts, but it will not allow us to extend it to support for example json frames. Or, I don't know, calendar events. The idea is to have something minimal that will allow long casts, but it can also be extended to support other types of data in the future. |
Beta Was this translation helpful? Give feedback.
-
|
My initial thoughts:
I'd prefer it if we support clients to treat the content of the URL as an HTTP message with its own header (including Content-Type) and body section. All languages have ways to handle HTTP messages. For long casts particularly, clients could support This will be the simplest and most future proof approach IMO, after all, it's HTTP. The OG. |
Beta Was this translation helpful? Give feedback.
-
If you fetch the IPFS content from a gateway, you will get a content type header back. There are some outlier cases where I've seen it not match the actual file, but for most cases, it will be accurate. |
Beta Was this translation helpful? Give feedback.
-
|
To make things clearer I added support for this to the client I'm prototyping: That points to this cast: Which points to this file on IPFS: This is example go code I used to parse the body as HTTP method and return the markdown content if the func fetchMarkdown(url string) (string, error) {
resp, err := http.Get(url)
if err != nil {
return nil, fmt.Errorf("Failed to fetch URL %s: %v", url, err)
}
defer resp.Body.Close()
if resp.StatusCode != http.StatusOK {
return nil, fmt.Errorf("Non-OK HTTP status code %d received for URL %s", resp.StatusCode, url)
}
bodyBytes, err := io.ReadAll(resp.Body)
if err != nil {
return nil, err
}
tp := textproto.NewReader(bufio.NewReader(bytes.NewReader(bodyBytes)))
mimeHeader, err := tp.ReadMIMEHeader()
if err != nil {
return nil, fmt.Errorf("Failed to read MIME header for URL %s: %v", url, err)
}
contentType := mimeHeader.Get("Content-Type")
if contentType == "text/markdown" {
bodyContent, _ := io.ReadAll(tp.R)
return string(bodyContent), nil
} else {
return nil, fmt.Errorf("URL %s has non-markdown content type: %s", url, contentType)
}
} |
Beta Was this translation helpful? Give feedback.
-
|
I'm personally a big fan of this approach that relies on the mimeType of the linked content (vs structured JSON) for multiple reasons:
|
Beta Was this translation helpful? Give feedback.
-
|
Thank you for your detailed thoughts supporting my approach :) You expressed clearly why I rather us adopt HTTP message format vs JSON metadata. This is a protocol and as such we should adopt a most efficient and future proof way of doing things. |
Beta Was this translation helpful? Give feedback.
-
|
Every once in I get some coherent sentences out there - glad they went to a good cause this time!
yepp - for better and worse 🙃 All the more why I like the potential of this being "just" URLs - so much less to adopt. And practically speaking, people are going to try linking long form content regardless (if they haven't already) |
Beta Was this translation helpful? Give feedback.
-
|
I like @deodad idea of doing something similar to what frames does. But can we expand this to support any kind of long files? It will depend on clients what to render and can potentially allow the creation of many interesting use cases. For instance: A user shares an embed link. It returns a set of defined meta tags: I like @gabrielayuso idea of the So, let's say Warpcast wants to integrate long texts. A user starts typing, and once they reach the max characters, a message is displayed saying, "Your cast is longer than normal, Warpcast will show it but other clients may not display it properly." When the user is done typing, they cast, and the client should handle uploading that content to an external resource, getting the URI, and embedding it. Cooler clients can even use the allowed cast characters for mentions and other embeds. |
Beta Was this translation helpful? Give feedback.
-
|
It's HTTP... it's flexible. For long text, Also, parsing HTTP is way faster than parsing HTML and extracting meta tags (you don't even have to read the entire message just the headers to decide whether the data is supported or not). |
Beta Was this translation helpful? Give feedback.
-
|
(Updated FIP has been moved to the main post to make the discussion easier to follow) |
Beta Was this translation helpful? Give feedback.
-
|
We already have it :) https://www.npmjs.com/package/@pinata/ipfs-gateway-tools This is a solved problem in the NFT space. I think FC devs will have no problem supporting IPFS protocol URIs. The added benefit of having this expanded content be immutable and sufficiently decentralized far outweighs any implementation concerns, IMO. |
Beta Was this translation helpful? Give feedback.
-
I mentioned it in earlier comments, but it's worth making the case again: IPFS has some additional complexity, but it's immutable. This is a very important property, because changing the content can change the context of user comments and reactions. Imagine recasting a cast with external content that says "I love X", and then the HTTP content changing to "I hate X". Immutability also makes it safe for clients to cache the content for ever. Personally, I'd go for IPFS-only if it was my call. It's much better aligned with Farcaster values, design and norms. |
Beta Was this translation helpful? Give feedback.
-
|
Agree with the sentiment on immutability. Although this is technically already an issue with any URL embed not pointing to IPFS/Arweave such as images, videos, web pages and especially frames. I didn't mention earlier but a property of casts that could be adopted for some externally linked content, such as the long casts in this FIP, is including a signature. This way clients can verify that the content was written by the account that owns the FIP that authored the cast. Re supporting ipfs and ar scheme. I think it makes a lot of sense for clients to support them but both IPFS and Arweave have http gateways that can be used to pull the content so immutability can be preserved without clients adopting those schemes by just linking to a gateway (clients can always parse the gateway URL to use another gateway or read from a node, etc.) One potential side-effect of not requiring immutable storage is that this not only introduces support for long casts but could also pave the way to editable casts. (Added benefit of the HTTP message structure I proposed is that we could add cache control headers to have clients/data-providers to invalidate their cache to refetch changes without reinventing this on JSON). |
Beta Was this translation helpful? Give feedback.
-
Indeed, but no reason to extend the issue for ever. :-)
It seems too much overhead, imho. Both on the creation side and the presentation side.
100%. Supporting a protocol does not limit clients on how they will implement the support. They can have their own IPFS nodes, or use an HTTP gateway, or whatever makes sense for each client.
LOL, I tout immutability as a quality, you want the exact opposite :-) Obv, both approaches have benefits. But editable casts, especially by changing the linked content would make devs life very hard. HTTP requests are expensive, require resources and an unpredictable amount of time. Imagine maintaining a client like Warpcast and having to revalidate 1% of 100,000s external URLs every minute or second. Really, really bad situation to be in (this was one of the hardest problems for RSS aggregators). It also make the life of indexers exponentially harder. |
Beta Was this translation helpful? Give feedback.
-
|
Absolutely. Updating content without an event that states that content was changed is a nightmare. |
Beta Was this translation helpful? Give feedback.
-
|
If you think the FIP should also include guidelines for clients to present this type of content, please share your thoughts.
|
Beta Was this translation helpful? Give feedback.
-
|
FIP updated:
|
Beta Was this translation helpful? Give feedback.
-
|
Sharing code (https://warpcast.com/michaelsullivan/0xb94476e8) is a known problem. How about we extend this to somehow support code snippets? Just indicating that the text is pre-formatted would be easy for clients (just use a fixed width font), but allows sharing of code and... ASCII art :-) What do you think, @goksu? This would be a nice differentiator for Farcaster. |
Beta Was this translation helpful? Give feedback.
-
|
This would come with supporting markdown. A triple tilde block with a language extension will be enough for clients to know to render as code even with syntax highlighting based on language if the client chose to support that. |
Beta Was this translation helpful? Give feedback.
-
|
I like markdown, and it was part of the original proposal. But I get it that properly parsing markdown can be messy, and it should be introduced at a later stage, if this gets traction. Markdown has many flavors and edge cases, and many details open to interpretation. In contrast, allowing |
Beta Was this translation helpful? Give feedback.
-
Clarifying the goal of this FIPSince this FIP is for "External cast data" and not just long text, we shouldn't try to be prescriptive as to what client should and shouldn't support. Instead the focus should be on:
The first use case is long text but having multiple examples is useful so making it work for both Given all this, a cast should be able to point to a URL that serves either The client should be able to determine the type (satisfy 2) without having to read and parse the external data to reduce overhead. This is to satisfy 5. This means that a client shouldn't have to parse a JSON document just to determine that the content type is Once the client determines that the data is What are clients?Usually when we use the word client we refer to apps such as Warpcast, Supercast, Nook, etc. This means that the bulk of the external link processing will be done by indexers and these indexers should be as efficient as possible. That's why point 5 above is important. I don't want my indexer to waste time issuing an HTTP request and then parsing a JSON document if it doesn't have to. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for putting all this together! There is a tension in this FIP between what it claims to address and what it wants to address. On one hand it pretends to be a proposal for long casts, on the other hand it tries to lay out the foundation of something that can be extended in the future, and this is where some of the "problems" you state come from. (But, I feel we all get the reasoning, and my slight dishonesty will be pardoned :-) That said, I'm not 100% sure if I get what your proposed changes are. Can you please clarify? |
Beta Was this translation helpful? Give feedback.
-
|
I want to make sure we're all on the same page about the scope and requirements for this FIP. Do the points I listed above make sense to you? I have some ideas but it usually involves using standard in non-standard ways. Such as what I shared earlier about using HTTP message structure. Another thought I had was, what if we use the data URI scheme which includes media type but instead of actually embedding the data in the URI we use the attributes to point to the external URL Something like That way clients can read the mimetype without doing a request to the external URL and without introducing a new field in the cast message. Then https://example.com/long-cast would just return plain text, no JSON. |
Beta Was this translation helpful? Give feedback.
-
|
I updated the FIP. |
Beta Was this translation helpful? Give feedback.
-
|
What would happen if the external fetch fails? Every single client that's trying to access that particular long form text would fetch on the fly. I'm assuming that the people creating long text will probably put a CDN but for some who aren't and get a sudden spike in traffic will face the hug of death similar to Reddit early days. Having a graceful fallback in cases would help. Would need to think about CDN, caches and who would be doing it.
I don't think it makes sense for protocol to cache it. The other thing is updating it. What if the poster posts, then updates it? The latest post would need to get refetched and cache busted. |
Beta Was this translation helpful? Give feedback.
-
|
I think this is more of a reason to use IPFS. Clients can choose the gateway provider (or run their own) to help ensure deliverability. If content fails to load through one, a client can fallback to another. This is exactly how NFT marketplaces work today and it works well. |
Beta Was this translation helpful? Give feedback.
-
|
@johnjjung IPFS also covers the user updating posts. You can't update a cast, so you shouldn't be able to update long casts. With IPFS, you know the post hasn't been modified too. |
Beta Was this translation helpful? Give feedback.
-
|
I like the idea very much.
I believe it would be useful to expand on the specification of
and so on. |
Beta Was this translation helpful? Give feedback.
-
|
Media types seem misplaced as a |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I agree. @davidfurlong's proposal to use json-ld provides a well-defined way to do this. But if it's up to me, I'd go for json-ld files and not json-ld embedded in html. Using HTML to encapsulate data feels like people who use Word for everything. |
Beta Was this translation helpful? Give feedback.
-
|
I don't think having a prefix in the URL is a good way of signalling, and if every protocol extension go this way it is going to be painful. |
Beta Was this translation helpful? Give feedback.
-
|
I think that’s the trade off we all have to come to an agreement on. Protocol change vs. lightweight change which can impact rendering on clients that don’t support it. The opengraph spec doesn’t make a ton of sense to me because it creates a significant overhead just to create long casts or add rich media support. |
Beta Was this translation helpful? Give feedback.
-
|
You could technically already display long posts in any client today just parsing the URL of the embed. On top of that, as OG can be considered as some sort of metadata it does not make sense to me to recreate a metadata schema. Indeed, OG handling is a significant overhead - however, infrastructure providers like Neynar, Pinata ;-) , Airstack or others could offer a service that parses OG for urls, similar to what @davidfurlong did with modsprotocol APIs. Today we want long cast and rich media support, tomorrow threads, the next day videos, etc. I don't think adding a prefix to URLs for that is scalable. Using OG makes the client rendering scalable without breaking the core protocol. |
Beta Was this translation helpful? Give feedback.
-
|
I prefer this way: #136 It seems to me that adding JSON linked data to a webpage is a better approach. If you have just json data, you can have a proxy gateway url that takes that json and renders open graph image fallback, frame fallback and serves that JSON linked data. This means that app builders can have a blue check/green check fallback by falling back to the open graph without having to implement each content type. |
Beta Was this translation helpful? Give feedback.
-
@davidfurlong I want to update the FIP to use json-ld embedded in HTML as you describe. Using a javascript block to embed the JSON data is OK, but it feels prone to a number of problems.
cc @deodad |
Beta Was this translation helpful? Give feedback.
-
|
Clients should definitely not execute any JS. It's bad enough that we have to parse HTML, look for a script tag and then parse JSON to get the value of It feels like taking a picture of a post-it note and running it through OCR then using text-to-speach to know whether the post-it note had text on it instead of just reading the post-it note yourself. I get the motivation of piggybacking on HTML since clients already have to parse it to get to the meta tags used for link previews. Frames piggybacked on this too for a quick one week rollout. That doesn't mean that it's the right standard for the job. Sadly we might get stuck doing things this way until a dominant data provider or client adopts another way which forces others to adopt to avoid looking broken. It works, it's just wasteful and unfortunate. It's great for data providers such as Neymar and Airstack since they can provide a simple API to all this data so clients don't have to get it themselves. |
Beta Was this translation helpful? Give feedback.
-
This is an existing standard. Multiple tags are valid
there's no js execution... it's a script of type JSON. So you parse it as JSON. |
Beta Was this translation helpful? Give feedback.
-
clients don't need to execute JS.
clients need to do something very similar for open graph images, as well as for frames. I don't think this is hard; json-ld is an existing standard with many libs for parsing it Here's an example that demonstrates both: https://github.com/mod-protocol/mod/blob/4361b912aba06d244e125ed14690eaa1197a9270/examples/api/src/app/api/open-graph/lib/url-handlers/local-fetch.ts#L31 |
Beta Was this translation helpful? Give feedback.
-
|
🙏 I'll be flying for the next day, but I hope to update the FIP after I arrive. |
Beta Was this translation helpful? Give feedback.
-
|
I built a client (3 clients in 1 actually) to show how this FIP impacts, or doesn't, clients. The demo app showcases the option of just linkifying these embed URLs, natively supporting them, and doing nothing. I think it does a good job especially of highlighting that adoption of this FIP will not break existing clients in any way. |
Beta Was this translation helpful? Give feedback.
-
|
cool! is there a reason why the abstraction choice is leaking into the UI here - the left col could have same the UI as the middle col |
Beta Was this translation helpful? Give feedback.
-
|
It's not leaking. It's a different implementation. If a client simply wants to render a link and not deal with rendering the long cast, they can do that. That's what the far left column is showing. I recorded a demo that talks more about this client here. |
Beta Was this translation helpful? Give feedback.
-
|
Right I guess the first thing one notices though is that the left col isn't really displayed as longcast at all; which might make someone falsely think that the left col version is limited to a worse UX, when in reality it isn't |
Beta Was this translation helpful? Give feedback.
-
|
I do not believe we even have to add an extended metadata, link rendering or protocol specification. I do not believe it needs more standardization then to agree up on at which number of replies stringed together we call it a long cast or as it is called in most of social media today "thread". The easiest solution by farAdding a "show more" button if there is a reply to a cast from the cast author would result in similar UX to what other plattforms already have with long posts, but keep it a very simple client level UI change. If one clicks show more unroll the whole thread into a nice reader view and let it be read like a blog post with reader mode in current browsers e.g. Firefox This also works great backwards with existing threads that can now be read more easily and the second cast in a thread doesn't suffer the "I am not visible since no one shows replies on the top feed level before clicking on the first one" faith. Making the writing experience pleasent then is a change to the cast editor to allow overflows and simply render them as thread similar to what supercast.xyz is already doing. This introduces NO change and is backward compatible with anyone doing nothing or not supporting it since everyone renders casts and replies. A secondary viewIf there really "needs to" be a change then I'd love for a Telegram style "instant view" where the link is precached and presented to the user in reader mode. Then clients could allow writing by adding paragraph or other's editor directly in the client and post there via API and the cast is a regular one with embedded link to the public post. Then clients that want to support it render webpages not via opengraph but frame style rendering with instant view. This could also be prefetched or even cached so it opens instantly for the user without another http request by the client or the user when accessing it. If this takes of, then one can argue about adapting frame specification to add instant view and maybe even extend what can be instant viewed to include different kinds of URI schemes like IPFS, Arweave and others proposed in the discussion #171 ConclusionI firmly do not believe this requires any change and encourage any client to go ahead like others in this thread have done to implement, measure usage and come back with number showing if others need to do it to or not. |
Beta Was this translation helpful? Give feedback.
-
|
Agree that this is a nothing burger at its current state. I thought it was something else due to the title but it isn't. Just stitch together casts, pull data posted from paragraph or mirror, add text support to frames (like I suggested) and call it a day. Long text is simple. No need to overcomplicate it. |
Beta Was this translation helpful? Give feedback.
-
|
Remember that this discussion is not only about long casts, but about any* kind of external data. Thus the need of thinking a bit ahead and try to find a way for clients to implement rich content rendering as proposed here #136 |
Beta Was this translation helpful? Give feedback.
-
|
The newest iteration of this proposal makes a ton of sense. Flexible and backwards compatible. I have no further feedback. Nice work @vrypan! |
Beta Was this translation helpful? Give feedback.
-
|
Great work on this spec @vrypan and @davidfurlong and others. If I could provide some feedback, I would nudge us toward extending the fc OG tags as others like @porenes have suggested above. I'm actually agnostic towards what we use, as long as it's consistent with Frames. Clients already have to parse OG tags to handle frame support, and there's a lot of existing infrastructure around frames that could be relatively easily extended to support this (and other future types of casts). We have talked about using JSON for Frames instead of OG tags, and it's something we can migrate to in the future for both frames and longcasts. I think supporting two different types of metadata for "rich content" is a lot of complexity for the ecosystem. Concretely, I would propose the following: Add an e.g. <meta property ="fc:render" content ="longcast" />
<meta property ="fc:longcast:format" content="markdown" />
<meta property ="fc:longcast:content:url" content ="<ipfs or https link>" />
// or
<meta property ="fc:longcast:content:raw" content ="**Markdown Content**\nThis is an example long cast" />If this is successful, we can look into moving Frames and Longcasts to start using JSON/JSON-LD down the line because it does have some benefits over meta tags. In that scenario, the page would have a single meta tag like <meta property ="fc:content" content="<url to json-ld document>" />And the json file describes the frame/longcast/other future types. |
Beta Was this translation helpful? Give feedback.
-
|
@sanjayprabhu I feel strong against HTML tags. Parsing the HTML DOM is much more complicated with many more edge cases than parsing a freshly defined json format. Especially when working in a language other than javascript. The concept of getting a random URL that you don't know what it points to (an image? a video? a frame? a blog post?), fetch it (if it's IPFS, you can use a HEAD request), see that it's HTML, then parse the DOM to see if there are OG tags, then decide what to do with them, and maybe in the future do a second request to fetch the longcast, seems very inefficient to me. And the only reason it makes some sense is because we adopted the OG tags as a way to describe things, and the more we extend OG tags, the more difficult it becomes to use something else. (OG tags were a great solution to a specific problem, not every problem). For a client like Warpcast that's rendering all types of content, and it's natively prepared to parse HTML anyway, this may feel natural. But for anything else, it's not. For a farcaster search engine, or something like buoy, my feeling is that implementing long casts as OG tags will increase their resource requirements and their code complexity by a lot. |
Beta Was this translation helpful? Give feedback.
-
|
The main advantage of using OG tags and HTML is that it makes it super-easy for any website to become compatible with longcasts, same as it is to become frame-serving. |
Beta Was this translation helpful? Give feedback.
-
|
@porenes, the FIP describes how to include a long cast in any HTML page, too. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, you can embed data in an html page using the script tag. |
Beta Was this translation helpful? Give feedback.
-
|
I think this is fine. Basically switch the FIP to be about frames.
Which aligns with my request to support markdown frames
https://warpcast.com/gabrielayuso.eth/0x6d5b09cb <https://warpcast.com/gabrielayuso.eth/0x6d5b09cb>
…On Fri Jun 7, 2024, 12:26 AM GMT, Sanjay ***@***.***> wrote:
Great work on this spec @vrypan <https://github.com/vrypan> and @davidfurlong <https://github.com/davidfurlong> and others. If I could provide some feedback, I would nudge us toward extending the fc OG tags as others like @porenes <https://github.com/porenes> have suggested above.
I'm actually agnostic towards what we use, as long as it's consistent with Frames. Clients already have to parse OG tags to handle frame support, and there's a lot of existing infrastructure around frames that could be relatively easily extended to support this (and other future types of casts). We have talked about using JSON for Frames instead of OG tags, and it's something we can migrate to in the future for both frames and longcasts. I think supporting two different types of metadata for "rich content" is a lot of complexity for the ecosystem.
Concretely, I would propose the following:
Add an fc:render tag to the frames spec. Defaults to frame, but can be set to longcast (matches @type in your spec). And then use the existing frames conventions for describing the longcast
e.g.
<meta property ="fc:render" content ="longcast" /> <meta property ="fc:longcast:format" content ="markdown" /> <meta property ="fc:longcast:content:url" content ="ipfs or https link" /> // or <meta property ="fc:longcast:content:raw" content ="**Markdown Content**\nThis is an example long cast" />
If this is successful, we can look into moving Frames and Longcasts to start using JSON/JSON-LD down the line because it does have some benefits over meta tags.
In that scenario, the page would have a single meta tag like
<meta property ="fc:content" content ="<url to json-ld document>" />
And the json file describes the frame/longcast/other future types.
—
Reply to this email directly, view it on GitHub <#171 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAPN5JDL5AQKGYKBVAJZRTZGD44RAVCNFSM6AAAAABIFE6WBWVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TMOJVGE3TG>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
I'm 100% for markdown frames. The limitation for md is not json/og but how much complexity it adds to clients that implement the write interface. I believe most content creation of this type happens in Warpcast, so if WC is ok with providing a markdown editor or is OK with users writing md in a text box, I'd love to see it. |
Beta Was this translation helpful? Give feedback.
-
|
Of course, we can also assume that all longcasts are markdown.
|
Beta Was this translation helpful? Give feedback.
-
|
I've been thinking about this over the last week and I think there are two ideas in this FIP that might bear separating - long casts vs inline article. Long CastsA long cast solves the problem where people are trying to express an idea and struggle to fit it into the 320 char limit. They may not even be explicitly aware that they are writing a long cast. They just start writing something and hit the character limit and give up or spend a lot of time truncating their thoughts. Here's an example of one on Twitter. 
This FIP's design creates a challenge because we must split content between the cast and the embed. We would have to do one of the following:
A different way of solving the problem is to simply increase the limit from 320 to 512 or 1024 characters per cast. We could probably pull this change off now safely and quickly. In the future we may have to reduce the number of casts per storage unit or something to handle scaling. Most importantly this approach would be very simple and explainable to users and clients. They can continue using the same surfaces and rendered components that they previously were using with minor modificaitons. In-line ArticlesAn inline article solves a very different problem - people are writing content on blogs but want to get more distribution via Farcaster. The paragraph frame is a good example. It does three important things:
This seems like a good fit for this FIP - can we improve the frame embed experience by making the content more readable than in the frame while also preserving advanced functionality like subscribe? Solving this use case requires benefits to both parties - users get a very convenient reading experience and authors get more readership. The one challenge with this proposal is that it doesn't (yet) solve the second problem. If I'm an author, how do I know that doing the work to have a "read inline" version of my content will convert better than just posting the link and having them come to my web page? tl;drWe have two distinct use cases and its probably a good idea to explore them with two different FIPs.
|
Beta Was this translation helpful? Give feedback.
-
|
The separate use cases are clear. Couple of thoughts:
|
Beta Was this translation helpful? Give feedback.
-
|
My personal itch (https://warpcast.com/vrypan.eth/0x354c1b89) most probably won't be addressed, but I've run out of energy on this one, @varunsrin. If this helps, as a potential user of long casts, someone who actually writes long-form content on a regular basis, increasing cast length to 512 or 1024 will not fit my needs. |
Beta Was this translation helpful? Give feedback.
-
In a utopia, the conversion rates would most likely be similar. A curious user would read interesting content whatever the complexity of retrieving one is (navigating to a different webite ~= clicking on "Show more"). However in a Social App like WC I believe the feed algo plays an important role here. With every each word read, more and more "curiosity energy" is either spent or accumulated. In other words, for a cast with a length of 20 words, "curiosity" score could vary between [-20, 20] and for a cast with 500 words it could vary between [-500,500] (saying if each word either increments or decrements the overall curiosity). I believe this is the reason why Long/Longer (if limit is simply increased) Casts have to be scored more aggressively in the feed to keep the content there interesting. In other words, seeing 5 Long Casts out of 10 overall in a feed would most likely be less interesting that seeing 5 regular casts out of 10 simply because you'll get through the not interesting ones faster and they won't consume that much of viewport. On the other hand though, Long Cast with "Show More" button sounds better to me than increasing the limit, as the latter might harm the feed. |
Beta Was this translation helpful? Give feedback.
-
|
@vrypan to be clear, im saying we should do both (1) and (2) in my proposal, just as separate fips. @dalechyn we would definitely do a show more type truncation on warpcast |
Beta Was this translation helpful? Give feedback.
-
|
FIP for (1) is ready. Thanks @varunsrin for moving fast with that. Hopefully it doesn't impact the priority or implementation of this one. As I was saying, this FIP is about defining a recommendation for clients to:
Ideally, the conversation from now on should focus on these items only, and not on specific types of external data. The idea is to have a standard, recommended way for clients to read metadata from an external resource. So does this FIP look good to you for that goal? |
Beta Was this translation helpful? Give feedback.
-
|
It seems people are generally aligned on splitting the FIP. The next question is: who will use this if we ship it? I hope someone like Paragraph will be excited about this. The reading experience is clearly superior to frames, which is what they use. A reason they might not want to is because frames let you "subscribe" to the author and this proposal has no equivalent. Is there some way to bake that into this standard to establish a link back to the author? If not I worry that paragraph will prefer to keep using frames and this feature might not take off. cc @seeARMS |
Beta Was this translation helpful? Give feedback.
-
|
I think the ideal outcome for Paragraph is to:
Here are a few possible options, in descending order of my preference: Allow frames & inline articles to be used in parallel; inline articles are triggered with a new client buttonParagraph could specify both a frame and a new "inline article" metatag. Clients render our existing frame, but if the new metatag is present, they also render some new "Instant View" button. This is basically what Samuel said above, and is what Telegram's doing with their Paragraph pseudocode: <!-- Specify that we have an "inline article" / "instant view" -->
<meta property ="fc:instant_view:format" content="markdown" />
<meta property ="fc:instant_view:content:raw" content ="**Markdown Content**\nThis is an example article" />
<!-- Specify that we also want to render a frame -->
<meta property="fc:frame:image" content="paragraph.xyz/frame-img.png" />
<meta property="fc:frame:button:1" content="Read Online" />
<meta property="fc:frame:button:1:action" content="post_redirect" />
<meta property="fc:frame:button:2" content="Subscribe" />
<meta
property="fc:frame:post_url"
content={`https://paragrap.xyz/api/farcaster/blog/123/post/456`}
/>It's worth noting that Telegram has a slightly different design where they don't require devs to actually include the raw markdown -- instead they let devs include a "template" for their page, which tells clients "this is how you should parse the HTML on the web page and convert it into an instant view article". May be worth exploring this further for future versions. Allow frames & inline articles to be used in parallel; inline articles are triggered with frame buttonAdd a new frame button action that opens content inline. We can replace our "Read Inline" button with this new button action. Eg: <!-- New frame button action -->
<meta property="fc:frame:button:3" content="Read inline" />
<meta property="fc:frame:button:3:action" content="instant_view" />
<meta
property="fc:frame:button:3:content:raw"
content ="**Markdown Content**\nThis is an example article" />
<!-- All the other frame buttons -->
<meta property="fc:frame:image" content="paragraph.xyz/frame-img.png" />
<meta property="fc:frame:button:1" content="Read Online" />
<meta property="fc:frame:button:1:action" content="post_redirect" />
<meta property="fc:frame:button:2" content="Subscribe" />
<meta
property="fc:frame:post_url"
content={`https://paragrap.xyz/api/farcaster/blog/123/post/456`}
/>Support complex JS or logic in the "inline article" viewI'm not a big fan of this idea due to complexity, but perhaps clients can support some rendering spec that's more advanced than markdown but a subset of the full HTML spec, similar to the Google Amp HTML spec. This would allow Paragraph to (eg) display "Subscribe" / "Mint" buttons at the top and bottom of every post that's read inline. Maybe we can even log the user in automatically in this "inline article" view by their fid, so all interactions on this page are authorized and users can 1-click subscribe without needing to login themselves. |
Beta Was this translation helpful? Give feedback.
-
|
Assuming my content is published at Where did I create it?
Where is it hosted?
How is it distributed?
I could see me using a cast URL to tell Paragraph to pull the embedded json from a cast created inside Warpcast, populate my Paragraph publication, and letting me notify my followers via email, as well as giving non-fc users the ability to comment on it. I can also see a Pinata service that watches my feed for long casts with an IPFS embed and pins them for me. |
Beta Was this translation helpful? Give feedback.
-
|
This is nice, @seeARMS! |
Beta Was this translation helpful? Give feedback.
-
Title: External cast data (long casts)
Type: Standards FIP
Authors: @vrypan, @davidfurlong
Abstract
This is a proposal to enable long casts. The long cast content is stored at an external URI. The proposal is designed to be easily extendable to support more features in the future, without hub modifications.
Problem
This FIP was triggered by the discussion on long casts (see https://warpcast.com/v/0xa9456e70).
In addition, a look at FIP ideas and Farcaster discussions indicates that many developers are interested in embedding a number of data types in casts: location, audio, events, etc. This FIP defines long casts in a way that will allow embedding various data types in the future with minimal changes.
Specification
Long casts are stored in external storage (not hubs) and are embedded to casts using
Embed.url.Only plain text long casts are supported by this FIP.
Data Format
The content of a long cast is stored in JSON Linked Data format:
Embedding the payload
There are two ways to link to a long cast.
1. json-ld payload embedded in an HTML page.
The json-ld payload can be embedded in an HTML page:
and applications can use
Embed.urlto point to the HTML page URL.In this case, clients will have to fetch the HTML, parse it and check for a json-ld longcast payload, in the same way they check for Open Graph tags to display frames and page previews.
This is a backwards compatible way that will work nicely with web content shared on Farcaster (for example, blog posts can provide a longcast json-ld payload and clients can show the whole blog post as a long cast).
The disadvantage of this method is that clients have to load an HTML page without knowing in advance what to expect, and check for OG tags, then check for json-ld, and decide what to do depending on what the results.
2. Stand-alone json-ld payload
The json payload can also be hosted at a URL and
Embed.urlcan link directly to it. Linking directly to the json payload is more efficient than embedding it in HTML.In this case, the
urlmust be in the formatfc:<url>that indicates to clients that the URL points to a json-ld payload.Examples:
fc:http://www.test.com/longcast.jsonfc:ipfs://QmWMo7MrnpSAH2dMKNhcrvLeKdyyqjyrAdy9vUfEdyqcwUWhy use the
fc:URI schema?fc:URL will always point to json-ld data.fc:, they would show a “no preview available” because they are not aware of the payload structure, now they will show the same because they do not know how to deal with thefc:URI schema.schema=fc,path=http://....), and then treat thepathas the new URL.Supported protocols
This FIP does not explicitly limit the transfer protocols clients are expected to support.
However, clients are encouraged to support at least HTTP, HTTPS and IPFS.
Presentation
If a cast includes both a body and a long cast, clients are expected to render both and I provide a visual indicator (for example a separator) that lets users know which part corresponds to each one. The cast body (if present) is expected to be rendered before any long cast content.
Size Limit
The JSON payload (either embedded or stand-alone) size must be less than 32kb.
This limit is set to help clients allocate resources and protect them from malicious payloads that could allocate an arbitrary memory size.
The limit also allows any content that could be published as a long tweet (limit 25,000 characters) to be posted as a long cast. (When using unicode characters this may not always be the case, but this feels like a good approximation.)
Wherever possible, clients are advised to reject the json data structure when its size is more than 32kb.
Compatibility
Long casts embedded in an HTML page provide multiple ways (OG tags, HTML tags) that allow clients that do not support this FIP to show an alternative representation of the long cast (for example, a frame or an abstract).
Long casts directly embedded as stand-alone json will appear as unsupported link types in clients that do not support this FIP. Given the early stage of the Farcaster ecosystem, this is considered an acceptable tradeoff to provide a future-proof, clean and efficient way to embed rich data in casts.
Extensibility
Clients that implement this FIP, can easily support additional json-ld payload schemas if they decide to do so in the future.
schema.org has a number of schemas (including events, places, products, reviews and other) already supported by major services like Google, but new ones can also be defined.
JSON-LD is available in a number of popular programming environments. A comprehensive list can be found at json-ld.org.
Hub requirements
No changes.
Storage requirements
No change in storage requirements.
Additional thoughts
The combination of long casts stored in decentralized storage, combined with permissionless channels can provide a truly decentralized content publishing platform that requires NO web servers: the web3 version of the web2 blog.
Revisions:
fc:schema to link directly to payloads.structured+tofc+. The term feels more natural given the context, and easier to use.text/preis also part of the spec. It indicates pre-formatted text such as code or ASCII art.Beta Was this translation helpful? Give feedback.
All reactions