It (hopefully) took exactly 30 seconds, the page delays every item until 30 seconds after its posted date. It doesn't poll HN's server, it opens a websocket to the official HN Firebase, and without the delay, items appear in large chunks. I'm pretty sure the HN server syncs with Firebase every 30 seconds, so this is as fast as it can go while still being accurate.

Interestingly some comments appear as [delayed].

I tried this, but it required making a request for every comment and would probably call for a backend, wheras this can run just off of the Firebase websocket stream on a static HTML file.

Haha, my version makes a websocket connection to the official Firebase that the HN servers already send everything to, so it is zero extra load on HN

Yours is the MUCH better approach. When I did it, no api!

That sounds interesting, are there any public details on this? Is it https://github.com/HackerNews/API ?

You can stream the ID of the most recent item with something like this:

  curl -N -H "Accept: text/event-stream" "https://hacker-news.firebaseio.com/v0/maxitem.json"

Then you will need to iterate through the new item IDs and fetch them, e.g.

https://hacker-news.firebaseio.com/v0/item/45534174.json

The instance https://cobalt.meowing.de is currently working for YouTube, which is very useful

thanks, didn't knew but I guess, its great!

Another thing I like about cobalt is the api, I had cooked something that could be a bang in duckduckgo of sorts that would download the video from the api of cobalt but I just couldn't deliver the bang and also I needed some custom facing thing in the background but now I think that I can have something like cloudflare.

Imagine having this thing in browser where !yt-dlp <youtube video> just downloads it or refers us to a working cobalt instance y'know.

I might build something like this for cf workers or smth. What are your thoughts?

https://altstore.io is the big one. You might want the AltStore fork SideStore (you can do the weekly reinstall without a computer, https://sidestore.io). Other tools exist, like https://sideloadly.io and https://appdb.to.

Currently, we're pretty limited on 5-character ab.xy domains, and they'll cost you over $1000 USD to register[1]. However, 6 and 7 character domains are available, and can indeed be really useful!

[1]: https://micro.domains

It looks like it's just the HN submitted title which is wrong (currently "Why the Original Macintosh Had a Screen Resolution of 512×324"). The article's title is "Why the Original Macintosh Had a Screen Resolution of 512×342", and "324" doesn't appear anywhere on the page.

Looks like someone is reading Hacker News comments and editing the page - archive.org captured the page probably mid-edit, and it says "324" in one place: https://web.archive.org/web/20250527202300/https://512pixels...

Oh that's priceless. Real time HN feedback loops.

Wouldn’t be the first time.

How would the OS know if the app that the browser is querying about is actually the current page? For all the OS knows, the user might be quickly visiting a ton of play.google.com pages for the top 1000 apps on the app store.

> How would the OS know if the app that the browser is querying about is actually the current page?

Maybe i’m missing something, but it sounds like it would be easy for google to support this functionality by letting developers configure this in their app “bundle”. A property that tells the OS “my app is related to domain example.com”. Make it an array of domains if you must.

> A property that tells the OS “my app is related to domain example.com”. Make it an array of domains if you must.

Elaborating on the sibling's comment: There is already such a property that apps must set in their manifests in order for them to be able to react to links/intents for domain-associated-with-the-app.com.

But it doesn't address the question of how a browser is supposed to be able to open links to domain-associated-with-the-app.com in that app, without Android revealing to the browser whether the app is installed or not. In short: The browser will, by construction, be able to determine which apps you've got installed or not.

I mean, do Windows or macOS tell the browser which mail apps you have installed when it handles a mail:// URI?

No, but web browsers do have the ability to ask the OS which application is associated with a certain url type.

But it doesn’t leak that information to web pages.

Intent filters can be for domains. It's how deeplinks work. But with querying being locked down you can't know what apps can handle a deeplink.

make it into a system dialog?

But God forbid users learn how to use their device. All of this could be prevented by having the users manually pick the application instead.

Those articles are paywalled:

https://archive.is/GWvCX https://archive.ph/ckFB2