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

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.

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.

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.

> I don’t want to “subscribe.” I just want to know when this ONE THING happens

What kind of magic was expected? Technology isn't clairvoyant (yet) so pubsub or callbacks is the expected advice.

I'm not in love with "delay" as a property name. I think "expected" might be more appropriate. I also don't think it should be a integer meant to be number of seconds. You might be better off with ISO8601 datetimes and intervals which would give you greater flexibility in the meaning of this field.

I also think "when" is a bad property name. I think "modified" might be more appropriate. That allows for the event to be updated more than once if necessary as well as allowing events to signal that they expect to trigger more than once.

Anyways.. neat idea.

  "expected" in place of "delay"

  "modified" in place of "when"

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.

Two other use cases spring to mind:

- "GitHub: Let me know when this PR is merged" - "Store: Let me know when this item is in stock"

Unfortunately I think it's only useful if it works everywhere, so we can't rely on every website implementing it themselves.

WebSub[1] has been a standard for real-time notification of changes for at least a decade.

[1] https://en.wikipedia.org/wiki/WebSub

You can tell chatgpt to notify you when something changes about something, and tell it how often it should check. It currently sends you a notif even if nothing changes, but that's easily swiped away. So in your case you could say: Tell me if this blog <link> releases part 3. Check once a week.

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

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'

A couple of my friends created a startup called Omnibrowse in the late 1990's to do exactly this, and sold it to Microsoft shortly after. I figured this would be a commodity feature by now.

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.

couldn't he use google alerts ? I've used google alerts to alert me about events

I think polling is not the best approach. We have PubSubHubbub as a protocol. What we lack is a public, and independent subscriber infrastructure.

I think the proposed anonymity and ephemerality could provided by that approach if there is enough interest.

Apart from the protocol and technical sides: What would be the most practical solution today that follows the spirit if the post? What do people use for RSS nowadays? What for sites and services that don't provide RSS?

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

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

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

Seems a bit like webhooks?

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

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

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

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

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.

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

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.

Isn't this just RSS?

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

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)

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

No, thank you.