This could be even easier to implement than the author suggests, at least for the cited use case of when a new web page is published (e.g. Part 2 of an article). The simplest solution--assuming you know what the URL will be--is to have your agent of choice periodically check whether that URL returns 200. That greatly simplifies the protocol since it piggy-backs off the existing HTTP protocol, and makes it easy to write your agent (or use an existing one). All that's left would be for authors to publish what the next URL will be; nothing else on the back end is needed.

"Would you like to receive notifications from this website?"

No, thank you.

Isn't this just RSS?

Maybe I'm misunderstanding something, but you can add filters to RSS feeds. What is proposed is pretty much just RSS, except for one specific item. Yes, it's more work on your side, but asking the creator to manage updates for whatever one thing any/every random person is interested in is pretty unrealistic, especially since the people asking for this are going to be explicitly not interested in everything else about the creator.

> There’s no AI to this. No magic. No problems to be solved.

Why would you not involve yourself in the new hotness? You _can_ put AI into this. Instead of using some expression to figure out whether a new article has links to the previous ones in the series / a matching title, you can have a local agent check your RSS feed and tell you if it's what you're looking for, or else delete the article. For certain creators this might even be a sensible choice, depending on how purple their prose is and their preferred website setup.

I would prefer to do something like the author described with RSS, but nice thinking and interesting concept.

Also a nice blog in general, I subscribed with RSS. ;)

Seems a bit like webhooks?

https://en.wikipedia.org/wiki/Webhook

Although your model is polling rather than making the other server push something.

Filtered RSS with some automation (ie: to delete the subscription) will do this for you.

I’ve always used huginn[0] for these types of tasks, though the learning curve/implementation is a bit cumbersome for more trivial tasks like the proposed scenario.

[0] https://github.com/huginn/huginn

This is conceptually extremely similar to the Web Push API: https://web.dev/articles/push-notifications-web-push-protoco...

You'd need something at the browser/UA level to unsubscribe or to make the subscription exist for only a single message. Bad content publishers have taught us to never allow Web Push notifications since they always get inundated with marketing and other nonsense - being able to bake protections against that into the spec could be interesting.

I want this to exist, but so few would adopt it that would make it mainstream/normal to use because a lot of those places rely on getting your email to tell you about other things.

This would be fairly limited to blogs which have no intention of writing a newsletter or consistently enough to merit subscribing via RSS.

Although I'd love for everything I just said to turn out to be false.

RSS for lazy people who can’t bother filtering their RSS reader is probably a very promising concept.

Overaggressive LLM scrapers have probably destroyed the feasibility of this idea, independently of whether the idea itself is any good. There are now captchas and other roadblocks in front of everything, which stop even tiny amounts of automation because of the sites getting hammered by the huge gobblers.

Isn’t this exactly handled with IFTTT?

I know I’ve used IFTTT for precisely that because it’s the simplest and often free (when no major hardware installation is needed) off the shelf way to do it

Or is the author asking that a service host user defined notifications?

If the latter that’s a different design pattern

The http protocols already allow for this, if that’s the case then the op just seems like he wants other people to instrument their systems for his desired interface type (user defined notifications)

A few years ago I came across (probably on HN) this little Firefox extension that I quite like https://addons.mozilla.org/en-US/firefox/addon/fraidycat/ . Seems like it could help you fill this use case although as other commenters are saying I'm not sure I understand the distinction with RSS

This, but for many things.

Paint is ready at the hardware store Table is ready at the restaurant Construction is done on a bridge

All kinds of things that we need a one-time notification for.

The big question here is who defines the events. I mean, the protocol suggests that the sender should describe the event and offer a simple button for it.

But in reality, the receiver knows a lot more about what he is interested in. Some people might want to get an update for the next blog post, while others may be interested in updates for the next blog post that completes a particular series, and so on.

When the sender defines the events, you can use a new protocol; however, if the receiver determines the events, all you need is a client with a rules engine (e.g., IFTTT).

Apart from the technical implementation I'm surprised the writeup didn't catch the flaws in such a setup.

The notifyer has no obligation to actually notify correctly. They can spam some advertising site or malicious site.

The notifee (?) has no way of checking that the notifyer has fulfilled their promise.

For example I could say 'let me know' when an update on the new cheese factory happens. Then the wait is too long so the notifyer does a 'semi fulfillment' of the promise. The notifee clicks, is disappointed and has nothing more to vote with since they never had something like a subscription in the first place.

It seems like an alternative might be something along the lines of this, just a rough sketch

- Alice wants Bob to notify her about something

- Bob advertises an email address specific to that something

- Alice creates a disposable email address and requests that Bob notify her about that something at that disposable email address

- Alice only accepts emails to that address from Bob's something-specific email

- Once Alice receives an email from Bob's something-specific email she discards the disposable email

You want an RSS feed filtered to only the events you are looking for

Shameless plug and completely tangential: Since we're talking about protocols we need, I wrote a specification called ToolsConfig that aims to reduce the clutter in our software projects (think of all the Makefile, package.json, .npmrc, .vscode/, .gitignore, etc. files and directories that clutter our software projects' directories and sometimes even sub-directories).

https://news.ycombinator.com/item?id=44883130

An expiry time should be required and not optional, or a default one well specified (e.g. 30 days). The endpoint shouldn't have to keep reporting that "something has happened" to agents forever.

Maybe ...

- When the expiry time is passed, any queries to the endpoint are invalid and shouldn't be performed. If they're performed anyway, the endpoint may simply not respond if it's feeling rude, or it can respond with 410 Gone or something like that if it's feeling nice.

Also what if the agent has registered more endpoints than the endpoint can handle. 429 Too Many Requests seems appropriate.

Also the agent should be required to confirm with the user or otherwise warn if the "happened" URL is not in the original domain of the request.

I guess my first thought here is that I would just implement this on my blog platform as a series specific RSS feed. Generating an RSS feed per series and even per tag would be trivial to implement and make for a decent user experience. IMO.

Am I missing something? Is this ragebait? There is no protocol specified here. The format of the “let me know” request is not specified at all.

Why not build an rss reader that implements this interface? That way all the blogs that support rss give you this for more or less free? You can even sprinkle a cheap llm to determine if the new updates to the feed satisfy your plaintext definition of 'thing happening'

You could probably consider a broader interpretation of ActivityPub for something like this; or the underlying ActivityStreams format.

It was conceived for social networking, but social networking doesn't have to be just 140 characters in a timeline.

https://www.w3.org/TR/activitypub/