Proposed XMPP Extension: Link Metadata
The XMPP Extensions Editor has received a proposal for a new XEP. Title: Link Metadata Abstract: This specification describes how to attach metadata for links to a message. URL: https://xmpp.org/extensions/inbox/link-metadata.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.
Le vendredi 6 février 2026, 12:08:00 heure normale d’Europe centrale Daniel Gultsch a écrit :
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Link Metadata Abstract: This specification describes how to attach metadata for links to a message.
URL: https://xmpp.org/extensions/inbox/link-metadata.html
The Council will decide in the next two weeks whether to accept this proposal as an official XEP. _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Hello, Thanks for this proposal, I like it and was hopping for something like that for a while. 2 remarks: - "his metadata is commonly generated from the resource that can be retreived from the resource that can be found at the IRI," ==> it seems that there is an error in this sentence, the repetition of "generated/retreived from the resource". Also there is a typo, it's "retrieved". - the main issue I see with this proposal is that the sender can send fake preview for malicious website, like sending a link to "evil.example.com" and the preview say "it's kitties pictures". I don't think that this can really be avoided, but a mention of that in security considerations would be good. Maybe the receiving client should show a small warning about that? With my council hat, I'm +1 on it. Best, Goffi
Hello,
- the main issue I see with this proposal is that the sender can send fake preview for malicious website, like sending a link to "evil.example.com" and the preview say "it's kitties pictures". I don't think that this can really be avoided, but a mention of that in security considerations would be good. Maybe the receiving client should show a small warning about that?
I think that adding a warning is fine, but maybe it should be stressed out that there is no perfect solution, and this is most likely the most reasonable tradeoff. Recipient-generated is a very bad idea, security and legally-wise. Sender-generated is E2EE compatible (I mean, once we have full stanza encryption I guess), fully in-band. It is worth noting that one will find other more or less standard metadata elements in web pages, like twittercards, microdata, json-ld, and probably others. I like that the text of the XEP does not say that link metadata does not necessarily have to map to opengraph data in the linked page, and that generating such metadata is out of scope. -- nicoco
Greetings. This argument is also valid to XEP-0446 and XEP-0447. Should we, perhaps, consider Metalink (RFC 5854) instead of OpenGraph, and any other similar solution which be specific to XMPP, for such task? Metalink -------- Metalink is a metadata document with references to any kind of file over any protocol (be it FastTrack, Gemini, Gnutella, MUTE, et cetera). Generally, I think that, Metalink is the best choice for that task of sending document and multimedia documents with description of the linked data. Multimedia ---------- Metalink can be also utilized to send a video (hosted over eD2k, FTP, Gnutella, HTTP, and IPFS) with textual description. Metalink can be utilized to send a gallery of images, and people would select whether to retrieve all images or a selected few. Adoption -------- Metalink probably does not even necessarily require an XEP, as it is solely a software client task to parse and realize the Metalink document. I think that, if XMPP developers would adopt Metalink, this would prompt developers of IRC, and other messaging platforms, to do the same; and, thereby, to contribute to interoperability of exchange of data with XMPP. Example ------- I have attached a short example Metalink document of the video "Trusted Computing (2004)" which realizes a few of the possibilities of Metalink which be useful with chat software. (X)HTML ------- While (X)HTML documents are not always meant to be downloaded; I think that, Metalink can be a valid mean to handle the described concern. Conclusion ---------- To summaries, my argument is to substitue XEP-0446 and XEP-0447 by Metalink, and to extend the use of Metalink to the concern of "Link Metadata". Kind reagrds, Schimon On Fri, 06 Feb 2026 11:08:00 -0000 Daniel Gultsch <daniel@gultsch.de> wrote:
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Link Metadata Abstract: This specification describes how to attach metadata for links to a message.
URL: https://xmpp.org/extensions/inbox/link-metadata.html
The Council will decide in the next two weeks whether to accept this proposal as an official XEP.
Should we, perhaps, consider Metalink (RFC 5854) instead of OpenGraph, and any other similar solution which be specific to XMPP, for such task?
While I expect OpenGraph to be a popular vocabulary here because it is the biggest standard for link metadata, we are not restricted to that by the XEP. TIL metalink, it looks basically identical to the jingle file element (and the sfs file element). Sad that we now have three of these defined instead of collaborating. However it's not really related to the main link metadata use case.
Stephen. Good evening. On Tue, 24 Feb 2026 11:10:45 -0500 Stephen Paul Weber <singpolyma@singpolyma.net> wrote:
Should we, perhaps, consider Metalink (RFC 5854) instead of OpenGraph, and any other similar solution which be specific to XMPP, for such task?
While I expect OpenGraph to be a popular vocabulary here because it is the biggest standard for link metadata, we are not restricted to that by the XEP.
TIL metalink, it looks basically identical to the jingle file element (and the sfs file element). Sad that we now have three of these defined instead of collaborating. However it's not really related to the main link metadata use case.
Thank you for your answer. Please, ignore my argument. I will ask, again, about the adoption of Metalink, and to deprecate similar XEP extensions in favour of Metalink. Kind reagrds, Schimon
participants (5)
-
Daniel Gultsch -
Goffi -
Nicolas Cedilnik -
Schimon Jehudah -
Stephen Paul Weber