The Missing Protocol: Let Me Know

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.

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.

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).

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/

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.

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 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.

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.

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.

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.

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

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