[Standards] The Open Graph protocol

Marvin W xmpp at larma.de
Tue Nov 10 11:10:04 UTC 2020


Beside what Jonas said, there is two things I'd like you to consider
when specifying this that seemed to be out of scope or not considered yet:

## Support sender-side link generation
According to various security/privacy people, the best way to do these
link previews is to generate them client-side with the sender. By
sending a link the user expresses some amount of trust into it and it is
reasonable to assume they won't be sending links with the intention to
cause harm to their client. However, sending links to cause harms to
others (being it servers or remote clients) is more likely to be in the
intention of some people.

While I understand the wish to do this server-side in MUCs (i.e. clients
will take some time to support this in sending and you don't want
receiving users to suffer in UX because of that), sender-side link
preview creation should be the default and server-side rather an
optional fallback.

If link previews are generated by the sender, there is no strict need to
use message attaching (or fastening or whatever is going to be the next
big thing), the link preview details could just be in the message that
has the body with link itself (that said, generating such links might
impose a delay, so some clients will want to use a second message to
announce the link preview nonetheless). So the spec IMO should have this
in mind from the beginning. When using message attaching, this would
probably be straight forward, when using message fastening it's not.

## Parsing (multiple) links from a body
A message certainly can contain more than one link in its body. And
parsing links from a message is a non-trivial task (think of closing
parens). Depending on how clients render those link previews, it may be
a crucial information where to put it. I think when having the link
preview, it should somehow replicate the URL it is referring to and it
should be possible to have multiple link previews for different URLs
attached to a message.
Note that the og:url is referring to a canonical URL, which does not
need to be the same as the request URL.


More information about the Standards mailing list