Hi, 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. Regards, Marvin _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
