The Missing Protocol: Let Me Know

By Deane Barker • •

I want a new protocol, tentatively called “Let Me Know” (LMK). The purpose is to provide someone an anonymous way to get notified when a singular, specific event occurs.

Here’s a basic use case:

Some random blog author has published Parts 1 and 2 of a series. You enjoyed it, and you want to know when Part 3 is published.

You don’t want to give away any personal information, you don’t want to subscribe to an RSS feed of other content, you don’t want to follow them on social media, etc. You just want an anonymous way to find out when Part 3 is published without having to manually check their website and evaluate it for the content.

My idea is that there’s a button at the bottom of Part 2, called “Let Me Know.”

The user clicks this, and it registers an endpoint with some agent.

Whatever agent registers the endpoint will ping the end point at a specific interval. Let’s say once per day by default.

The endpoint will often simply return:

{
  "happened": false
}

Or:

204 No Content

Either of those responses mean, “The subscribed event has not happened yet. Check back later.”

Alternately, the endpoint can advise the agent when to check again.

{
  "happened": "false",
  "delay": 604800 // Don't check again for one week
}

Your agent will keep dutifully checking on its default schedule, or obeying the delay response if it’s provided.

But hopefully, on some bright shining day in the future, something like this will be returned:

{
  "happened": true,
  "when": "2025-08-06T05:38:20.234Z",

  // This can be included in the notification
  "message": "Part 3 of the Awesome Blog Post Series has finally been published!",

  // The notification can provide one or more things to do from here
  "actions":
  [
    {
      "Read the post",
      "https://domain.com/part-3"
    },
    {
      "Visit the home page",
      "https://domain.com/"
    }
  ]
}

You will get this notification… somehow.

But somehow, you will be notified that the event – whatever the thing was you were waiting for – has occured.

And then – and this is key – the endpoint is automatically deleted from your agent.

The event has happened, so the agent does not check again. The one task you assigned to it has been completed. If you want to find out about Part 4, you’ll subscribe (presumably) using a button at the bottom of Part 3. Or not. Whatever.

At any given time, you can review the endpoints registered in your agent, see when they were registered, when they were last checked, when they are scheduled to check again, force then to check again, etc. And you can delete any that you don’t really care about anymore.

As for the button that lets you subscribe to the event (which has now occurred), a few things could happen:

  1. The author could manually delete it.
  2. If the endpoint architecture was built into their CMS, it could be automatically suppressed when the event happens (or, more likely, proactively display when the event hasn’t happened yet; default would be to not display).
  3. The button could consist of some client-side code that would ping the endpoint itself and decide whether or not to display.

If the button still shows up after the event has occured, it’s not that big of a deal. If an agent tries to register an endpoint for an event that has occured, the worst that could happen is that it notifies immediately. Alternately, the agent could detect this when it tries to register and notify the user that there’s no point in registering it and provide the actions from the response.

From the author’s standpoint, their CMS or other system could have an “LMK Control Panel” that would let them register new endpoints, manually resolve endpoints by providing messages and actions (they would “publish a resolution,” archive endpoints, get “ping analytics” of the traffic to specific endpoints, etc.

And… that’s it. That’s all it does.

You register an endpoint, the agent starts checking it, and then the agent lets you know when the endpoint returns in the affirmative.

You have never given anyone any personal information. Your agent checking the endpoint is as anonymous as you visiting the website. There is no commitment or cognitive overhead – you’re not exposed to a bunch of other events of content you don’t care about, and if the event never happens, you will never hear about it again.

There’s no AI to this. No magic. No problems to be solved. Like any standard or protocol, it’s just a matter of agreeing on it and evangelizing it.

But…

I showed this all to a friend, and he pointed out the “Subscribe” button “at the bottom of every YouTube video.”

I responded:

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

There might be 20 unrelated videos between the one I watched and the Part 2 that I want to see. Just yell when Part 2 is out, and then never talk to me again and forget we ever had this interaction, unless I subscribe to something else.

And he responded with the cold, hard truth:

That makes sense. I can understand why you’re asking for that, and can understand why creators would never want to build it

…[sigh]. Yeah.

Technical Postscript

The only thing I might add is a /meta pseudo-endpoint that would provide data about the endpoint. It could return something like this:

{
  "created": "2025-08-05",
  "purpose": "To notify when Part 2 of Awesome Blog Post Series is published"
  "contact": "deane@deanebarker.net <Deane Barker>",
  "happened": false // So the agent can filter for active events
}

Your agent could retrieve this when the endpoint is registered and use the data to maintain its list and give you more information about the endpoints you’re checking.

This is item #0 in a sequence of 362 items.

You can use your left/right arrow keys to navigate