I've been advocating for RSS support, and you should too
reedybear.bearblog.dev
reedybear.bearblog.dev
The form is
https://www.youtube.com/feeds/videos.xml?channel_id=UC2wdo5v...
where channel_id is the channel hash code which is buried in the source for the "nicely named" channel:
https://www.youtube.com/@CuttingEdgeEngineering
and can be found without source diving via (say) FeedBro (RSS browser extension) "Find Feeds in Current Tab" function.
https://www.youtube.com/feeds/videos.xml?playlist_id=
It's a really nice way to be able to follow creators/playlists without needing to register an account. I'm surprised that YouTube still allow it, but I hope it stays.
This is a problem because many channels have playlists where they put older episodes at the top and add new ones to the bottom. This makes the playlist RSS useless, because it will always show the same 15 videos.
So many times I can't find anything to watch on YouTube and it just isn't showing me any of my subscriptions, it's ridiculous.
I'm using the RSS feeds, so I'm not sure...
I do not understand why people keeps suggesting subscription view, as it is a worse experience for me, than central RSS management
Using the Subscriptions view is as simple as changing your bookmark. Setting up RSS is a lot more complicated for someone who isn't already using one.
If you're already on RSS, no one is suggesting you use Subscriptions instead.
For some reason YouTube website never has any kind of notification popup in site either. Instead, the notification icon count increases by one.
Which caps at out 9+. Stupid.
What I want from subscriptions is basically a filtered list I pull from when going to youtube. With maybe some tiering so the people who upload once a year don't get lost in amongst the people who upload 2+ times a day
I browse YouTube anonymously, have an ad blocker setup that pretty much eliminates all ads, and track my "subscriptions" with RSS. It's highly usable. I use a fork of tt-rss and actually embed the YouTube videos in the reader pane so I never see any of YouTube's algorithmic recommendation schlock (beyond recommendations at the end of videos, which I ignore). Browsing YouTube, the site, is a jarring nightmare.
I am considering having my podcatcher use a YouTube downloader to just pull down all the videos in the feeds I watch. I believe Google is throttling yt-dlp to realtime speeds, but I figure if my podcatcher is doing it behind the scenes that shouldn't matter. I maintain curated collections of podcasts I like (in case they ever disappear), and since I just added 40TB if storage to my home system I figure it's time to do that with YouTube too.
I use that for my ex-twitter RSS feeds.
Adding /.rss on to the end of lots of URLs works all over the place on the site.
Example: For channel id "UCXuqSBlHAE6Xw-yeJA0Tunw" replace the first two letters "UC" (channel ids always start with "UC") with "UULV". The feed url then looks like this: https://www.youtube.com/feeds/videos.xml?playlist_id=UULVXuq...
For more special playlist id prefixes see this StackOverflow answer by "coco0419": https://stackoverflow.com/a/76602819
Example: For channel id "UCXuqSBlHAE6Xw-yeJA0Tunw" replace the first two letters "UC" (channel ids always start with "UC") with "UULF". The feed url then looks like this: https://www.youtube.com/feeds/videos.xml?playlist_id=UULFXuq...
It will only contain Videos, no Shorts, but also no Live Streams (in case you want (only) Live Streams use "UULV").
For more special playlist id prefixes see this StackOverflow answer by "coco0419": https://stackoverflow.com/a/76602819
<?xml-stylesheet type="text/xsl" href="assets/xml/rss.xsl" media="all"?>
[1] https://getnikola.com/rss.xml (Open it in your browser!)
[2] https://github.com/getnikola/nikola/blob/master/nikola/data/...
Retrospectively, writing code in XML, eewwww, but back then I liked writing XHTML by hand
For example: https://andrewstiefel.com/feed.xml
Niche? It happens far more than you think.
Even with a custom implementation it’s a simple thing to support. You can find the whole spec here: https://www.rssboard.org/rss-specification
I’ll mention that there is a competing Atom specification which is compatible with all notable RSS readers https://en.wikipedia.org/wiki/Atom_(web_standard). The POV I’ve seen on HN favors Atom because it offers more functionality and is a clearer standard.
I want to voice my support for RSS though based on its simplicity. To me the feed doesn’t need a bunch of bells and whistles. I get analysis paralysis I get deciding which Atom features to support.
There's also this version, which I believe is the original: https://cyber.harvard.edu/rss/rss.html
It's far from perfect, but at least it's not infested with spammy advertising.
Atom exists because RSS is ambiguous and prone to breakage. The "bells and whistles" exist only because there were a lot of common extensions at the time that made sense to fold into Atom itself. Even if you use none of that and just the bits that overlap with RSS 2.0, your feed will be less likely to break in random feed readers, and that's enough reason to use Atom over RSS.
In this day and age, there's no good reason to use RSS over Atom beyond brand recognition.
(Yes, I'm still salty from the feed wars of the 2000s, but I still stand by all that I've written above.)
Also advocate for support with browser manufacturers. It used to be good, then one of them dropped it and the others blindly followed. People clearly want the RSS button, why on earth not provide it?
Most people didn't decide. Most people were tricked into using chrome. Most people are not computer literate.
Most people switched from Internet Explorer.
Firefox was never the "mainstream" choice.
This may be more regional-based and profession-based though. Around 2010 when Chrome was entering the market Firefox had around 30% global market share. In Slovakia where I'm from Firefox was "mainstream enough" that we had it pre-installed on high school and library computers and were taught to use it instead of IE as early as 2005..., But also in lots of enterprise-style managed companies (including basically all government offices, banks, ...) you couldn't use anything other than IE as late as 2016 cause there was no way they were gonna allow you to change your homepage from the company intranet home, so there were also lots of people who were using Firefox at home but also using IE at work because they had no other choice...
Give Google credit: they have created a very useful ecosystem that has won people over in the marketplace. I NEVER thought anything would convince companies to move off of Microsoft Office, but Google is actually doing it (on a small scale at least).
Creating an ecosystem where you web apps "encourage" users to use your browser is the antithesis of an open marketplace.
Whatever comes with the browser will not be as good as an extension from a company focused on that feature. For example I use https://www.inoreader.com/
Open the current page's RSS feed in my configured client. Failing that, copy its URL. Absolute minimum, it's a shortcut for having to view source, cmd-f, "RSS", cmd-c
- It rendered the feed in a pretty way.
- If provided a little widget to open the feed in your feed reader (in practice it substituted the feed url into a URL template with popular readers by default and the option to add your own). This basically made it a one-click subscribe option.
Then don’t click it?
> RSS is best when integrated with a stateful server-side reader.
Hard disagree.
Look, you do you, but your preferences aren’t universal.
Who said that? It's meaningful if you read the feed across multiple devices, but lots of people read RSS on their computer only.
And even so browsers could provide RSS status synchronization. In fact almost every browser is already syncing your browsing history, bookmarks and settings if you are signed in.
> Whatever comes with the browser will not be as good as an extension...
not true.
In many situations you _can_ just send an email. Most often someone will read it and be very happy to help out if they can. Not always, but how much of a time and effort investment is an email really?
The best part is that a few kind words can absolutely make someone’s week.
Some RSS readers are quite aggressive with their polling time. At the same time, a single request may serve thousands of users. However, you can check your logs and get the actual number of subscribers, at least for popular RSS readers: https://darekkay.com/blog/rss-subscriber-count/
Thank you for your effort in advocating RSS support. I hope RSS makes a major come back especially with the recent events.
I sometimes wonder why there is so much push for "federation" and so few for... well just simple interoperable solutions that just require a client to connect to whatever server it wants with a well-known protocol.
Which is great for me as the end user - but makes it much harder for them to monetise.
But for the company running the website, the fact that you're no longer browsing to their site, being served adverts and tracking code, and seeing what's on their homepage is not a benefit
On the other hand, RSS definitely provides extra opportunities to monitise. Imagine your business provides a customisable "offers" feed so you can tell interested parties when a sale occurs, etc. Businesses should be falling over themselves to get that kind of engagement.
Some sites even have different RSS links for subscribers only that give a full feed.
I would even say that a podcast that does not support RSS is not a podcast, it is something else.
Federation comes in mainly because push based systems require a server managing who follows who, what is posted, and who to notify of updates. That's a lot of information for one central service to be responsible for, leading some to think its better to federate and trust a bunch of servers to host copies of some or all of that same data.
Still I can't help but to wonder whether those notifications are needed or not. Except for instant messaging, I generally don't want notifications. Like I don't need to be told that a new podcast is available, I'll see it next time I open the app.
I would like to at least have the choice to use RSS instead of having to go through a complicated federated system.
Even if I'm using someone else's system, I just don't like the idea of giving them a reason/need to manage all that for me. RSS works fine 99% of the time.
Ideally the push-based parts would be optional for both ends so you could host a static feed and still have people see those updates in their fancy fediverse apps, just not immediately when you post them.
Instead we have a completely different standard without a simple core that you can easily implement if you don't need all the bells and whistles.
The people creating websites often don't know that they're providing RSS feeds though, and never link to it.
To solve that I developed a tool that finds RSS feeds, even if RSS autodiscovery isn't implemented: https://lighthouseapp.io/tools/feed-finder
I often receive answers, that surprised me! People saying "thank you for your suggestion, we will think about what we can do". None of them has every changed anything (I've been doing that for years). I don't even know if they did anything more than answering to the email.
Also many of those emails are autogenerated. So the template has to be done once, and that's it. And it should be trivial for whoever composes the HTML email to copy-paste the important part into a text-only version. Maybe it would actually help them think about what the important part actually is.
> So the template has to be done once, and that's it.
Except the world is not static and then when the HTML template gets updated they'll forget the text template and now you are missing vital information. Perhaps even legally required information like unsubscribe links.
Supporting text email only makes sense if that will actually be tested. Otherwise you are better of just rendering the HTML to text locally. That's going to lose you less information than a forgotten text mail template.
And again, HTML brings security concerns.
The problem is when the email explicitly includes a plain text part which is an empty string (or a generic one-sentence placeholder), and a separate html part. In these cases, the email client is right in defaulting to the plain text version.
Right, let me answer in a tone that I find similar to yours.
> gmail doesn't even do this
How the hell did you test that? Gmail sends goddamn plaintext together with HTML.
If you can't be arsed to even check that, why should I even answer to the rest? You've completely ignored the security aspect of it, but I guess you have similarly "not super callous" opinions about that. Don't bother, I don't care to read them.
I cringe every time I see a feed that uses RSS and then pulls in Atom for some of elements. If you're going to do that, then just use Atom for the whole thing rather than building a frankenfeed.
Consider helping them out if this interests you, you might even be using a feed already as they have some custom feeds for github like for discussions and issues.
Was surprised that anyone would be interested in keeping up with my writing, but was happy to oblige the request as it had been on my to-do list for a while. Happy I did do as it seems many people are hitting the RSS endpoint now. Cool to see that RSS is relevant in 2025, and will definitely advocate for its usage more moving forward :-)
I never bothered to make a list of the mails I send but now I see it is quite useful to show how well it works. Maybe some data on implementation time would be as useful.
Auto-discovery for RSS is simple enough to explain here: just put the following code in your head element (at least on the homepage).
<link rel="alternate" type="application/rss+xml" href="/feed.xml" title="RSS Feed">
I came to the industry way later than the Web 2.0 inception and didn’t even know about it until a while back.
I created a tool to find such RSS feeds for as many cases as possible: https://lighthouseapp.io/tools/feed-finder
And if you're interested in the details: https://lighthouseapp.io/blog/deep-dive-finding-rss-feeds
1. https://github.com/0x2E/fusion - A lightweight, self-hosted friendly RSS aggregator and reader
2. https://rawweb.org/ - A search engine for indie websites (the crawler collects data from RSS feeds)
3. https://github.com/0x2E/rss-finder - A tool for finding the RSS link of a website
RSS feed could be generated automatically with some AI code generator (or tree-sitter query generator), and just parsing the elements of the page.
Eventually i failed, but also i didn't try hard enough.
1. https://lighthouseapp.io/ - feed reader combined with bookmarking
2. https://lighthouseapp.io/tools/feed-finder - tool to find RSS feeds (https://lighthouseapp.io/blog/deep-dive-finding-rss-feeds)
3. https://lighthouseapp.io/tools/newsletter-to-rss - tool to convert newsletters to RSS feeds
If you remember, Yahoo Pipies allowed devs & others quickly build something with RSS feeds. I've recently rebuilt and launched my own Yahoo Pipes clone
Along the way of building this tool, I came across a plenty of major websites that do not provide RSS feeds and indie devs who maintain niche tools to provide these feeds.
Then again, RSS are still plentiful!
Implementations of this notification mechanism are either spammy, privacy-problematic, or both: (Web) Push notifications, Email, or Messages.
The only solution that doesn't have either of these problems seems to be RSS: Provide the user with (customised) feed link and let them/their RSS client deal with it.
I really wish RSS was less niche and more mainstream. I will "advocate" for it regardless.
It's the correct amount of complicated imho.
And RSS is an over-complex solution anyway, designed for a time before web standards when sites all had spaghetti table layouts. Today there's no need to create a whole shadow site in fussily-formatted XML for what can usually be found in the page source of the article list page as a bunch of `<li>`s.
The more sustainable solution, I believe, is client-based: RSS readers that also parse HTML. There is even an HTML attribute schema, `hfeed`, that makes this easy-peasy and is much easier to implement for publishers. I still don't understand why this solution has not taken off yet. It's clearly optimal.
Microformsts, which give us things like h-feed, are useful but the author is already thinking about the feed reader use case. Why wouldn't they also hook up an RSS feed?
I've found microformats to be just as much work to maintain (assuming more than just h-feed is needed these days). Its still easy to break silently, and if I care enough to make it I'll automate a test. Testing an RSS feed shouldn't be any harder than testing the rendered HTML to catch silent regressions.
Do we?
> Even a single publisher that's missing a feed will be a deal-breaker for any new adopters.
Is a single publisher not being on your favorite social media app also a deal breaker? Where does this absurd requirement come from - most people already end up visiting multiple sources for their daily updates. If RSS can reduce that it's useful even if you still need more than one.
> And RSS is an over-complex solution anyway
It's extremely simple compared the "modern" alternatives (social media APIs).
> I still don't understand why this solution has not taken off yet. It's clearly optimal.
Because it doesn't actually improve anything over the status quo. You still need to do the work to implement it whether it's inline or a separate file for the feed and the inline version is more prone to breakage with website changes.
I also include a short description of rss, which parts to support with an example and a description of how one could make an rss feed: you take whatever code produces the index html, remove everything except the part that outputs for each item the title, introduction text, the link and the publication date.
Followed by one more short example rss with $title
Not that any developer would really need this but it puts everything they need to know and do on a single page. You don't have to think, just do it.
I came to the software industry a lot later than the inception of Web 2.0 and rediscovered RSS almost accidentally. I advocate for it too.
You’d be surprised how many people still care about this. My static site build broke the RSS[1] once recently, and I immediately got like 5 emails from different people.
Or use an open source module. Here is a general atom feed generator that I wrote and published under the GPL:
https://github.com/no-gravity/atomfeed.py
Just 14 lines of Python. And it has been reliably serving the feed for my own website for quite a while now.
Combine that with a list of shared links which functions as a blog roll and consists of the feeds that you follow, and you have yourself a Really Social Site. You can even download the OPML file that contains all the shared links and start following some feeds from it yourself. So discovery is also possible with RSS feeds and OPML lists, albeit it works slightly different than you're used to from big tech.
After that I built a Newspaper module that automatically collects new posts from feeds that I selected. This is my main way to get news without some algorithm deciding for me. The only wish I have is that more of your personal sits/blogs (most websites I follow come from HN) offer more 'photo feeds', just an enclosure-element in your item with a link to a picture or other media.
In any case, many actually useful sites that disable RSS are public orgs that do not rely on adtech or subscriptions. Its the sad result of digital illiteracy and outsourcing their web presence to some inane outfit thats up their neck in the SEO and social media shit.
Incidentally a Web that makes full use of RSS is also one where more complex protocols like ActivityPub and ATProto can flourish. A client is a client is a client. Now that Mozilla has essentially abdicated their role as a user-centered window to the universe maybe there is room for something else?
https://github.com/bluesky-social/social-app/issues/3384
https://bsky.app/profile/did:plc:3nfshkzomgboapasu6amkhui/rs...
Obviously I can see why they don't want to subsidize the entire internet with high-res videos and images, but a blank RSS feed for media isn't the way to go.
After the migration was complete without an RSS feed, I received dozens of emails within the same week from people I never knew read my blog specifically requesting an RSS feed on the new site. So I added it.
That quickly reminded me about how important and common RSS is, and I'll continue ensuring that RSS feeds exist on any blog I create as a result.
This seems like what we should do against negative trends. I think complaining is more common, probably more accepted (?) than advocating, but logically, the latter is what we should do.
And since this is HN, implementing a RSS reader tutorial is surely more interesting than TODO lists.
The core issue is that browsers have completely failed at offering anything to keep track of websites. Why aren't notifications simply build into the bookmark system? I don't need the website to provide that information via yet another special format, my browser should be able to figure that out itself from plain .html. But bookmarks haven't changed one bit in about 30 years, instead we moved that functionality server-side for no reason.
No need for JS workers or push servers.
What I want is a simple counter that show how many new posts there are of the RSS, and that's it. I only click for new content.
The RSS feature was always kind of useless, since it required that the website provided a RSS feed to begin with, which most don't. The implementation in Firefox was also horrible on top.
HTML is a markup language, with header, datetime and article tags, parse that and do something useful with it, we don't need yet another format that duplicates the information that is already on the website.
And if you respond with "well, I don't care about the actual content, I just want to receive a notification when the page has changed at all", think how long would it take for every marketer use that "feature" to simply make minimal changes in the site to trick their viewers into inflating their page view numbers...
It worked amazingly well! It worked so well that it became a problem for the publishers when they realized the standard for syndication has become so widely adopted that people were not visiting the websites anymore and they had lost control of content gatekeeping.
> Mozilla had half a billion dollars each year to work with, I am sure they could have figured something out if they cared.
I agree with you that Mozilla has shown that they don't really care about an open web, but I think you are reversing cause and effect. RSS was already a reality when Google had to kill (*) it, and Mozilla went along with it because they never managed to get out of Google's money tit.
* Not really kill it, but just taking all the steam out of it so it wouldn't destroy their own business.
I can only see this happening as a service. A company crawls the web—probably a search company. Their LLM classifies changes. Their users can subscribe to individual sites or pages.
Even then there are downsides to publishers including loss of some tracking information and users spending less time on their sites being subjected to advertisements.
The problem with the "single lightweight endpoint" is that it has to be maintained. RSS is literally a whole shadow site, with finicky XML validation to worry about on top. I've worked on multiple projects where the RSS endpoint was broken much of the time. It's both fragile and not very visible.
A solution involving client parsing of semantic markup at least has the benefit of requiring zero maintenance.
Are you referring to the microformats tags? They were never standard, and they were never meant to "turn pages into things".
Microformats, while nice and useful, were never meant to be more as compilation of certain adopted practices by the indieweb crowd.
(Also, a bit of a side rant: now that I am working on ActivityPub stuff I'm finding less and less sympathy for those that jump into code and push for "pragmatic" solutions. The ActivityPub spec is not perfect, but it's incredible how almost everyone implementing ActivityPub ignores JSON-LD and RDF and just want to wing with the JSON messages. It gets to the point where perfectly valid JSON-LD will get refused to anything that is not called Mastodon, because everyone else is just parsing the JSON they receive and completely ignoring @context directives)
Interesting rant about ActivityPub, you have my sympathy.
Maybe making everyone who wants to interact with the fediverse deal with all that complexity isn't such a great idea after all. What we really should have gotten was RSS++ with optional push notifications for new content instead of this mess. But it wouldn't be the web without reinventing the wheel for every new "standard" I guess.
I could entertain the argument that we don't need two way interactivity, and that most of the applications would be fine by implementing their own ad-hoc API. This is exactly what is happening in the Fediverse now, where every microblogging project ends up implementing Mastodon's API and every Lemmy client goes straight up to Lemmy's API instead of getting the data from "raw" ActivityPub.
This is a pipe dream. In reality your HTML markup needs just as much maintenance if not more - at least the separate feed is unbothered by design changes to the HTML site.
That part is a non-issue since Browsers need to be able to turn that tag soup into a sane DOM already. And these days how to do that is well specified.
Or wait, that was just a clone from the pc desktop which was a clone from the 1973 Xerox Alto.
https://design.tutsplus.com/articles/know-your-icons-part-1-...
Ah yes, how familiar it looks...
My joke since the 90's: Mosaic had full text history search!! It aged well I must say.
With all the money coming in from google it was hard for Mozilla to understand the point of subscribing to RSS or organizing what one finds online. For google it must have been even more incomprehensible.
Feedly asks for a url, this site makes me download a .bin file. It doesn't make sense how this is my first user experience. I can assume I'm supposed to copy the url in the link? But it is a nav item on the site.
Call me nieve or whatever you like but with ux like this I can start to see how this technology has become less popular.
Feedly is a huge beast besides just an RSS reader. Try something lightweight.
In feedly and many readers, you can just enter the website URL and it'll find the feed(s) automatically if present.
But in general, how RSS work, you copy the URL to the RSS feed and give it to Reader to subscribe/follow the website. https://reedybear.bearblog.dev/feed/
When the author publishes a new piece, they update the file located at this URL and your reader will fetch you the new content.
For me I believe I'd prefer a TUI in the terminal, but probably depends.
When pulling RSS, how do you know how often to poll? How do you know which items have been seen previously?
I would guess a combination of frequency from sitemap.xml, last modified http header, and past heuristics. Previously viewed items would, I think, need to be cached in the client (unless the RSS URL uses some kind of token to identify the user, which sounds ripe for abuse).
Tracking what's been read or not isn't done by the RSS feed or whoever hosts it, it's performed by the user's feed reader, which be just a local app on your phone or PC, or it might be a cloud service, either hosted (like Feedly) or self-hosted (using ie. FreshRSS).
Personally I just start my reader then it aggregates and sorts my feeds by date into a single interface. This works well specially for much larger numbers.
TL;DR: readers should not poll more often than once and hour, use ETag and If-Modified-Since to determine whether to download the full feed again.
Which items you have seen previously is something the feed reader keeps track of.
Is there a particular field that can be used as an identifier?
Of course a lot of feeds also get this wrong and change the GUIDs for existing entries once in a while which results in strictly compliant readers showing you the entire feed history as new. Really annoying.
The latter is annoying, I agree.
¹ It is an NNTP interface so the article is superseded; https://feedbase.org/about/ - if you don't want to see updates, you can configure your newsreader to skip supersedes.
It really depends on you but IMO for most feeds polling once a day is plenty.
https://www.rssboard.org/rss-specification#optionalChannelEl...
ttl, skipHours, skipDays
Source: working on a feed reader (https://lighthouseapp.io/) and feed finder tool (https://lighthouseapp.io/tools/feed-finder).
Do someone knows a way to retrieve RSS feeds URLs for any podcast that would be hosted on major platforms? (Spotify, Apple Music)
I subscribed to podcast having some hosted website (where they are publishing the RSS feed from) but most of them don’t
https://pca.st/podcast/170a7610-948e-0135-9d21-5bb073f92b78
Under "more ways to listen" it has RSS as an option.
The site is https://podcastindex.org/
It seems like Atom is better, but RSS as a name is more well known?
I'm guessing adding a button on your website which says "Subscribe via RSS" but which actually points to an Atom feed would be confusing and bad?
Not having it enabled makes life harder for them since many are too lazy/not savvy enough to use other means to steal content.
Why? You can’t bombard RSS with advertising like you can on browsers and if people could get the information they need from RSS they won’t see ads.
I recall the dropping of RSS happened over 6 months to my recollection. RSS was here and every website of merit used it, then all of a sudden Chrome, FireFox and Safari all dropped RSS support. You could go and install a separate RSS client but few people did that (extra steps and all) and then websites saw no one was using RSS and dropped support.
RSS was particularly useful for browsing jobs for IT contractors. I used it daily, using RSS I was able to get job listings fast and apply before other candidates.
For example, job seeking sites:
https://tyomarkkinatori.fi/ is the national "job market" for the whole of Finland. Municipal and state employers are obligated to publish their openings there. That site has been in development for years and from 1.1.2025 onwards it replaced the old one - which supplied RSS feeds. Tyomarkkinatori does not and when asked, they will only reply that RSS is not going to be supported and that's the end of it.
https://indeed.com doesn't provide feeds anymore.
Neither does (yet another Finnish aggregator) https://laura.fi
If they don’t play nice, they often offer short digests in feeds, driving users to open their sites where you get ads, tracking, bloat, paywalls, and no longer in control…
Thank you for advocating RSS. It’s the least we should strive for in our services.
We can also strive for services themselves without tracking, ads, bloat…
If you have a blog or want to start one, consider supporting platforms that genuinely improve the web experience.
I built https://lmno.lol after growing tired of the popular blogging platforms.
Here’s my blog on it https://lmno.lol/alvaro
If you prefer a different blogging service, there are other folks working on building a more mindful web.
By supporting services like these, you prove that like-minded services are not only possible but fully sustainable without deceitful tech.
• Bear
• Ghost
• Glitch
• Haven
• LMNO.lol
• Mataroa
• Micro.blog
• mmm.page
• Montaigne
• Nekoweb
• omg.lol
• pages.casa
• Pika
• Posthaven
• prose.sh
• Scribbles
• Smol Pub
• Write.as
• Yay.Boo
Recently, one of my posts hit the front page here, and a few people emailed me asking for an RSS[1] feed. It turned out that it was just a simple config update to enable this on Hugo.
Other SSGs usually support it out of the box too. Plus, it’s not too hard to build the XML from your HTML if you want to build it yourself from scratch.