Skip to content

Conversation

@flavorjones
Copy link
Member

@flavorjones flavorjones commented Jul 14, 2025

ref: https://3.basecamp.com/2914079/buckets/37331921/todos/8833406931

See also https://github.com/basecamp/rich_link
See also basecamp/lexxy#26

TODOs:

  • only attempt to unfurl links that are allowlisted (currently attempting everything)
  • Fizzy is making a web request to itself for Fizzy links, which is gross. We could optimize this by having the client make the request (which is what BC4 does). Not sure it's worth having two separate code paths, though. Feedback welcome.

and split out Current.user as a separate property so that we can set
it for these one-time rich link tokens without creating a session.
@flavorjones flavorjones force-pushed the flavorjones/unfurling branch from 162760b to 53dc8f7 Compare July 14, 2025 19:44
@flavorjones flavorjones force-pushed the flavorjones/unfurling branch from 53dc8f7 to 917f81c Compare July 14, 2025 19:54
gem "image_processing", "~> 1.14"
gem "platform_agent"
gem "aws-sdk-s3", require: false
gem "rich_link", bc: "rich_link"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's great to have a gem to centralize this logic! For your consideration: I think it would be fine if the gem just exposed the API to unfurl the link (e.g: to get the title for the link), and then the host app introduces its own controller using that gem. That would simplify the authentication stuff and, more importantly, would allow different apps to configure the unfurl logic differently. This goes in the line of the suggestion about whether Lexical should support getting arbitrary HTML replacements for links.

For example, In Fizzy, we could choose to present "Fizzy links" with some custom HTML, while in Basecamp, we present those as regular links. Or we could choose to unfurl other types of links differently (E.g: PDF links using the PDF viewer in Basecamp). Both apps could use the same API to extract the title of "supported apps links", but would assume how to present the links (even if we duplicate the same rendering logic in both apps, I think that's fine).

@monorkin monorkin mentioned this pull request Sep 30, 2025
3 tasks
@flavorjones
Copy link
Member Author

Superseded by the great work at #1196 by @monorkin

@flavorjones flavorjones closed this Oct 3, 2025
@flavorjones flavorjones deleted the flavorjones/unfurling branch October 4, 2025 02:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants