Link previews - Githubissues

tinode / chat

Instant messaging platform. Backend in Go. Clients: Swift iOS, Java Android, JS webapp, scriptable command line; chatbots

GNU General Public License v3.0

12.05k stars 1.88k forks source link

Link previews #820

Open or-else opened 1 year ago

or-else commented 1 year ago

Embedded previews of URLs

yinebebt commented 18 hours ago

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

Thanks!

or-else commented 14 hours ago

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 commented 14 hours ago

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 commented 13 hours ago

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 commented 13 hours ago

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

or-else commented 12 hours ago

I see two options:

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.
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 commented 8 hours ago

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 commented 7 hours ago

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.