Atom is better than RSS, in ways that matter • Hacker News Board

Re: Atom is better than RSS, in ways that matter

#101

Post by adrianwaj » Mon, Aug 03, 2026, 4:21 AM UTC

Matumio wrote: post #65

adrianwaj wrote: post #46

Both really need an explicit "Full/Partial" flag. Over-polling is also a problem with both formats. But the Local-First Fediverse is evolving. https://share.gemini.google/NHjiUHtpRTiJ That's important and will break the walled gardens, and will change money flows I suspect as advertising revenue is more equitably shared with content providers, who themselves can be better paid for content produced and content promise…

I agree with Gemin— wait. Did you just post a link to google.com to support an argument for self-hosting, decentralization and breaking monopolies...?

"Gemin" I'd support an argument to bring back the "I" to computing. The gem in I.

Perhaps humans need their own APIs for others to then mash-up in the way they please?

For example, I think the goal is to merge all entry fields into a local one that manages and monitors output. I should be able to see and record a stream of everything I do online but I can't. That stream, being a representation of me, is what's valuable. Straits of Hormuz on a person-by-person basis.

How many entry fields are there that you use? email, video, social, crypto, HN, chat, apps... the list goes on. There's a lot of duplicated effort there. Why so many?

I think the whole "One device to rule them all" that I mentioned here [1] is about putting a layer around yourself and letting others interface with you on your terms.

[1] https://news.ycombinator.com/item?id=48912226

local-first >> individual first

Re: Atom is better than RSS, in ways that matter

#102

Post by chrismorgan » Mon, Aug 03, 2026, 9:58 AM UTC

paulddraper wrote: post #95

chrismorgan wrote: post #47

Earlier quoted context omitted.

Consider the title of my article: “Atom is better than RSS, in ways that matter ”. That emphasis belongs there, and it’s mildly bad to lose it. (For presentation on my own site, I also control the line break position on larger screens; but that wouldn’t be appropriate for feeds, where you can’t control the presentation.) We accept that sentences can have formatting, and headings can have formatting, so why shouldn’t…

Because the title appears next to a bunch of other titles. It should be consistent, or else compromise browsing. The content has no such situation.

You haven’t engaged with my second paragraph, or my responses to other responses in this thread. Meaningful inconsistency is already easy with just Unicode, nor does limited HTML make things materially inconsistent.

Re: Atom is better than RSS, in ways that matter

#103

Post by pauladams » Mon, Aug 03, 2026, 12:13 PM UTC

I’m not a developer or publisher, but i am interested in the technicalities.

I get that ATOM is better in terms of being more consistent and the way it handles full content.

Is it true that RSS is simpler, and of you’re not publishing full html articles and other rich content, you don’t need the extra complexity?

Re: Atom is better than RSS, in ways that matter

#104

Post by pauladams » Mon, Aug 03, 2026, 12:27 PM UTC

While we’re on the subject, it would be very cool if HN had feeds for user comments so we could follow each other

Re: Atom is better than RSS, in ways that matter

#105

Post by kevincox » Mon, Aug 03, 2026, 1:31 PM UTC

pauladams wrote: post #103

I’m not a developer or publisher, but i am interested in the technicalities. I get that ATOM is better in terms of being more consistent and the way it handles full content. Is it true that RSS is simpler, and of you’re not publishing full html articles and other rich content, you don’t need the extra complexity?

RSS is no simpler. And in fact when you have to take account the ambiguity of different clients interpreting the sloppy specification differently it just gets more complex.

Even the trivial case of trying to include "&" in a title is ambiguous and different clients will handle it differently.

Re: Atom is better than RSS, in ways that matter

#106

Post by paulddraper » Mon, Aug 03, 2026, 2:18 PM UTC

chrismorgan wrote: post #102

paulddraper wrote: post #95

Earlier quoted context omitted.

Because the title appears next to a bunch of other titles. It should be consistent, or else compromise browsing. The content has no such situation.

You haven’t engaged with my second paragraph, or my responses to other responses in this thread. Meaningful inconsistency is already easy with just Unicode, nor does limited HTML make things materially inconsistent.

While it’s true Unicode pushes the boundaries of “plain text” having a consistent font face, font size, font weight, letter spacing, font color, text wrapping, etc is good.

I don’t want one title 16pt and another 28pt.

Or one Helvetica and the other Arial.

Re: Atom is better than RSS, in ways that matter

#107

Post by pauladams » Mon, Aug 03, 2026, 3:34 PM UTC

kevincox wrote: post #105

pauladams wrote: post #103

I’m not a developer or publisher, but i am interested in the technicalities. I get that ATOM is better in terms of being more consistent and the way it handles full content. Is it true that RSS is simpler, and of you’re not publishing full html articles and other rich content, you don’t need the extra complexity?

RSS is no simpler. And in fact when you have to take account the ambiguity of different clients interpreting the sloppy specification differently it just gets more complex. Even the trivial case of trying to include "&" in a title is ambiguous and different clients will handle it differently.

That’s helpful, thanks for replying

Re: Atom is better than RSS, in ways that matter

#108

Post by qznc » Mon, Aug 03, 2026, 4:10 PM UTC

chrismorgan wrote: post #90

inigyou wrote: post #71

Earlier quoted context omitted.

And those three ways to encode a title. Do I really imagine that every parser is going to undo the double-encoding correctly? Or XHTML conversion if I use a namespace prefix?

… yes? It’s simple XML parsing, and then taking it as text, serialised HTML, or an already-parsed DOM tree. You are using an actual XML parser, right? In most environments it’s no harder, and in browsers themselves (which is where half of it is consumed) it’s arguably easier .

HTML5 is not XML. You don’t need to close your

for example. If I include such valid HTML5 into Atom it is invalid XML. Well, I can use <![CDATA but that is weird too.

Re: Atom is better than RSS, in ways that matter

#109

Post by chrismorgan » Tue, Aug 04, 2026, 2:01 AM UTC

paulddraper wrote: post #106

chrismorgan wrote: post #102

Earlier quoted context omitted.

You haven’t engaged with my second paragraph, or my responses to other responses in this thread. Meaningful inconsistency is already easy with just Unicode, nor does limited HTML make things materially inconsistent.

While it’s true Unicode pushes the boundaries of “plain text” having a consistent font face, font size, font weight, letter spacing, font color, text wrapping, etc is good. I don’t want one title 16pt and another 28pt. Or one Helvetica and the other Arial.

I already addressed that in this ancestor thread.

Re: Atom is better than RSS, in ways that matter

#110

Post by chrismorgan » Tue, Aug 04, 2026, 2:03 AM UTC

qznc wrote: post #108

chrismorgan wrote: post #90

Earlier quoted context omitted.

… yes? It’s simple XML parsing, and then taking it as text, serialised HTML, or an already-parsed DOM tree. You are using an actual XML parser, right? In most environments it’s no harder, and in browsers themselves (which is where half of it is consumed) it’s arguably easier .

HTML5 is not XML. You don’t need to close your for example. If I include such valid HTML5 into Atom it is invalid XML. Well, I can use <![CDATA but that is weird too.

You’re talking about writing it. The question here is reading it.