livemarks uses alternate instead of primary URL for feeds

[anarcat]

Feed URL
Please specify the feed URL: private URL, but an example would be:

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
            <id>wallabag:lib3.net/wallabag:anarcat:tag:quicklinks</id>
        <link rel="alternate" type="text/html" href="https://lib3.net/wallabag/tag/list/quicklinks"/>
        <title>wallabag — tag quicklinks feed</title>
        <subtitle type="html">Atom feed for entries tagged with quicklinks</subtitle>
                <updated>2023-07-18T17:03:05+00:00</updated>         <link rel="self" type="application/atom+xml" href="https://lib3.net/wallabag/feed/anarca
t/gmU2B6OGqPRzYk/tags/quicklinks"/>
    <link rel="last" href="https://lib3.net/wallabag/feed/anarcat/gmU2B6OGqPRzYk/tags/quicklinks/1"/>
    <generator uri="https://wallabag.org" version="2.5.4">wallabag</generator>
    <author>
        <name>anarcat</name>
    </author>
    <icon>https://lib3.net/wallabag/favicon.ico</icon>
    <logo>https://lib3.net/wallabag/bundles/wallabagcore/themes/_global/img/logo-square.png</logo>
        <entry>
        <title><![CDATA[tpa board]]></title>
        <link href="https://gitlab.torproject.org/groups/tpo/tpa/-/boards?scope=all&amp;utf8=%E2%9C%93&amp;state=opened"/>
        <link rel="alternate" type="text/html"
              href="https://lib3.net/wallabag/view/38722"/>
        <link rel="via"
              href="https://gitlab.torproject.org/groups/tpo/tpa/-/boards?scope=all&amp;utf8=%E2%9C%93&amp;state=opened"/>
        <id>wallabag:lib3.net/wallabag:anarcat:entry:38722</id>
        <updated>2020-06-25T12:36:01+00:00</updated>
        <published>2020-06-22T17:52:19+00:00</published>
                    <category term="work" label="work" />
                    <category term="quicklinks" label="quicklinks" />
                    <category term="tor" label="tor" />
                        <author>
            <name></name>
        </author>
                <content type="html" >
            <![CDATA[estimated reading time: &lt; 1 min]]>
        </content>
    </entry>
    </feed>

This is a feed generated by Wallabag.

Add-on version
Add-on version: 3.8

Describe the bug

With the above feed, livemarks now links to (e.g.) https://lib3.net/wallabag/view/38722 instead of the canonical https://gitlab.torproject.org/groups/tpo/tpa/-/boards?scope=all&utf8=%E2%9C%93&state=opened. This means an extra click to actually get to the article.

This is, from my perspective, a regression that was introduced in response to #34, in 345156e, which deliberately prioritised the alternate links to "fix" feedburner feeds, but from my perspective, this is actually inaccurate: the "alternate" is a fallback, well, an alternative in any case... Certainly not the best link for wallabag!

To Reproduce
Steps to reproduce the behavior:

1. Go to https://app.wallabag.it/register/
2. Register
3. Bookmark a few articles
4. Generate a RSS feed link
5. add it to Livemarks
6. observe the links going to wallabag instead of the bookmarked links

Expected behavior

Before the above change, the bookmarks were pointing to the right place, which is the article itself, not the wallabag link.

Thanks!

[evilpie]

Well this is just a bad situation all around, not sure what we can do. Feedburner needs to keep working in any case.

[anarcat]

let's break it down.

wallabag does this:

1. plain <link>: good
2. <link rel="alternate" type="text/html">: not great
3. <link rel="via">: good

feedburner does this:

1. <link rel="self">: broken?
2. <link rel="alternate" >: good

it also has rel=replies and rel=edit which i'll ignore here.

Could we prioritize the plain <link> without any rel tag, then fallback to alternate then self? that would make both feeds work.

I think this is fundamentally an interoperability problem between RSS (which doesn't specify a rel attribute, which Wallabag seems to do here) and Atom (which does). According to RFC4287 section-4.2.7.2, Atom feeds without rel attributes are considered to have rel=alternate so it seems to me the above algorithm would be standards-compliant for both feed formats.