X-Rssgoemail?

(1) By Omar Polo (omarpolo) on 2022-08-19 12:07:54 [link] [source]

you (asbc@) mentioned this on irc the other day, as it would allow to easily filter the mails.

i like the idea and would like to use it, as i'd prefer for my feeds to be in a separate (imap) directory.

What remains is the bikeshedding for the name and content of the header i guess? :)

X-rssgoemail: <url>

do we want more?

(2) By absc on 2022-08-19 21:01:40 in reply to 1 [link] [source]

Yes, I consider this the right approach, given the flexibility it provides for all the hops between the client and the final destination (SMTP servers, LMTP servers and whatnot.

I don't have that much experience about naming custom header. Question is, what's the meaning of it? You mentioned that the header content will be a URL, maybe X-RssGoEmail-URL will be better?

I believe the header should be a bit more descriptive about it's content. Otherwise, I believe that's the way to go to give people the flexibility they need.

(3) By absc on 2022-08-19 21:11:29 in reply to 1 [link] [source]

My random thinking is that, given that we support wildly different types of feed formats, Just go with the URL (even partial). For example, the gemini feeds have nothing outside of a date or a link.

I suggest to just use the URL, there is not much in common between formats.

(4) By Omar Polo (omarpolo) on 2022-08-20 07:33:26 in reply to 2 [link] [source]

Thanks for the suggestions. I was sure about using an header, it's easy then to filter emails at different levels (smtp, lmtp, other client stuff ...) but i wasn't sure about the rest.

I agree that the URL is the only bit of information in common and useful. Other things like the site, the name etc... are already present in the subject or from header.

(and for the body i have a plan, i'd like if the content of the articles would be sent as the body of the email, but we'll talk about it :D)

fwiw i agree with X-RssGoEmail-URL as naming.

(5.1) By absc on 2022-08-20 11:51:33 edited from 5.0 in reply to 4 [link] [source]

I'm not sure about sending the content, it implies parsing HTML, various mime types. Not sure we should do something like that in a tool such as rssgoemail.

What if there is no body? Do we fetch it from the internet? I believe this would be outside the scope of an rss reader.

(6) By absc on 2022-08-27 10:27:20 in reply to 4 [link] [source]

I thought a bit more about adding the article text to the feed item. In the kind of feeds we support right now, we have different options:

1. RSS/Atom over HTTP/HTTPS

This feed is semantically consistent, but it's not mandatory for it to have the whole content in the feed itself. Some CMS embed the whole document in the "description" tag, others embed only the subtitle, or an ABSTRACT in it. How do we decide what to do? The only correct option, should be to fetch the whole HTML document from the item URL, but what happen if it's a paywall? Do we want to run the Javascript that may be embedded in the doc?

IMHO, fetching the whole article would work only for plain HTML documents, not much for more complicated content. Remember that some sites even tells you that:

You must enable javascript to see this content

Or similar shit. Security-wise, javascript code execution is something I'm not eager to enable on a tool like rssgoemail.

2. RSS/Atom or gemfeed over gemini

Here we can fetch the content, no problem. Even if not rendered, the content itself will be just plaintext. A potential client could open the content without rendering issues and even embedding the document body in the e-mail should work just fine. We may need to add a proper encoding in the email headers.

I believe that RSS over HTTP should remain as it is, but we can do something for the gemini side, at least to let people in the gemini world enjoy such a feature.

Thuoght?

(7) By Omar Polo (omarpolo) on 2022-08-27 16:54:53 in reply to 6 [source]

what the rss clients I've used do is to let me read the description in their UI, if available, or otherwise just show me the link.

most clients have only a basic support for HTML and (fortunately) zero support for js so this in practice works decently.

however, this requires some additional dependency (either go libraries or runtime programs like w3m) and so it's likely unwanted. It's not a big deal to me, if we add the X-RssGoEmail header I can very easily write something that on a keypress pops up w3m/netsurf/whatever with the link of the feed i'm looking at.

for RSS/atom over gemini it's the same story IMHO.

for gemfeeds thought i think that we can fetch the document and pass it as body of the mail. i can try working on it.