HN user

tjansen

1,396 karma

Developing software since the 90s. Corporate work by day, side projects by night. Now working on downread.com.

Posts4
Comments497
View on HN

I have also thought about things like that. I'm currently working on a mainstream-focused RSS reader that comes with a large feed catalog and a feed-spider mechanism: when a site like Hacker News posts a link to a yet-unknown site, it automatically searches the website for an RSS feed, and if it finds one, it automatically adds it.

While my main project is the RSS reader itself, I think the ever-growing feed catalog is something that would be interesting as a stand-alone project: a reader-neutral catalog of RSS feeds.

An interesting observation is how people are currently discovering podcasts vs how they discover news feeds. Most podcasts are found on podcast directories, usually embedded in the podcast listener's platform. While discovering an RSS feed is more like i-found-an-interesting-site-does-it-have-an-rss-feed, which works ok for enthusiasts, but is far too complicated for mainstream users.

From a publisher's perspective, the main issue with RSS feeds is that if they contain the full text instead of a summary, they are currently hard to monetize. And a summary-only feed is just not that great.

A solution may be a YouTube-like model, where feed readers either insert ads or charge their users monthly fees that are redistributed to feeds.

I keep hearing that "the web is broken". But how exactly? What parts are broken in a way that makes it worse than it used to be at some point? I think people who write this just glorify the past. I don't want to go back. Not to the age of Flash ads that crashed the browser. Not to the age where people overused HTML frames and basic stuff like opening in a new window didn't work. Not to the age when every site used tables for layout, and they didn't work half of the time. Not to the time when every non-trivial application required Java and the whole computer froze even if you were one of the lucky ones who got it working. Not to IE-specific hacks and ActiveX. Not to image maps...

And content-wise, there is more content than at any point in time. So what's the issue?

You can use a more nuanced approach.

What I did in the last systems I created:

1. The JWT expiration depends on the user. Admins get only 1 minute or so, but regular users 1 hour. If I had an SaaS for enterprise customers, I would use very short expiration times for paying enterprise users, but long for non-paying users.

2. When 95% of all requests are reads, and it's not sensitive data, only validate the JWT. For dangerous operations, always require validation of the user status.

3. I prefer to let the server control the JWT lifetime. So the server can respond to any request with a 'token too old' error, and the client knows it must renew it and retry. That allows you to configure the expiration date of the token depending on the operation and how critical it is.

I’m writing again 2 months ago

I wouldn't be here if I hadn't somehow obtained and read Accidental Empires as a kid. Still no empire of my own though :(

I wonder whether there is any tool that can prevent npm from downloading any package that has been published in the last month. While I miss out on possible fixes, this would prevent downloading some 3rd level dep that takes over my machine.

They probably didn't even think about that. Admittedly, 4GB is quite big, but if I were in their shoes, I would have expected that people are thrilled about using a local LLM instead of sending data to a cloud-based LLM.

I am still stunned that there are people who hate AI so much that they have a problem with the weights of an LLM being on their computer. To me, that sounds rather esoteric.

You want to grab all you can during excess production/very low prices periods and then use that for the rest of the day.

Batteries help, but even that is limited in northern countries like the UK. If you look at the data, in July '25, solar produced 2.36 TWh. But in December '25, it was only 0.535 TWh: the output in summer is >4 times the winter output. So either you need to discard 75% of the electricity produced in summer, or you need truly gigantic batteries that store power produced in summer for winter. Both is not economical. Solar is far less efficient in the UK than in, for example, Florida.

As soon as everybody is paying spot prices, balcony power stations are not economically viable anymore. Even today, on a sunny day, spot prices for electricity are either very low or even negative. The more solar power is available, the lower these prices will be. So your balcony power station is replacing electricity you could get for free anyway. At night, when you are not producing electricity, you still need to buy the expensive electricity from fossil plants.

The reason why personal solar installations are profitable is that you can buy electricity for fixed prices from your local power company. You pay the average of the vastly different low (or negative) prices during the day and the extremely expensive prices on windstill nights. Solar allows you to use your own electricity when the average is below spot prices, and get power for much less when the price you pay is cheaper than spot prices. It's like a state-approved scheme to play the market in the name of decarbonization while actually increasing everybody else's prices and possibly even CO2 emissions.

Over the last 12 months, AI agents have become dramatically better. And in the last 3 months, they have reached a point where, with some light guidance, they can write 100% of the code. Most skeptics have been convinced and are now realizing the impact. That's what you see in the stock market.

I don't know where the ceiling is. And how much of the improvement was due to better context engineering, and how much to better models. I would expect the context engineering to plateau very soon. Not sure about the models.

An even more dramatic change for the whole economy will be when non-IT, non-creative office clerks are replaced. This is mostly a matter of redesigning the interfaces around them. AI could probably do already most of the work, but getting the tasks to the AI, using their output, and communication with third parties are still a major challenge. Like someone processing insurance claims. AI needs a way to get the claim, to contact third parties (write emails to humans, communicate with other AI agents, maybe even call humans), and then to initiate the payout. It's already doable with today's technology, but still a lot of work.

The Sideprocalypse 5 months ago

What’s your differentiator over Readwise?

Simplicity. I can get you reading your first feed in under a minute. Also, I am not really thinking about monetization right now, but I am building a feed reader I want to use. I wouldn't want to spend $13 a month for it.

thin UI + OSS pipeline

No, the UI isn't that thin. I am optimizing it to minimize my costs for operating it. Everything I can do inside the client is done inside the client. Interactions with the server are mostly limited to polling every 2 minutes for feed updates, and sending read markers after 3 seconds of inactivity. Feed data is stored on CDN, compressed.

The Sideprocalypse 5 months ago

I think you're in a tough market, but I'll agree that Feedly hasn't gotten much love, and is clearly aiming for a more enterprise market.

Yes, enterprise is certainly where the money is (Feedly's plans start at $1600/month...), but as a solo dev working on a side-project, that's not an accessible market for me anyway. So I try to create a service that's simple and cheap.

My AI agent is (probably) going to do a better job of choosing the most relevant stuff.

The idea would be basically: the feed reader know the user's interests because of the subscriptions, and knows the last time the user logged in. So it can filter what happened since then; it can also order the posts by relevance, allowing the user to catch up. And in a second step, an agent could even write the posts dynamically, summarizing information gathered from the user's feed, possibly even adjusted to the user's level of knowledge and offering background info where needed.

And personally, less interested in podcasts in my RSS app. That's something for Pocket Casts / AntennaPod. I like my audio separate from my RSS.

There are some feeds that are more like a mixture of text and podcast. I usually read only the text, but sometimes it catches my interest and I want to listen to one or two posts. That's when I start hating the lack of podcast support in Feedly.

The Sideprocalypse 5 months ago

I am not familiar with Nextcloud News. In the first version, it probably won't offer much for you, besides having a catalog of feeds, the ability to search them, and subscribe with one click, which is usually not offered by non-cloud RSS readers.

For people who do not want to use self-hosted services (which generally includes me), it offers simplicity. Open the page, choose Google as auth provider, confirm, and you will get a friendly start page. Click on 'follow' on one of the feeds, and you can start reading immediately. The UI is more like Facebook or X, so basically, you just need to scroll. Either in a feed of your choice, or all your feeds. It's designed to work well on small mobile screens, tablets, and desktops, with great keyboard support on the latter. Larger screens use two or three columns.

The Sideprocalypse 5 months ago

Mainly, a friendly and simple UI. Feedly looks like it hasn't gotten much love recently. Inoreader is too cluttered for my taste, though it has a feature set I can't match any time soon.

I have plenty of other ideas for what to build on top of it: offering an SDK and APIs so you can vibe-code the UI you want, a built-in podcast listener, using news from aggregated feeds to build a personalized AI feed. But the first step is to reach the Google Reader feature set minus social features.

The Sideprocalypse 5 months ago

Maybe it's wishful thinking, being one of the SaaS-developing developers he describes. But I think that only the complexity required for a SaaS is increasing. You certainly can't earn millions with the kind of SaaS that used to take a week or two, and can now be done on a weekend. So I am trying the kind of SaaS that I never dared to start, knowing that it would take a year or two of my spare time. And with AI agents, I now hope to complete it in 3 or 4 months, with a lot of extra features I would never have dared to include in an MVP.

That assumes that it can easily reproduce the issues. But it's not good at interacting with a complex UI like a human user.

10 minute is not the limit for current models. I can have them work for hours on a problem.

Admittedly, I have never tried to run it that long. If 10 minutes are not enough, I check what it is doing and tell it to do what it needs to do differently, or what to look at, or offer to run it with debug logs. Recently, I have also had a case where Opus was working on an issue forever, fixing one issue and thereby introducing another, fix that, only for the original issue to disappear. Then I tried out Codex, and it fixed it at first sight. So changing models can certainly help.

But do you really get a good solution after running it for hours? To me, that sounds like it doesn't understand the issue completely.

I wonder how our comments will age in a few years.

I don't think there will be a future where agents need to work on a limited piece of code for hours. Either they are smart enough to do it in a limited amount of time, or someone smarter needs to get involved.

This can't be a serious project. It must be a greenfield startup that's just starting.

I rarely review UI code. Doesn't mean that I don't need to step in from time to time, but generally, I don't care enough about the UI code to review it line-by-line.

"Agents should work overnight, on commutes, in meetings, asynchronously."

If I read stuff like that, I wonder what the F they are doing. Agents work overnight? On what? Stuck in some loop, trying to figure out how to solve a bug by trial and error because the agent isn't capable of finding the right solution? Nothing good will come out of that. When the agent clearly isn't capable of solving an issue in a reasonable amount of time, it needs help. Quite often, a hint is enough. That, of course, requires the developer to still understand what the agent is doing. Otherwise, most likely, it will sooner or later do something stupid to "solve" the issue. And later, you need to clean up that mess.

If your prompt is good and the agent is capable of implementing it correctly, it will be done in 10 minutes or less. If not, you still need to step in.

I don't know what it is, but trying to coax my goddamn tooling into doing what I want is not why I got into this field.

I can understand that, but as long as the tooling is still faster than doing it manually, that's the world we live in. Slower ways to 'craft' software are a hobby, not a profession. (I'm glad I'm in it for building stuff, not for coding - I love the productivity gains).

Generally, my stance is that I add more value by doing whatever ridiculous thing people ask me to change than waste my time arguing about it. There are some obvious exceptions, like when the suggestions don't work or make the codebase significantly worse. But other than that, I do whatever people suggest, to save my time, their time, and deliver faster. And often, once you're done with their initial suggestions, people just approve.

This doesn't help all the time. There are those people who still keep finding things they want you to change a week after they first reviewed the code. I try to avoid including them in the code review. The alternative is to talk to your manager about making some rules, like giving reviewers only a day or two to review new code. It's easy to argue for that because those late comments really hinder productivity.

>because that's how management decided we should work, there's no point

If you are personally invested, there would be a point. At least if you plan to maintain that code for a few more years.

Let's say you have a common CSS file, where you define .warning {color: red}. If you want the LLM to put out a warning and you just tell it to make it red, without pointing out that there is the .warning class, it will likely create a new CSS def for that element (or even inline it - the latest Claude Code has a tendency to do that). That's fine and will make management happy for now.

But if later management decides that it wants all warning messages to be pink, it may be quite a challenge to catch every place without missing one.