RSS has got to be the thing that Hacker News loves the most that every non-tech person on Earth doesn't care about. So many techies love this model of designing their feed and collating what content they consume, while the quickest growing social network's entire pitch (TikTok) is "we'll deliver you what you want without you having to follow anyone".
Podcasts seem quite popular among non-tech people. The national over-the-air radio station in this country even has an entire weekly show dedicated to helping people find new podcasts to subscribe to. It appears non-tech folk do actually enjoy this model of designing their feed as much as anyone else.
Indeed, non-techies don't actually care that it is RSS under the hood, but I'm not sure techies really care either. It is the high level concept of what RSS embodies that is really being talked about. RSS merely gets suggested because it is an already defined standard that gets us there. No need for a 15th competing standard.
RSS mainly failed because the predominant model for funding content creation is ads. Sadly, RSS is a poor medium for ads—to get more revenue, content creators were incentivized to bring users to their own sites rather than syndicating rich or useful feeds.
There’s a lot that goes into the success of social media over the last couple decades and figuring out the best ad revenue models was a big part of it.
Nah it's much simpler. The reason RSS failed is because Google killed Reader so they could push content creators to Google+.
That in turn led to other companies with the ability to set things at the time gradually deprecating and removing their build-in feed readers (thanks Mozilla, thanks Apple) and the result is that RSS "failed".
It didn't fail, it was murdered so Google could promote their failed social media network.
I wonder if Google+ could've succeeded if Google had evolved it from Reader somehow. Start with the product people are actually using, develop it until it's the product you want people to use?
At the time, several of us were telling our friends working at Google to start from Reader comments. It was already a functional and somewhat popular social network.
Instead of that, they removed the comments and replaced them with something worse that no one ended up using.
Google should have built out Reader as its Twitter competitors, and Google+ as a separate Facebook competitor.
The former would be a more impersonal source of information and discussion, whereas the latter would have been where you put your personal connections.
Unfortunately Google wanted to do both in the same product, and thought that Circles would be sufficient to create the distinction, but the kind of stuff someone might want to expose to an impersonal connection is drastically different from the kind of stuff they want to expose to personal connections, to the point that they should arguably have completely different UIs.
Circles seems like the sort of feature that would appeal to power users (and indeed I remember a bunch of academic type people using Google+?) But most users are not power users and don't want to do a bunch of thinking about what circle each contact belongs to.
Nevertheless it seems to me like the network effect was the main thing, and Reader could've been a huge step there.
If RSS really were popular, you would expect Google closing Reader to spur Mozilla and Apple to put even more work in maintaining their RSS readers, to attract people to them.
However, RSS was never very popular outside some small tech circles, and Mozilla and Apple saw that the same way that Google did.
That assumes that Mozilla and Apple were capable of doing those things in that time period.
Mozilla is nothing more than controlled opposition that Google can prop up and say "See, we're not a totally monopoly" while Apple at the time could see nothing beyond the piles of money that the iPhone was making them, to the point where even their desktop/laptop lines suffered.
Are you sure this is true? RSS failed because people stopped using feed readers. I stopped using a feed reader because there was an explosion of content and managing with a reader just didn't scale. I was happy to outsource curation. It was a "hair on fire" problem
This was my experience as well. Opera 12 was my browser of choice because of the built-in feed reader. There were several times where I exported my feeds to an .opml file and started over, because I was inundated with updates and following way too many blogs.
I still have these exports, backed up to a CD somewhere.
Yes. After my comment I started thinking more about the experience at the time. It was always fun adding new feeds until you have too many. The hard word comes at deciding what to prune. It isn't even just about time, it's about not being able to figure out what to get rid of. Like a closet filling up with clothes and you wear them all. You know you just can't add more but figuring out what to unload is painful. Maybe this is a good case for clothing rental services.
Edit: actually I would say its more like an infinite closet but the more clothes you had the longer it takes to find something to wear the next day until things becoming unbearable and you just close the door to your closet, lock it and then rent clothing for the rest of your life.
This is true, but there was no reason that RSS readers themselves could not present you with a curated feed built both out of your subscriptions as well as global feeds, imitating what Twitter already does.
I dunno, I fetch roughly 10 per second which isn't a lot. It takes less than an hour to fetch 30 000. If one would do a bit of logic based on pubDate intervals and slow the process to 24 hours you could "hammer" a sub set more aggressively and still be fine on a modest desktop.
Cutting off the obvious revenue source may be a feature: some people want personal connection, explicitly devoid of commercial interest.
It, of course, limits the medium to, well, social media proper, peers talking among themselves for the enjoyment, not making it a full-time job. It pushes for-profit stars elsewhere.
It of course does not solve the problem of hidden ads ("shilling"), product placement, etc, in more popular feeds.
There is certainly room for strictly non-commercial communication, where the value is in the human connection (talking to friends) or fame (being a local luminary). But certainly it's not going to be a medium fitting for everyone, and for al types of content.
Daring Fireball has ads in the RSS feed[1]. If RSS was more successful, we could imagine services, marketplaces for that model. Of course the same personalization you have on the web wouldn't be possible, but maybe in some ways it would be better, because you would know that everyone else sees the same ad, creating common ground[2].
I'm finding increasingly harder to follow some podcasts as well.
More and more are centering their distribution through Spotify. Reason: money. Either to fund the minimum needed or to give them some margin that Patreon or similar methods are not able to.
Another Hacker News thing is the middle-brow dismissal.
It's not really a fair comparison between a centralized product optimized for engagement and a distributed protocol that can be used in lots of different ways. Sure, the world doesn't care about RSS, that's pretty much the easiest strawman to come up with. On the other side though, it's not a foregone conclusion that what the world wants is to be mindlessly entertained by the algorithm of a faceless corporation. At this point TikTok is the new hot, but there is a long history of youth culture rebelling against corporate tastemakers, so it doesn't seem outrageous to assume that the next big thing will involve some measure of curation.
I don’t have anything against RSS, I think it’s a useful protocol that fills a niche. I do however think that it’s just that: a niche. If you read through the other comments on this and other historical posts it’s presented as a panacea to the “algorithm of a faceless corporation”, where the ills of social media could all be resolved if RSS was just more widely adopted. There’s a lot of trends you can bet on in tech and in tastes, but any action that requires active effort (including all forms of curation) will be outcompeted by something that automatically does it for you. For every German programmer reveling in fine grained control there’s a thousand people in India opening YouTube for the first time and just watching recommended.
There's a paradox at play. Or maybe a distortion in our thinking.
I like my niche. You like your niche. My family, colleagues and
friends like their little niches. Ask around and you'll find that
everybody, barring a small slice of 13 year old's who talk about "what
everybody is doing", is quite happy in their niche. Indeed that's what
social media is all about. If everybody was 13 and wanted to attend
the universal party, and not be "left out", we'd switch back to
broadcast technologies.
It leads me to the conclusion that the mentality around social media
is really that of an insecure teenager, and that it's caused society
some degree of arrested development.
The only rss feed reader I have used that hasn’t gone away or become sketchy is thunderbird, and it’s not a great ux (I haven’t used it in a while, maybe I’m wrong)
RSS seems like great tech but it doesn’t have great user facing apps (that is easy to find at least) to support it
At the risk of sounding like a shill, have you tried Feedly? (feedly.com)
I switched over to it ages ago after the death of google reader, and it's held up remarkably well for me, and now also includes welcome features for, e.g., intaking email newsletters, conducting automatic content-specific web searches, etc into the same RSS-reader UI.
I'm gonna have to give this a thumbs up for use too. I'm not a fan of it being propritary, or tied to a web service, but it works amazingly well for what it is.
I'm still hunting for a good self-hosted or offline alternative, but till then, Feedly really does cover that gap.
Feedbro is also a very good choice for reading RSS feeds. Best of all, you could configure it to get the full article from the web site itself and show it in the preview pane.
Agreed, hence the importance of treating RSS as an implementation detail rather than a user-facing feature. I'd also love to see more reading apps experiment with algorithmic recommendation too; that's been one of my own focuses for a while.
Email would fit that description too I think. I can talk SMTP over telnet manually, but most people just want to crack open Outlook or Gmail and fire off a quick reply.
Something that uses RSS but doesn't go on about using RSS would go down well I imagine. It works like this for podcasts for example.
Same with mastodon and all the other decentralised stuff. Nobody cares about the nerd bit! Market to the mainstream and let hackers hack. The only thing you need to do differently to improve things is reject the desire to wall up your garden when you're succeeding.
I think this is the key point. Because saying "this is what you want" hides a part of the problem: who says it.
The implication is that when you chose what you want you are in control. You may miss stuff, but you are the one deciding. When, on the other hand, it is chosen for you, the algorithm may be the best ever but you're not in control.
For some people "being the decider" is more important than for some others.
Technological implementation details aside, the single biggest issue I have with Mastodon as a replacement for the Twitter-shaped hole in my media universe, is that it has no extant established functional scalable utilized replacement for the distillation of a single feed,
specifically one which has a meticulously crafted "algorithm" aka secrket sauce for comprising posts from sources I have chosen to follow, to universally trending events, with a strong attention to network and correlated interests within it.
This is hard work and is indeed a sekret sauce.
And despite how abused it was, e.g. to drive engagement-through-enragement, and, as with the pathological death-spiral cases of Facebook and Instagram, how corrupted by paid-for and otherwise placed content, it was effective at constantly exposing me to things RSS does not and AFAIK cannot:
things I want to see but don't know to ask for.
Whoever cracks this for Mastodon in a fashion that plays well with the established norms around control, is liable to make a small fortune.
Much smaller than in a non-federated, centralized universe, that captures a broad audience...
Its a question of whether you are happy to be a passive bystander in your own life, or are self-directed.
Corporations, governments, etc, are most happy with passive bystanders. They encourage this behaviour, and train people to be this way (deferring to authority figures, etc) as it makes everyone more regular and easier to manage.
The self-directed individual however, rejects this sort of entrainment. They would prefer to receive various information directly and in an un-intermediated fashion, so that they are able to make up their own mind.
I like the comment, but how is this different pattern of information consumption than, say, buying your favorite zine, compared to reading a newspaper or whatever Condé Nast says is worth printing?
Of course, we have new modes of distribution and production, but whose to say Tik-Tok can ‘define’ what you want in order to give it? (A la. You can have any color you want so long as it’s black).
So there are people who watch broadcast TV or what’s “hot” or “trending”, or other well defined products (Star Trek, not Star Wars, parody fiction).
And then there are people whose entertainment involves choice, refinement of taste, and discernment. Plus a bit of the more plentiful Star Wars parody fiction.
It boils down to the distinction between people who:
1. want to get content precisely tailored to their interests (high signal to noise ratio), at the expense od time invested in finding and curating sources and limited chances od discovering news stuff.
2. want to get content quickly, without much of the hassle at the expense of potential spam/uninteresting stuff.
Something like turning the radio om vs gathering and playing own records collection.
This is interesting because TikTok has the uncanny ability to both do 1 and 2. It brings you content precisely tailored to your interests via the algorithm, and it does so in a fast way (some might say too fast). I guess the general audience wants the same two things except they place even less weight on manual curation.
Does it? I suppose TikTok did a good job of recognizing what I was interested in during the first day or two of using it, but now it keeps pushing that same content to me even though I've long moved on to new interests. You can only watch variations on the same video over and over so many times before it gets really old.
For the sake of discussion I opened the app again to see if anything had changed since I last used it. Still, I got the same kind of content that bored me away from the app last time. I'm not sure that's all that uncanny. Pretty much what you'd expect from a mediocre algorithm.
I don't really see RSS as being a curation channel as much as a notification channel, though. What RSS provides is a means to notify you when 'professional' curators have curated new content for you.
With tiktok, you have recommendation engine and following in one. With the open web, you can use HN as a recommendation engine and a feed reader to follow specific blogs.
TikTok used to be called musical.ly and was a platform for publishing short playback lip-sync and dance videos. If you're dead-set on naming an intellectual relative among 'western' apps/sites, Vine would be the closest fit (which was basically Twitter for videos and, appropriately, purchased by Twitter and later shut down).
There’s no money in an email list (in itself) and yet it can be valuable. I think it’s all about growing an audience. Maybe there’s a long tail of people who miss RSS.
and what's wrong with that? why can we have both RSS for people who like it, and TikTok for people who like TikTok? Are you saying everyone should dumb themselves down into the fastest growing fad of this year, or people can have different preferences?
I've made quite a few comments before on HN about how I have come to use RSS feeds- essentially as a way to distribute highlights rather than distributing entire articles or previews of entire articles with a meaningless blurb in the feed item body.
I curate RSS feeds on specific topics[1] and populate them with highlights from what I'm reading from across the internet- this can be a literal highlight from an article, a comment on HN, Reddit etc., a Kindle highlight from a book, anything really, as long as it is on-topic.
There is always a link back to the original context for subscribers to dig in deeper if they want to.
I think this is a real sweet spot. I cannot go back to feeds of anything and everything, a hodge-podge mixture of bad one-paragraph summaries or overwhelmingly long RSS item bodies.
I want to know what exactly grabbed somebody's attention that made them think that something was worth sharing, what gripped them about it, and if it also grips me, I'll gladly go to the original context and read further to my heart's content.
But I don't want a never ending queue of things that I have to put an outsized amount of effort into filtering through to even answer the question "is this something that interests me?"
With the explosion of Mastodon I also added the ability for my RSS subscribers to comment on RSS items from my feed using their Mastodon accounts. So far, so good!
In addition to improving usability, it defeats attempts to measure clickbait summary efficacy, etc., since it breaks sites' ability to pull popularity / telemetry info.
I have used Diigo for a long time in a similar way - bookmarks are useless, and I only remember the sentences in the links I’m after, not the url, plus tagging them.
This seems like a much cleaner setup and can feed into indieweb as well.
Thanks for sharing, I wouldn’t have gone looking for this.
If somebody from Diigo is reading this: Why is there no content on the frontpage? It's a sleeping social network that could generate many more subscriptions.
The Share section could offer a feed of all content that users are willing to share publicly. There could be support for ActivityPub to make it a worthwhile investment of time.
It should be a better sales channel to get new users hooked on good content first instead of forcing them to commit to a new account before trying anything.
>I also added the ability for my RSS subscribers to comment on RSS items from my feed using their Mastodon accounts
How does it work? Looking at a feed.rss file, I don't see any links to Mastodon posts.
>I curate RSS feeds on specific topics
>I think this is a real sweet spot. I cannot go back to feeds of anything and everything, a hodge-podge mixture of bad one-paragraph summaries or overwhelmingly long RSS item bodies.
It is the sweet spot when it comes to consuming your feed on its own.
In the context of other feeds, and you may have resolved it with Mastodon feedback, it still takes some time to find the best links in your feed. That's a quality on its own, so please don't feel pressured for change. However, these points would make it sweeter for me:
* Showing the most popular highlights of the week, month and year, by user vote and by the popularity of the main article on social networks, as well as your personal favorites.
* Find like-minded collectors who have included the same highlight or for further drill-down, a set of highlights.
* It would also be interesting to see a note from you why you have selected a highlight, when that's appropriate. Further tags that could be used for sorting and ranking would also be nice.
It uses a "just in time" model to create a Mastodon post if it doesn't already exist when a user clicks on the "Comment" link (it also does a bunch of other stuff to handle truncation, fitting within the submission limits of the instance, making space for source links etc).
I think it's important to try and be a good citizen on Mastodon instances run by volunteers and minimize unnecessary load. The reality is that not everyone is going to want to comment on every single item in a feed, so in my mind there is no point trying to having a 1/1 parity between RSS items and Mastodon points.
Comments initiated by subscribers are posted on Mastodon with the "unlisted" visibility so they don't spam the public discoverability features in the instance timeline, but can be boosted by the curator at their discretion. The commenting user can also boost the highlight on their instance if they wish.
> It would also be interesting to see a note from you why you have selected a highlight, when that's appropriate.
I do this sometimes[1] - curators have an option to post a highlight directly to the public feed of their instance (ie. not unlisted), and then reply to that themselves with notes.
I think I'm a little overdue in writing a blog post about this new feature! Stay tuned for a submission on HN hopefully sometime in the next week!
I will wait for your post, but if you want to know what is still unclear to me:
>>for my RSS subscribers
>It uses a "just in time" model to create a Mastodon post
What is 'It'? notado.app for people who have logged in? There is no links to comments when not logged in. How can new users or people who don't want to create an account discover the comments?
>no point trying to having a 1/1 parity between RSS items and Mastodon points.
To me, the interesting part would be an n/1 relation: One comment section where everybody from all RSS streams can meet to discuss an article. Like HN/new, there is no incentive to comment on a 3 day old post because hardly anybody will read it. The economics change if the comment section can appear on various RSS streams because then, there can be readers and replies to a comment even years later.
Is it acceptable or even desirable to share your mastodon comment sections, or do you see them as a place for the people who follow you?
> How can new users or people who don't want to create an account discover the comments?
The links to initiate new comments on the public HTML versions of the feeds show only for people who are logged in, because unfortunately bots and scrapers are not as respectful as they should be.
As a user's feed homepage is designed to be shared publicly, it only takes one bad actor to click on every "Discuss on Mastodon" link for every item in all of a curator's feeds and put undue load on a Mastodon instance which makes the whole "just in time" approach moot.
Where Mastodon posts have already been created for discussion (by authed users, or by any users subscribed directly to the RSS versions of the feeds), those links (ie. to the Mastodon posts) get shown on the public HTML versions of the feeds.[1]
Otherwise, anyone who subscribes to the public RSS version of the feed (unauthed by default, doesn't require an account etc.) is presented with a "Discuss on Mastodon" link at the end of each RSS item on any feed for which the curator decides to enable comments, and this link can be used to initiate new comments/discussions with a Mastodon identity.
> One comment section where everybody from all RSS streams can meet to discuss an article
This isn't really something I'm interested in for Notado, but I wouldn't be surprised if someone sees your comment and runs with this idea!
> The economics change if the comment section can appear on various RSS streams because then, there can be readers and replies to a comment even years later.
It's not quite the same as what you're suggesting, but I am thinking of providing an API for https://kulli.sh where article authors can embed comments on their articles from across all supported platforms at the bottom of their articles. This could go a long way towards keeping discussions fresh regardless of the time that passes since the initial submission due to comments being embedded with the source.
I just need to really sit down and work out a pricing model (or maybe separate models for individuals vs organizations) for the whole thing.
> Is it acceptable or even desirable to share your mastodon comment sections, or do you see them as a place for the people who follow you?
I think this depends entirely on the curator. I personally don't have any issues with mine being shared more widely, but there are settings that I've made available to allow people to restrict comments to approved followers (on Mastodon).
The nice thing about the Mastodon API is that if you enable public comments, you can filter for your posts that have been created by the "Notado Feeds" OAuth app, and then filter again by posts that have >N replies, and then embed those discussions on your personal website (or anywhere else).
You definitely have thought this through. Is there a reason that you don't have a page with the posts with >N replies, or the posts with the most recent replies, available on the notado.app?
I prefer the substack model personally: full article with a link to the substack at the top and bottom. I feel a bit yanked around otherwise, speaking for myself anyway
What would be the benefit of this, really? Easier consumption, I suppose, but RSS is a read-only protocol, and allows no participation. Users would still depend on centralized services to publish content, and there's little to no chance that these companies would interoperate using a standard protocol. Not only that, but why would a centralized service that depends on ads and promoted content allow you to use an open format to consume it? They _want_ to keep you on their platform as long as possible.
What decentralized protocols try to solve, and what the centralized web has failed us with, is data ownership. Users should have full control over the data they produce, and be free to migrate it to any other node without losing access to the service they're interested in.
Mind you, I don't think social media is worth reinventing. Connecting everyone on the planet is wrong on a societal level. But P2P services are a good fit for building smaller communities, which is a crucial missing component of the design of the WWW. I'm still hopeful that something built for the masses can take over the current mess we're in.
Easier consumption is pretty much it, yes. Specifically, it'd make it easier to stay engaged with publishers and communities even if they aren't part of a centralized platform, which means that people who develop publishing and community apps will have an easier time growing their user base.
> Users would still depend on centralized services to publish content, and there's little to no chance that these companies would interoperate using a standard protocol.
All you need is a blog/newsletter platform like substack, ghost, wordpress etc. They may not aggregate your social posts into another feed for you, but you can use a separate service to generate and host the feed, then link to it from your main site.
> Users should have full control over the data they produce, and be free to migrate it to any other node without losing access to the service they're interested in.
I mentioned in another post I added the ability to comment on my items from RSS feeds with Mastodon accounts recently. Sure, it's not part of the protocol, but it does the job without any fuss and people who want to interact with me (the majority of them are on Mastodon, I guess this is the key point) in the context of certain RSS feed items can do so very easily.
Do you support web mentions as well? That was the first attempt at adding social to RSS, ActivityPub is very similar with an angle to federation instead of self hosting
Honestly I don't know much about web mentions. It would be very cool however, if when I add a HN/Reddit/Twitter/Mastodon comment by somebody to a curated feed, that that person could be notified by a web mention. From my limited understanding, though, I think this would require web mentions to be implemented wherever the comment/highlight originated from?
I like to think that I'm pretty technically competent, but I really struggle to understand a lot of the standards/protocols that the fediverse/indieweb is built on...
Well you're wrong that it doesn't allow participation. It just separates read from write. Participation can be in the form of additional feeds. It can be in the form of a feed remixer (moderation or aggregation).
I’ve always thought a social api built on email as the transport and mailing lists for organization would be ideal. The infrastructure is there and scales.
I would mostly agree with these ideas if only there wouldn't be one large obstacle in the face of having RSS publishing and consuming be considered "social media": the main tenet that makes social media, well "social", is the consumers' ability to interact with the content they're consuming. If the plan is missing that essential component, then it's not "social" media, it's perhaps a better way of consuming and aggregating media, but that's it.
If you want to bolt interactivity on top of RSS then my question is why use an XML document with a very limited vocabulary when you can have a JSON document with a wide (and extensible) vocabulary in the form of ActivityPub. (I don't mean to imply that the later is perfect, but it's a better fit than RSS). An ActivityPub actor's Outbox is exactly an RSS feed by a different name. Instead of a list of "content" items, it has a list of "interactions" the actor had with the rest of the ActivityPub ecosystem, but once you reach the interactions which signal new content, you get that RSS feed experience.
> If you want to bolt interactivity on top of RSS then my question is why use an XML document with a very limited vocabulary when you can have a JSON document with a wide (and extensible) vocabulary
Quite ironic reading this. Do you know what the "X" in XML stands for?
However in ActivityPub extensibility is specifically mentioned in the growing of the vocabulary to cover areas that the initial specification doesn't include (the way some members of the community created source forge related objects and activities).
XML is a data interchange format specification that allows extensibility.
RSS is a protocol specification on top of XML. Whether the underlying data interchange format is XML or JSON doesn't restrict extensibility. XML namespaces are designed explicitly around the idea that document schemas can be embedded and remixed.
Ultimately, the mode and points of extensibility is a function of the design of the protocol and not the data format.
ActivityPub wouldn't be more or less extensible had it been built on XML instead of JSON (you can make the case that it would be a less wire efficient implementation on XML).
I know that XML is extensible, but my impression was that RSS and Atom are not (hence why Atom superseeded RSS) but looking at the specs it looks like they might allow for some improvement.
The last version of RSS actually specifically calls out that the spec is effectively frozen with the expectation that new features and vocabularies can be added in as modules
In this proposal, interactivity would happen within the community apps (discord, slack, forums, whatever new ones are built in the future) and not over the protocol. You use a reading app to get a feed with posts with the various communities you're in, and if you want to leave a reply/reaction, you click on the post and get switched to the relevant app/website.
ActivityPub was explicitly designed as a successor to OStatus, which was built on Atom and Pubsubhubbub (now websub), which was a successor technology to RSS (AP also integrated lots of fundamental design concepts from pump.io, which was an intermediate step between OStatus and AP). The RDF vocabulary it uses still has roots in the same RDF vocabulary used for OStatus (ActivityStreams 1).
Though it looks like ActivityPub is push, and RSS is pull. But one should be able to construct transformers between the formats of ActivityPub and RSS/Atom.
Good read! Aligns a lot with everything happening with the IndieWeb community[1] (including social readers[2]) and what I'm working on with Haven[3]. The additional piece (I know, more parts make everything harder for everyone) is using these tools for _private_ sharing. That's been my focus--publishing RSS with http basic auth for access control--while keeping subscribing as simple as copy/pasting a URL or using a browser extension that recognizes RSS auto-discovery[4].
Thanks--and I'm glad to hear you're working on access control. My current approach to that hairball has been basically to work on everything else first and think about it later. Maybe it's not actually a hairball, but the fear of it being one has been enough to keep me from thinking about it.
The only problem when I used any of these RSS feed readers is that the signal to noise ratio is pretty bad. I always get notified of topics I do not really care about (Liking a particular website does not mean everything they put up will be relevant and interesting). That's when I found HN and it resonated well.
There’s an upper bound to SNR for non-algorithmic feeds. You can of course rely on human curation but then you rely on unpaid labor or you’re back with ads again. Podcasts went very much that way, for instance.
I think non-algorithmic is a great baseline, HN and certain other communities are proof that it still works. There’s also a benefit of “everyone having seen the same stuff”, leading to interesting meta-conversations. This is the same “lost shared experiences” of only having one tv channel that old timers talk about, and it’s very real.
That said, there’s nothing inherently bad or destructive with algorithmic curation. What sucks is that we have no insight or control of them. If there was an open marketplace of curation algorithms, we’d be in a pretty good place.
I've built Movim (https://movim.eu) on top of that and many users have already access to thousands of articles daily, pushed in real-time in their timelines.
> My main idea here is that every reading app should let you create shareable links where people can subscribe to an RSS feed and sign up for the reading app at the same time. If I want to invite people to join my community or subscribe to my social feed, I give them one of these shareable links.
This is close to the way podcasts work now, and it kind of sucks. I was just looking at a show on the Apple Podcasts site (because it was the first result that showed up in the search results), and it has social media sharing buttons for Facebook and Twitter and an icon to copy some markup to embed an iframe-based player. If you are not Facebook or Twitter or looking to embed an iframe, too bad. The reverse sucks as well: when I'm on the site of the podcast itself, and it gives me a bunch of options to subscribe using Apple Podcasts or Google Podcasts or watch on YouTube. If you use something else to consume podcasts, your best bet is to copy the link to the bare RSS feed and put that in. Problem is, some sites omit that one.
This is one thing that the fediverse is getting right, in comparison. If I use Mastodon and want to touch someone's post (i.e. react to it—by replying, starring it, or whatever), then I can trivially refer to that post with its URL. If I copy the link from my browser toolbar and then paste it into Mastodon, it works. (This isn't amazing. The workflows around it could use some polishing up, but the fact that it is at minimum possible is awesome.) For comparison, when I copied the Apple Podcasts show page URL and pasted it into the Google Podcasts search bar, it returns a message: "No podcasts found".
I think this is the same thing I was trying to address with this paragraph at the end:
> Another suggestion: provide browser extensions and iOS/Android sharing menu items so that it's easy to open an web page in the reading app. If there's one or more RSS feeds detected, throw in a subscribe button with checkboxes for each feed. The "shareable subscribe links" should include a link to the original RSS feed in the page metadata. Then if I click on the subscribe link but want to subscribe with a different RSS reader, I can do so easily.
i.e. we should be sure to provide smooth user experiences both for people who don't yet use a feed reader and for people who do. Agreed that Mastodon does this nicely, and I think adding in some browser extensions/mobile apps would help to automate things a bit more.
Suppose someone registered a vendor-neutral, collectively owned* domain `feedme.example`. A static site would be hosted there. Instead of everyone being compelled to do one-off integrations with the most popular commercial services, they would instead link to their own feed e.g. as <https://feedme.example/#!/https://meta.discourse.org/posts.r...>. The user's preferred reading app would be accessible in client-side storage for the feedme.example origin, and when the user actually lands on <https://feedme.example/#!/https://meta.discourse.org/posts.r...>, it redirects to the appropriate service, assuming the user has already set it up. If they haven't, the feedme.example SPA prompts them to set it up. Client software will be free to hardcode support for this well-known name and provide native equivalence to the purpose that the softcoded feedme.example serves. A sort of lame re-invention of Web Intents; alternatively, basically the same as registering a new URI scheme with IANA, except there's a web-based fallback.
* or collectively managed, at least; in the vein of w3id.org, for example
Nice to see a different application of the same concept I'm pursuing with Hey Homepage. I chose to have the feed creator and feed reader in one-and-the-same app. Just like with Facebook or Twitter, where you can read and post in the same interface. It's combined with a microblog/timeline, that can just as easily be viewed by regular people in the browser who've never heard of RSS. Openness and accessibility are key, no walled gardens. My website system also publishes an OPML file and an accompanying list of recommended other websites (just like a blogroll or webring).
I subscribed to your feed and wish you luck with your nice projects! I did miss an RSS icon on your site, however. ;)
This is cool! Other People's Meaningful Links is great :). I've subscribed to your feed as well.
I actually haven't worried about the RSS icon on my site since I figure people who use a feed reader can just copy and paste the site URL and the reader app will auto-detect the feed, and people who don't use a feed reader can just subscribe with email. Maybe it'd still be helpful to link explicitly to the RSS feed I suppose, perhaps underneath the email subscribe box?
Thanks! Indeed, I auto-detected your feed with my system and you're right about the people who know about RSS will find it, but I catch myself looking for an icon first. It also signals that RSS is still alive.
I think somewhere close to the email subscribe box will do the job. I even check the footer a lot, or the blog section of pages.
Shout out to the h-feed / h-entry microformat https://microformats.org/wiki/h-feed, sadly underutilized but an extremely easy way to make the web much more syndicable.
They're comprised of standardized CSS class names to be inserted into HTML and enable meaningful scraping. Especially given that more and more sites are produced using JS frameworks, which have a harder time producing XML than older generation PHP and the like, h-feed seems a no-brainer.
I would love to see more thoughts on interactions e.g. comments, likes. Reusing existing protocols is good but I expect a lot of trouble to implement some common social media features on RSS.
I'd say that you are the perfect user for my new RSS reader/tracker https://lenns.io/. What is more, you assign priorities to both subscriptions and categories so that you can have the ones you care the most always at the top.
I don't read in my RSS reader. It's browser isn't as good and doesn't support adblockers or other add-ons. I read in my regular web browser with uBlock Origin and all my other add-ons.
This is a really good idea, but to the point of not needing a different apps to read all the different social media sources, (and I might have missed the answers to these in the post), could the problem of participating in the communities be solved through one app too? How reading of different type of content should be handled,as some posts are just media, some are comments? Could there be something like "rss+social" spec?
> could the problem of participating in the communities be solved through one app too?
My thinking is that it's a good-enough solution to leave writing comments etc. to the separate community apps. Most of the benefit the "one app" thing IMO is to provide a single feed to check--I want to have a habit of checking only one place when I have a few spare minutes to read something. While it would be kind of nice to also be able to leave comments and such without leaving that app, it's not too difficult to click on the post and leave a comment via another app. So I'd leave that kind of thing off of this list since I don't consider it to be essential. But it could still be worth experimenting with after the essentials are in place!
Another aspect to this is that protocols and interoperability have a downside since they require more coordination between different parties and can thus slow down development of new kinds of features. I think it's important to find the right amount of interop. There needs to be enough interop so that people can build new apps without having to fight against (the lack of) network effects, but not so much interop that people are unable to experiment independently with new kinds of features.
That's a long-winded way of saying I think it's actually better to not worry about making community interaction happen over a protocol, because it gives community app developers more freedom to experiment.
> How reading of different type of content should be handled,as some posts are just media, some are comments?
It may be helpful if community apps include various metadata in the feeds they provide, so reader apps can distinguish different types of posts (e.g. perhaps include a "in reply to" field for replies). When possible, reader apps can also try to infer things about the posts, similar to my suggestion of inferring if a feed is a "social feed" or a "regular feed" by looking at the frequency (and probably also the length) of posts.
> > How reading of different type of content should be handled,as some posts are just media, some are comments?
> It may be helpful if community apps include various metadata in the feeds they provide, so reader apps can distinguish different types of posts (e.g. perhaps include a "in reply to" field for replies).
Fun Fact: The Activity Streams JSON-LD Vocabulary, which is used in ActivityPub, started, a long time ago, as a metadata extension for Atom (and RSS) feeds.
Additional Atom back in 2005 provided a minimal mechanism for copying feed items from one feed into a new feed – the "social feed" in your proposal – by specifying an element which references the original source feed.
Over the years people have put a lot of time and thought into distributed social media APIs and related specs and are still doing it. Current efforts like ActivityPub and the Indiewebcamp stuff are a direct descendant of some of these specs.
(If I were you, my first thought would be to simply read, what has happened in the last 20 years. At the very least it can never hurt to know, what other people found worth doing.)
Yep, I'd certainly recommend not adding new metadata extensions without first checking for existing ones that would suffice.
I'm interested if you have any reading recommendations? Indie Microblogging[1] is on my reading list. My impression so far of existing protocol-based social media efforts is that they're not really going in the same direction I'd like to go myself, but of course you're right that it doesn't hurt to have more background knowledge.
Both the Indiewebcamp wiki and Wikipedia often have pages on now defunct protocols and services. That is of course not a perfect approach but it gives one entry points.
> It would be sweet to have a page + RSS feed on my website that contained all my comments from Hacker News, Reddit, Mastodon, Twitter*, and of course Discourse.
I've been thinking about doing this "manually" by parsing JSON responses from Reddit and etc, because about a year ago I realized that all my absurd volume of posts there, on twitter, here, basically constituted labor I was giving to these places for free, that drives up their valuations. I wanted to "take that back" and make it my own by reposting the material somehow on my website.
Obviously, a huge part of the "value" of these comments comes from the context, the fact that the websites exist to have discussions on. If I just posted my comments on my website verbatim, that value and parent comment context would just be lost, and I bet a majority of the content would be almost meaningless.
Still though I really like this idea of being able to link to "my posts across the internet," cause I do it a lot lol.
Consumers of content don't get to choose the system or protocol of the person they follow.
I want to see a good client that supports many different ways of following content: RSS, Atom, Twitter, Mastodon, nostr, youtube, whatever... with smart ways of dealing with different kinds of content (tweets versus blog posts versus videos).
Agreed, and this is actually my "top level" recommendation for anyone building apps in this space: if you make a reading app, make it read from anything; if you make a publishing app, make it readable anywhere; etc. Don't fixate on implementing a specific protocol. This is what I'm trying to do with Yakread.[1]
I see these RSS-related recommendations as the next step: what can an app developer do to reduce the effort it takes for others to interop with them?
Why not put RSS into something like Mastodon? Take the code of a project like TTRSS and merge it with Mastodon to allow people to subscribe to both activity pub and RSS feeds. They are both chronologically sorted. People could comment on RSS items which would simply turn into shares for their followers.
I know my Mastodon account has a RSS feed automatically. I am talking about following RSS feeds from within Mastodon. Then I don't need to have both an RSS reader and a Mastodon screen open. They are merged.
IMO it makes much more sense to do the opposite, and follow mastodon posts in the UX of a RSS reader.
I personally haven't been liking any content aggregation outside of RSS/reddit because I can't take the timeline model of unrelated things being streamed to my eyes without context. I tend to want to specialize what I read or otherwise I tend not to remember it or appreciate it as much (for instance I'd typically scan through news-like nodes during breaks and read art/science/in-depth feeds after work, but something that mixes both makes me uncomfortable).
But I do have a "people" node in my ttrss instance that aggregates from social network sources/blogs/shaarlis. Gives the best of both worlds, I think.
But where do the ads go? How do publishers or authors (or content aggregators) monetize the content? The reason RSS is dead (unfortunately) and social media is very much alive is because of a pact between content aggregators, publishers, creators, and advertisers.
If we look to podcasts as a model — 490K new episodes in the last 90 days, delivered to users and to aggregators alike via "not dead yet" RSS — ads are placed inline with the content. There is no RSS-related "pact" that precludes the relationships you mentioned.
I work in this space (podcast ads) and the podcast ads tech maturity is years behind other media, like video, due to RSS. This lag is also reflected in that advertisers generally spend less on podcasting.
RSS makes it very difficult to measure the performance of an ad. Most players in this space wrap a publishers hosted podcast link with their own tracking link, and the main metric of engagement is a download. Downloads themselves are a pretty crude measurement and don’t hold up to something like minutes watched/listened.
Placing ads into the audio directly also just isn’t as performant as streaming it into the media like in video. Publishers and advertisers want more fine grained control over where the ad is placed, when it’s placed, and how it’s consumed by the listener. Podcast ads currently don’t deliver on that.
> Publishers and advertisers want more fine grained control over where the ad is placed, when it’s placed, and how it’s consumed by the listener.
There you go.
Ad tech is behind when it comes to podcasts? Who fucking cares. Not the audience. Podcast advertising is the closest thing to traditional broadcast ads for TV and radio—when ads were still inert instead of sentient. There's not a damn person on this side of the divide that sees the things you mention as being a significant downside. Not having the self-awareness to realize it is pure déformation professionnelle; this entire comment reads like a burglar lamenting the fact that people keeping their money in the bank instead of at home under their mattresses makes it harder to break in and take it.
The podcasters care? Because if the advertisers can't quantify ROI and audience, then they're less likely to spend their money with you, and your potential revenue is capped.
You, like the previous commenter, are stating the obvious. What's mystifying is the general tone suggesting that what either of you are saying is supposed to be insightful.
Yes--there's also plenty of money being spent on newsletter advertising. I make about $2k/month in revenue from that myself.[1] Publishers have lots of flexibility on how to monetize; you can do ads, or paid subscriptions, or a mix of both.... I'm planning to do paid subs + free with ads for Yakread.
The problem with RSS is that to join the social media you need a server and normal people will never host servers. Even tech people don't like to host servers (see how many DBaaS and PaaS and hosted offerings of open-source server software exist).
Because of that I think a standard that allows people to publish their own (cryptographically signed) things on a variety of publicly accessible servers (that could be restricted or not, have their own moderation policies or not, be paid or not or have other model) is the way forward: https://github.com/nostr-protocol/nostr
Judging from his blog, Dave Winer is trying to build something that will tie in RSS with Twitter, Mastodon, and so on.
I first learned his name here on HN a while ago, although he doesn't seem to participate here. He thinks he's doing great new stuff, but as in this thread, his name rarely seems to come up in other people's discussions of RSS.
"Some feared that the inability for people to get along with Dave Winer would further damage the development of RSS."[0]
Very nice--I like all the "Follow in" links. The one for Feedly in particular is pretty much what I'm envisioning, since it shows a page for the feed itself even if you're not signed into Feedly, instead of just redirecting to the landing page/sign-in page like the other ones do.
I don’t like self-promoting in comments but this feels incredibly coincidental. Just a few days ago I published an iOS app called Beluga which tries to reproduce a “Twitter-like” experience on top of JSON Feed (with some extensions) and RSS. The app does all the work on the device and uses an S3 compatible account to publish a feed and a statically generated mini-site.
Open article, Ctrl+F, mobile, app, no apparent statements. Close tab
Any "rebuild" solution without heavy involvement of mobile first is destined to fail. Or it will just be a nich market on desktop websites for desktop browsers.
Mobile apps is the client solution, the problem is most people are "consuming" mobile-only content. E.g. from other mobile apps. RSS doesn't tackle this the slightest.
Why not ActivityStreams instead of RSS? It would have free and seamless interop with ActivityPub, with the only difference being a "pull" model as opposed to the "push" inherent in ActivityPub.
Anyone can host an RSS feed with just a web server. Everything from a shared host to a VPS to a Raspberry Pi at Home. It takes a lot more resources and administration effort to run an ActivityPub server.
That's true of current implementations, but the spec is flexible enough to allow much simpler ones. You can have an outbox which is a collection of activities (that could even be statically generated) and software could poll the outbox just like RSS. Existing software requires a push-based model, which means handling follows, which means a database, but fundamentally there's nothing stopping ActivityPub from being pull-based.
Maybe that'd work too! I'm honestly not very familiar with ActivityStreams. My main concern is figuring out a lowest common denominator/the simplest thing that works, and I think RSS is sufficient. I'll have to do some more reading + thinking on ActivityStreams.
Intentions are good, but these types of ideas need real world scrutiny.
There's a reason why social media entities have become walled gardens. Some used to have RSS but removed it. Then they restricted anonymous viewing. Then they motivated users to use the app instead of the website. This isn't just driven by pure evil, it is fueled by the need to keep the lights on.
Running a social media behemoth for the masses costs billions per year. They need to keep online a staggering amount of content forever, develop lots of apps, have teams in every jurisdiction, comply with laws, it's a massive operation. All so that you can use it for free (with ads).
Why would these "hoarders" of social content open up using RSS? It's suicidal.
You cannot escape the monetization question. The Mastodon model moves this cost to individual volunteers, which will not scale to billions of users. The typical instance already has to stop registration after a few thousand users, media content is regularly purged, and instances constantly come and go, so your cohesive "identity" is based on quicksand, as well as subject to inconsistent and arbitrary moderation.
Apart from that, the RSS idea doesn't go beyond the aggregation of reading content. Say that I follow your social feed that way, how do I talk back? Where will my comment be posted? At which service? At which of the various sources that make up your combined feed? Who pays for the hosting? Who moderates? Who gets to see it? Who gets notifications? Which service pays for managing notifications?
What about a like, heart, retweet, all the various types of amplifications? In a decentralized scenario, what does this do, if anything?
What about discovery? How do I discover people to follow and relevant content? Supplying the current effortless experience?
How does blocking and privacy work in an open feed? I'm subscribed to your feed but don't like a particular person commenting on it. So I block him. Who maintains/stores this block?
How do ads work? How does verification work? How do creator fees work? How do subscriptions and newsletter work?
All of these things are standard features of modern social networks that people have to expect. Reading content is only a tiny part of the total social media experience.
The proposal isn't to make a twitter clone that just happens to use RSS under the hood. I'm basically just saying we should take the existing trend of smaller, focused communities (like you find on slack or discord) and try to add a bit of glue so it's easier to keep tabs on a large number of communities. That's about half of the proposal, anyway.
A lot of the questions you ask are already resolved in the newsletter ecosystem.
RSS doesn't have to include the article. Websites can omit the it if they want people to visit the website. I don't use the browser in my RSS reader anyway because it doesn't support my favourite add-ons.
A related idea I have is to support subscription for OPML feeds. That way, instead of getting a private personal feed URL that merged hundreds of feeds that you follow on the server side, clients should support subscribing to an OPML feed, which can just be links to whatever you are following (games, posts, users, discussions etc).
The OPML feed changes, your RSS client picks up the changes and starts following the correct endpoints.
I’ve been trying to think of an RSS driven daily newspaper.
I currently use Reeder. I source in my usual news sources and HN and twitter and some subreddits.
I’m working toward a place where I can setup a feed, a frequency, and a service to use both to make an “old timey” newsprint like PDF into my inbox (or an rss feed!) each day so I can still try for that “back when papers were good” feel.
I used to do this. A long time ago, I had a setup that would sync feeds from BBC, CNN, Janes [0], and a few other places; extract and sanitize [1] the text of the articles for the previous day; and ultimately prepare a nicely typeset, five column, landscape oriented PDF. It took some trial and error to get something usable, but the printed result was a pleasant way to stay informed.
That was many moons ago.
---
[0] Circa 2008, I could find several feeds from Janes that carried meaty non-subscriber extracts.
[1] LaTeX is picky about all sorts of "special" characters that are more common than one might expect.
In many cases, following the links in the item entries will get you full text. Just to get something going quickly, you can do a `links -dump <url>` to get just text and then cut it down with some bash-fu. That said, if you pull a lot from a given source, it's worth figuring out a reliable way of cracking out the title and text so you can format them sensibly.
I think RSS needs fixing first before building anything on top of it. At the risk of that xkcd meme about 15 competing standards, RSS + images is a total mess. Every reader supports different ways of rendering images. Sometimes it's inline HTML, sometimes it's the RSS <enclosure> element, sometimes its something entirely else.
Some readers either support <enclosure> or instead load inexplicably tiny/blown up/stretched/pixelated images, or just don't display any images at all.
Consider that podcasts use RSS - yet need a special namespace "itunes" in order to work:
This is one reason why it's important to not try to do too much over RSS. The question isn't "can we re-implement every social media feature using RSS," it's "what is the minimum amount of interop we need in order to for an ecosystem without gatekeepers to flourish," which hopefully will make things bearable.
Besides that, I also think this problem can be ameliorated to some extent by using and developing open-source feed parsing libs like Python's feedparser rather than using a plain XML parser and doing the rest yourself.
Having had to work with importing RSS feeds. I absolutely despise the tech. The sources generating RSS have almost no consistency on how things are done and the actual spec itself doesn't show much opinion on which of the 5 ways to do things is the preferred one. That's before you get in to the mess of invalid RSS and then invalid XML which is extremely common.
One of the problems is the spec tries to do everything. You have blogs, podcasts, random crap, and now social media all trying to cram in to the same spec. Ideally you want one spec per use case. With modern tech it's very easy to create a new JSON spec which is trivial to parse and serialize. And you can auto generate extremely accurate documentation.
I don't think we really need "another rss" which would just be fragmentation. We just do not need to be using RSS for social media just because you can.
RSS needs it’s QR
moment. By that I mean Covid was the accelerator for QR adoption. RSS needs something so that most people are happy and used to collecting feeds. An RSS can be used for anything where you want to update someone at the same pace as an email: soon but not realtime. I use RSS to get alerted to deals.
One aspect of RSS that might appeal to marketers is the perfect delivery and no games trying to avoid spam folders, plus tracking via images and landing pages will work. The receiver gets easy unsubscribing and less in their real inbox.
But email replacement is just one thing you can do. Stock alerts; Reminders etc. could all be done this way. Social media of course too.
This shows the bubble different people live in. I literally never dealt with QR codes with respect to covid but I use them for electronics/documentation all the time.
Currently making my own social network from scratch and it's more media-based than text-based, but I love the idea of RSS feeds for everything. My only concern would be extra bandwidth requirements if there's a ton of readers out there constantly fetching updates.
It's better than someone F5-ing a page and redownloading all the assets, but feed readers check automatically on a (usually short) timer, so it's not really comparable.
Does YouTube still offer RSS feeds? I remember those being extremely useful when they swtiched from reverse-chronological to the recommendation-driven Home feed.
Youtube does still have feeds. The bandwidth can be reduced if readers use the If-None-Match and If-Modified-Since headers when requesting feeds (so if the feed hasn't been updated, the server can return an empty response). I also imagine that as feed readers become more mainstream, you'd start to see more intermediaries for fetching feeds like Superfeedr[1].
the problem with RSS is only one directional protocol also with no auth system. there's something like BlueSky's new ATP protocol that I think better to your case.
Basically it's because decentralization has downsides, and I think the optimal amount of decentralization is less than what e.g. Mastodon/ActivityPub provide. See also my other comment: https://news.ycombinator.com/item?id=33976289
