[ibz]

I am a huge fan of RSS (Atom) and was really hoping for a comeback... I feel like it unfairly died out because of Google Reader's sudden demise and was hoping some new equally popular client to show up and take over. I even spent some time creating one.

But for the past year or so I have been falling down the Nostr rabbit hole. Nostr is a lot like RSS, but it really is better and without getting much more complicated! You can write a Nostr client that simply does what a RSS reader would do (fetch status updates) in a couple of lines without external libraries. And the Nostr ecosystem has been growing so much over the past months, it is getting hard to keep up! It seems to be really getting the momentum I was hoping RSS to regain.

PS: For those that are curious about Nostr and don't know where to start, have a look at the NIPS [1] and of course at the awesome-nostr [2] list on GitHub!

[1]: https://github.com/nostr-protocol/nips [2]: https://github.com/aljazceru/awesome-nostr

[dugite-code]

RSS never really died, most CMS packages still spit out RSS feed that web site owners either don't know exist or don't care to advertise. So you can often find unadvertised feeds all over the internet, but for everything else there are plenty of poling services (hosted or selfhosted) that can generate an RSS feed well enough.

If enough people start using RSS again the icons will show back up on websites again, mainly because it wouldn't be much work to add.

[ibz]

I know. I have built my own RSS reader just so I can follow blogs I like and listen to podcasts. You can certainly find RSS feeds all around the web!

But I still consider it a dying protocol for the simple fact that average people don't seem to care about it anymore and not much seems to be built on it anymore.

The main exception being of course podcasts, which work over RSS!

[j-bos]

And Spotify is trying to kill that too, bring it into the cable/paid subscription model.

[PaulHoule]

Failing RSS readers are still failing with the same failing interfaces that have been failing since 1999 and the strange thing is that there is very little insight about the phenomenon from people who write RSS readers and potential users.

Two perennially unpopular but strangely persistent interfaces are (1) the RSS reader that looks like an email or Usenet (dead) reader. The cause of death here is the "mark as read" button that makes every item the system ingests a burden to the reader -- for all this click, click, clicking the system is not gathering any information about the feed items or the user's preferences and (2) the RSS reader that renders 200 separate lists for 200 separate RSS feeds. If your plan is to scan, scan, and scan some more, why not just visit the actual web sites?

Contrast that to the successful interface of Twitter where new content displaces old content, where if you walk away for a week you see recent content and don't need to click, click and click to mark a week's worth of content as read (though there hopefully is a button to nuke everything.) And now there is Tik Tok and RSS readers still barrel on as if the last 15 years didn't happen.

RSS needs algorithmic feeds to really be superior to "I have a list of 50 blogs I check every morning." That is, you have to be able to ingest more feed items than you can handle and have the important and interesting stuff float to the top.

I was involved a bit in text classification research 20 years ago and it was clear to me that an algorithmic feed for RSS was very possible with the caveat that it would take a few 1000 judgements yet even at that time it was clear that you could never underestimate people's laziness when it comes to making training sets. Most people would expect to give five or so judgements.

I had thought about the problem for years, a bit about ideas that would improve low-judgement performance, but I did very little other than this project

https://ontology2.com/essays/HackerNewsForHackers/

and

https://ontology2.com/essays/ClassifyingHackerNewsArticles/

Last December I started working on YOShInOn, my smart RSS reader and intelligent agent with a primary user interface that looks like "TikTok for text" (no wasted clicks to 'mark as read' because I am always collecting preference information.) I started out with the same model from the article above (applied to the whole RSS snippet as opposed to just the title) and upgraded to a BERT-based model.

It shows me the top 5% of about 3000 ingested articles a day.

I am still thinking about how to productize it. On an intellectual level I'm interested in the problem with training on fewer examples. Ironically it wouldn't be hard to do experiments because I have a year of data I can sample from, but I couldn't care less on a practical level because I have 50,000 judgements already... And it is all about "pain driven development" where I work on features that I want right now for me.

If I were going to make a SaaS version of it would almost certainly fall back on collaborative filtering (pooling preferences from multiple users) because users would perceive it to learn more quickly.

See the entirely forgotten https://en.wikipedia.org/wiki/StumbleUpon

[coldpie]

Have you tried Feedly? One of the sort options is "most popular", although I'm not sure how that works. Older unread stuff ages out automatically after about a month.

[PaulHoule]

Popularity is a useful metric for ranking (if A is more popular than B it is more likely I’ll like A better than B than if it is the other way around.) but combining it with a relevance score can be tricky. (e.g. it is not so straightforward to incorporate PageRank into a web search engine and really get better results.)

The interesting thing I see in Feedly is it seems to have a broad categorization: you might get some topic like “American Football”. I think users will certainly feel more in control if they can pick topics like that.

YOShInOn does ingest categories that are supplied by the feeds. I’ve also thought about adding a query language inspired by OWL (contains word X or word Y and is not a member of category Z) but now when I want to do a query I hand code it. If there is ever a “YOshInOn Enterprise Edition” it will have some system for maintaining multiple categorizations so it will be able to put labels like “American Football” on.

[hiAndrewQuinn]

Ah, I was hoping to find a drop in replacement for RSS, but Nostr looks more like some kind of Twitter clone in protocol form.

[ibz]

Not really. Twitter clones are one application indeed, but I see it more like RSS on steroids.

[SuperHeavy256]

What do you use nostr for? Forgive my ignorance but, does it have uses beyond being a twitter replacement?

[ibz]

I am currently building 2 things on Nostr:

* a marketplace (sort of like eEay) where you can buy/sell items for a fixed price or as auctions

* a CMS you can use to host your own website (sort of like Jekyll, but without the build step, and with an admin interface)

People build all sorts of things though!

The most notable things that people are trying to build (it didn't happen yet though) is a GutHub replacement, because Jack Dorsey famously said he will give 10 BTC to whoever does it first.

[Retr0id]

I dipped my toes into nostr recently, and I was struck by the fact that content on nostr does not have a canonical location. IIUC, you have to know which relay(s) have what you're looking for, and if you don't, you just have to guess. Ostensibly this is a win for censorship-resistance, but it doesn't seem very practical to me.

Has this caused you any issues with your projects?

[treyd]

That's in-line with my general criticism of Nostr. It's a very simple protocol that imposes too little structure on downstream software so you get a kind of impedance mismatch (so to speak) at the messaging layer. There's not a lot provided for ensuring reliable delivery so the strategy will evolve to just broadcast to as many relays as possible and accept the duplicated effort (which will have to be paid for by somebody). It also doesn't have a good story with regard to identity management and key compromise. It's neat and useful for some applications but people think it's some amazing new advancement when it's not. Its something very simple that we could have easily invented in the 90s, but we didn't because it's kinda a shaky architecture to build applications on top of. It's too simple.

[ibz]

Indeed, too many people think Nostr will somehow magically solve everything... I think of it just like RSS on steroids - which is why I even mentioned it in this thread.

[ibz]

This is indeed one of the issues I still didn't fully wrap my head around!

Currently clients just use the same bunch of relays as defaults, and let you (maybe) customize the relays you want to connect to.

I think this is sub-optimal for another reason, besides the one you mentioned (discoverability?): you don't necessarily control where your data is stored, and these relays might disappear without notice. It is a great way to broadcast status updates, but not great for having an archive of your own data, that you can trust.

I assume this will change eventually, with paid relays, which will have the incentive to keep your data around, OR personal relays - which is what I am building as part of my CMS - basically I want all my data to have one "canonical" location (my domain) and be hosted on my VPS, which also serves my data as a web page with RSS... this helps me wrap my head around where my data is stored, and know that I always have a copy of it... but doesn't solve the discoverability issue, I guess, which ... IDK, it seems to be solved using just a "shotgun" approach: mostly publishing to well know relays.

[KoftaBob]

See my comment here explaining how Nostr aims to solve this: https://news.ycombinator.com/item?id=38346741

[janandonly]

I would love to read/hear more about this NOSTR based CMS. Do you have a website or nostr channel I can follow to hear about a alpha/beta launch date?

[ibz]

Just a GitHub. [1]

It's very early days still, but I use it myself.

The marketplace [2] is much more advanced! You can already use it to buy and sell stuff over Nostr!

[1] https://github.com/servuscms/servus [2] https://github.com/PlebeianTech/plebeian-market

[KoftaBob]

> IIUC, you have to know which relay(s) have what you're looking for, and if you don't, you just have to guess.

This problem is tackled by an improvement to the protocol that was recently introduced called "NIP-65": https://github.com/nostr-protocol/nips/blob/master/65.md

The TLDR is that when a Nostr client supports NIP-65, it broadcasts to all known relays (which is continually updated/expanded) the list of relays that User A posts their stuff to.

This means that as long as User B is connected to at least one of those "all known relays", their client now knows what relays User A posts their stuff to, and will specifically fetch things from those relays when it needs to load User A's things.

It's essentially the Nostr take on the Gossip protocol: https://en.wikipedia.org/wiki/Gossip_protocol

[al_borland]

I think the fall of Twitter, and other social media sites, is good for RSS… assuming its functionality is made known. A significant number of people are on those sites just to get news from various sources in one place. That’s literally what RSS was made for.

Podcasts are also more popular than ever, and last I knew, the entire podcast world was backed by RSS. All the podcast apps are purpose built RSS readers designed around audio.

[pbronez]

Does the Nostr community have an opinion on key management? The FAQ says:

“How do I find people to follow? First, you must know them and get their public key somehow, either by asking or by seeing it referenced somewhere.”

You can do a lot of cool things if you start by assuming everyone has a strong identity communicated via key pairs. The trick is managing those keys… discovery, validation, revocation, etc.

Keybase was (is?) amazing for this. They couldn’t figure out the business model though, and it’s a zombie since the Zoom acquisition. Keys.pub tried a more open implementation, but has been discontinued.

[withinboredom]

https://github.com/withinboredom.gpg and replace the username. If they have commit signing configured, they have keys, and then they (probably) can decrypt with that key.

[rglullis]

https://keyoxide.org/ seems to be successor to keybase.

[IshKebab]

I read some of those links but it's like it's actively trying to avoid telling me what Nostr is.

It's never going to succeed if you have to do extensive research to find out what it's even trying to do.

[mro_name]

https://seppo.social/demo is a microblog server (I am building) combining ActivityPub and Atom.

I agree Atom is here to stay.

[callalex]

It wasn’t just the death of Google Reader. It was also the death of the creator and top promoter of RSS who was unjustly killed by the copyright mafia. RIP Aaron Schwartz.