Feeds ids parsing in the Greader API seems inconsistent

[kaiyou]

The Greader API is blurry at best when it comes to feed ids. The best source I could find is: https://github.com/mihaip/google-reader-api/blob/master/wiki/ItemId.wiki

Basically the API supports short decimal ids and long, tag-prefixed, hexadecimal ids. 16 is equivalent to tag:google.com,2005:reader/item/10.

Hence, the fix from https://github.com/miniflux/v2/pull/1517/files looks consistent with the Google API, except for some very specific implementations of the API, which ignored some of the spec. Because Miniflux implements /items/ids and /items/contents, many clients first request /items/ids, which returns short ids, then pass those ids unchanged to /items/contents. Those clients (including Liferea) currently do not work with Miniflux because aforementioned fix was later reverted: 3eb3ac0..

Some clients (e.g. RSSGuard) do convert short ids to long ids and succeed. I wonder which clients did convert to base16 without prefixing, and explain why you reverted your fix. I could not find any reference in an issue or PR.

Currently Miniflux Google Reader API is broken for at least one client (Liferea) that still seems to conform to the historic API. It sounds like the fix belongs in Miniflux, and I suggest we check for user agents or client ids when converting ids to handle any unsupported behavior.

I am ready to provide a PR. Since passing short-base10 or long-base16 are consistent with the API, I would rather make an exception for those that pass short-base16 ids, if you could remember which.