Mastodon: RSS Feed Titles Need to be More Expressive.

[MilkManzJourDaddy]

This was actually raised in #1438 . But, disappointingly, was closed without really understanding the heart of the issue. Followers should read that one first. 😒

The biggest change over all this was adding RSS to the mix. It seemingly did NOTHING to fix the issue.

We should not need to Reverse Engineer/workaround a F(L)OSS project, ala https://github.com/RSS-Bridge/rss-bridge to get a good feed that does not drop some non descript generic blurb where fed. Sad that we yearn for Twitter™ in that respect. With re-toots, replies, et cetera, when content is fed outside a Mastodon client, we get a bunch of generic feeds. And it is a waste of time clicking on things of no interest to us. Try https://mastodon.social/@TootBot.rss. It yields the same as https://mastodon.social/@TootBot.atom:

TootBot (@[email protected]) posted a new article: New status by TootBot ( https://mastodon.social/@TootBot/100495275495149029 )

And that is insufficient when a bit of description/summary is needed. There have been several issues related to this, including merged/pulls, and still this. 😒

[mike-burns]

Historical and implementation notes:

7259 is where RSS feeds were added to the repo.

The title is set in RSS::AccountSerializer: https://github.com/tootsuite/mastodon/blob/master/app/serializers/rss/account_serializer.rb#L22 . There's duplication in RSS::TagSerializer to watch for too.

It's set from Status#title: https://github.com/tootsuite/mastodon/blob/master/app/models/status.rb#L146-L152 . Be mindful when changing that; it's also used for the Atom feed that communicates between instances. It's probably safer to construct a title specific to the RSS feed (#human_title or a one-off in the serializers).

[MilkManzJourDaddy]

Media RSS allows for a much more detailed description of the content to be delivered to the subscriber than the RSS standard.
https://en.wikipedia.org/wiki/Media_RSS

I think many of us who are happy to have a non-birdsite platform feed content elsewhere, would much rather know a basic bit about the status, if it interests us, before clicking. Just a basic blurb, not necessarily even MRSS.

The state of this repulses people from Mastoson instead of drawing them. Think about it… I put a Mastodon feed, and birdsite feed someplace. The birdsite fed item describes itself, and the Mastodon item states that some microblogger posted something in their microblog. If the birdsite item interests thrm, most people will click that, not some mystery link.

[jbond23]

I posted the original. My user requirement still stands. atom.title is a useful summary of an atom item that is commonly used in the same way as an email subject line.

I don't know the detail of the underlying code that does federation. But if it really depends on atom.title containing text of the form "New status by $USERID" then there's something broken with the code design. atom.title should be purely descriptive text and not functional data. I actually find it really hard to believe that the activitypub spec calls for atom.title to be "New status by $USERID" and for that to be somehow used federation between activitypub instances. Can anyone point at a URL where this is stated?

[mike-burns]

My understanding of things is that there is a dedicated RSS feed for us to subscribe to (#7259), and any one who wants to improve it should submit a PR that changes the title. That line of code is here: https://github.com/tootsuite/mastodon/blob/master/app/serializers/rss/account_serializer.rb#L22

[nightpool]

@jbond23 The reason an RSS reed was added was not because atom.title is required to be "New status by nightpool" but because the atom feed breaks most user-facing feed readers, full stop. So instead, we added a "user facing" RSS feed that was designed to be more friendly.

for that to be somehow used federation between activitypub instances

ActivityPub doesn't use atom at all. the atom feeds are required by OStatus.

[jbond23]

My bad. Got my OStatus and ActivityPub mixed up.

As far as I can tell, atom.entry.title == rss.item.title and atom.entry.content == rss.item.description. And the only thing in the atom feed that might display badly in user-facing Atom feed readers is the atom.entry.title And the only reason that displays badly is because while it is "A human readable title for the entry." [W3C atom guidelines], the text is human-readable uselessness. Since rss.item.title is identical, I'd expect it to display equally badly in user-facing RSS feed readers.

I still don't believe that OStatus federation requires atom.entry.title to be this human useless. It should be human readable and not contain functional data. Any functional data should be in functional fields or extensions. I'd love it if somebody could explain why it has to be the way it is currently.

So, recommendations.
1) Make rss.item.title the first ~128 characters of the toot after stripping html.
2) At least consider doing exactly the same thing with atom.entry.title and understand exactly if and why this is not possible and would break OStatus federation.

[babolivier]

I'd second that. Having human-readable RSS/Atom feeds is a feature Twitter has that Mastodon lacks imho.

Make rss.item.title the first ~128 characters of the toot after stripping html.

Maybe also include the whole HTML-rendered toot in a <content:encoded> tag using this RSS extension.

[vabd]

+1, this would help integrating users' timelines in other systems (i.e. public announcements in a project's IM room from the project's Mastodon user's toots).