Link previews

[or-else]

Embedded previews of URLs

[yinebebt]

Hello, is there someone working on this? if no, I am going to work on it.

Thanks!

[or-else]

No one is working on it. You are welcome to take a shot.

Before you start, please describe how you are going to do it:

• which component fetches the web site: sender client, receiver client, server.
• how you render it: drafty or image.
• which parts of the website you are going to use for preview, i.e. <meta property=og:description>, <meta property=og:image>, <meta property=og:title>, if these are missing then ..., then ...

[yinebebt]

I am planning to proceed with these points in mind:

• Data Fetching: Perform URL fetching on the server side.
• Rendering Format: Use image-based previews with HTML templates.
• Data Extraction: Prioritize og:title, og:description, and og:image tags for previews. If these are missing, fall back on the <title>, meta description, or a default image (e.g., placeholder icon).
• Fallback Strategy: Where no Open Graph tags exist, provide generic descriptions or favicon for minimal preview details.
• Additional Considerations: Sanitize fetched content and use caching to avoid redundant network calls.

Thanks!

[or-else]

Perform URL fetching on the server side.

As a separate service which gets called by a client?

Please keep in mind that the server-proper does not do any message parsing right now and we do not want it to do the parsing. There is parsing in the push notifications module only. The server does not rewrite the messages and we don't want it to so.

Rendering Format: Use image-based previews with HTML templates.

Please expand on it a bit more. Also, keep in mind that the tinode clients do not have the ability to handle HTML right now and we have no plans to add such ability.

use caching

What kind of caching do you want to use?

Thanks.

[yinebebt]

ok, I will take some time on this and will update you. But if you have plan let me know.

[or-else]

I see two options:

1. Server fetching, sender-client rendering: the server provides an API for fetching a site description: takes a URL, returns JSON with title, description, and image URL. The sender-client appends the site description to a message in drafty format. Client-receiver just renders the message, no changes needed.
2. Sender-client fetching and rendering: same as above but the sender-client does the fetching too. Server would have to implement HTTP proxy functionality for CORS avoidance.

The option 1 is somewhat simpler, but will encounter captcha a lot more than 2. And it would require request throttling and caching.

The option 2 is a bit more complex, because fetching and HTML parsing would have to be implemented independently for each client. And it won't just work for Javascript because of CORS: server would have to act as a proxy for requests from the JS clients.

[yinebebt]

I prefer to go with Option 1 (Server fetching, sender-client rendering). If I understand correctly, the client itself will detect the link(s) and then fetch the preview details from the server, right?

Also, would it be better for the message to wait until the server returns the preview data, or should the message text be sent immediately, with the preview appended later as an update?

[or-else]

Yes, the client would detect the link. It does so already.

I just checked: it looks like both Telegram and Whatsapp fetch site info while the message is being composed.

[yinebebt]

Hello @or-else, can you check a PR at #929