Open sjehuda opened 1 month ago
Thanks for reporting this. The current implementation supports only 1 alternate link and does only use one if multiple are found. The DB schema is also limited to having only one link.
Therefore while it is easy to parse more links, it is hard to store and render them properly. This is a complex border use case I do not plan to support.
I must admit I'm not very familiar with XMPP use case / Blasta. In the scope of Liferea what could you do with all the links if they would be rendered?
Blasta is a new system.
https://video.xmpp-it.net/w/cfozoUeVLFbBFMCCSCJ1Dn
On Wed, 25 Sep 2024 15:21:17 -0700 Lars Windolf @.***> wrote:
I must admit I'm not very familiar with XMPP use case / Blasta. In the scope of Liferea what could you do with all the links if they would be rendered?
As I have mentioned, that alternate link is not standard.
I was thinking that each client would use the one that it is familiar with.
For instance, Rivista XJP would use the XMPP link to suggest people to read the content via XMPP.
Good day!
Either the Blasta feed is malformed or Liferea might have an issue.
Template https://git.xmpp-it.net/sch/Blasta/src/branch/main/template/browse.atom
Please notice the non-standard type attribute
type="x-scheme-handler/xmpp"
.This is the resulted feed:
P.S. Liferea is featured at https://git.xmpp-it.net/sch/Blasta/src/branch/main/template/syndication.xhtml#L416