
Ask HN: If you were to design the RSS today, how would you do it? - deepakkarki
I&#x27;m looking at discussing the current limitations, when RSS works and when it doesn&#x27;t. More importantly how would you design a better (more powerful) system today - while maintaining the decentralised ethos of RSS.
======
lj3
I'd build it somewhere in between what it is now and Usenet. One of the
biggest benefits of RSS is how easy it is to publish content. Two of the
biggest downsides is the lack of interactivity and the lack of
discoverability. What if all of the rss readers spoke to each other? What if
you could see which feeds people were reading? What if you could add a comment
to a particular post and have a discussion with other people who are reading
it? What if you could be notified of updates to certain conversations the same
way you're notified of updates to your feeds? A killfile will solve the issue
of not seeing unwanted content or people. Maybe go with a federated model
instead of peer to peer, so that the servers could scrape the internet for RSS
content. That way discoverability isn't just limited to what you and your
friends are already reading. Maybe use Cap'n Proto as the app-to-app wire
protocol instead of http for real-time updates.

> Decouple it a bit more from html

Is that really possible? I've considered it quite a lot in the past few years,
but I can never get past the fact that it has become the universal markup
language. Even markdown converts to HTML before displaying (so it can by
styled with CSS).

~~~
kristoff_it
One could argue that allowing markup at all in RSS fields might be an anti-
pattern.

~~~
lj3
Not successfully. By far the biggest advantage of RSS is its so easy to
publish content to a feed. The more difficult we make that, the more we shoot
ourselves in the foot.

------
pjotr99
Use JSON instead of XML. Well some guys already build it.
[https://jsonfeed.org](https://jsonfeed.org)

~~~
quickthrower2
What's wrong with XML?

~~~
twobyfour
Verbose, unwieldy, harder to read by humans (especially without syntax
highlighting) in terms of picking out key data. More unwieldy to write in most
languages as well (most now have libraries that will convert a dictionary
structure to [or from] JSON in a single call, while XML often still needs to
be assembled element by element).

I think it would be an exaggeration to say that there's anything "wrong" with
XML, but there's a reason JSON has by far overtaken it outside of "enterprise"
applications.

That said, in some ways XML is preferable for standards - particularly in that
there's a standard way to publish a document type specification, and widely
available tools for validating a document against such specifications. The
somewhat experimental equivalents for JSON haven't really ever caught on.

~~~
rurban
Also slower and insecure. JSON is the defacto interop standard over the line.

~~~
twobyfour
How is JSON any more secure than XML?

And no, XML is just as much a standard (in fact, a better defined one as a
formal standard), and is still very much the default in most enterprise
applications. JSON being more common in startup land doesn't make XML not a
standard.

------
kristoff_it
Decouple it a bit more from html, too many RSS feeds contain html
description/title fields. It's annoying both when you're showing them in a
html page and when you're showing them in a native application.

------
bmn__
RSS is a piece of shit.
<[http://web.archive.org/web/2004/http://diveintomark.org/arch...](http://web.archive.org/web/2004/http://diveintomark.org/archives/2004/02/04/incompatible-
rss>)

Atom was invented as a replacement because nothing could be salvaged from the
multitude of original RSS specifications. See RFCs 4287 and 5023.

------
1123581321
It would be nice to be able to declare endpoints for structured responses to
items. I'd like to be able to thumbs up/down or rate articles in a client and
have it go back to the publisher in addition to helping me customize what I
read.

