[HN Gopher] The Missing Protocol: Let Me Know
___________________________________________________________________
The Missing Protocol: Let Me Know
Author : deanebarker
Score : 135 points
Date : 2025-08-12 20:15 UTC (1 days ago)
(HTM) web link (deanebarker.net)
(TXT) w3m dump (deanebarker.net)
| kmoser wrote:
| 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.
| SirFatty wrote:
| Isn't this what RSS is for though?
| baruz wrote:
| https://xkcd.com/927/
|
| You know which one.
| jjmarr wrote:
| it's a funny comic but Unicode was created as a "universal
| standard" for character encoding and has actually been
| successful at it.
|
| Ditto for power adapters. Every laptop now uses USB-C
| instead of weird barrel plugs.
| eqvinox wrote:
| I need to point out a subtlety that is might or might not
| be intended in that comic: it's bystanders, or consumers
| of the 14 standards, trying to fix it.
|
| Unicode was invented by Xerox and Apple employees. USB-C
| was developed "by Intel, HP Inc., Microsoft, and the USB
| Implementers Forum."
|
| To be clear, it's not about the huge companies, it's
| about the people doing the heavy implementation work.
| They can change 14 standards into 1. And in most cases -
| with rare exceptions - _only they can do that_.
| kmoser wrote:
| That's an example of the type of existing agent that I was
| alluding to. So you're not wrong, but it doesn't change what
| I was suggesting.
| 0x696C6961 wrote:
| It could be implemented as some type of extension to RSS.
| cxr wrote:
| No extension is necessary. There's nothing that says a
| website has to have exactly 1 or 0 RSS feeds and that they
| most be for global syndication. Anyone in control of their
| site can dump a plain ol' RSS (or Atom, or JSON) feed at
| /foo/part-3-has-been-posted.xml. I've done this on my own
| site.
|
| This is not (really) a technical problem. It's a cultural
| one--getting people to actually make hyperspecific micro
| feeds available.
| akoboldfrying wrote:
| 100% this. Per-topic RSS feeds solves this perfectly.
| waterproof wrote:
| Nah an RSS feed has the ability to contain n feed items.
| This proposed new protocol would have a maximum of 1
| item. The closed contract (1 notification only, ever)
| makes sure that it doesn't become yet another avenue for
| producers to push content that you didn't ask for.
| akoboldfrying wrote:
| "RSS but for just 1 item" and "A brand new protocol that
| is functionally equivalent to RSS for just 1 item" are
| both just contracts. What makes you think that the latter
| is more enforceable?
| zaphirplane wrote:
| > assuming you know what the URL
|
| This is the tricky bit thou and will come down to chicken and
| egg problem of adopting some convention
| 01HNNWZ0MV43FF wrote:
| Actually it's super-easy, barely an inconvenience.
|
| Dedicate a portion of your site to notifications. Allocate
| the URL there with a blank page that has a meta 404 tag or
| something.
|
| When blog post is live, replace the meta 404 with a meta
| redirect to the real permalink.
|
| You can do an all-manual URL shortener for QR codes the same
| way. That means you can also have a QR code for this kind of
| subscription, which is cool
| losvedir wrote:
| Ah yeah, simple manual methods are tight.
| zaphirplane wrote:
| How does the user agent know this is 2 of 4 or 2 of 2
|
| Anyways the convention isn't too hard it's the adoption by
| authors and software that will be tricky
| dragonwriter wrote:
| > This is the tricky bit thou and will come down to chicken
| and egg problem of adopting some convention
|
| Sure, there needs to be a standard for this, but it could be
| as simple as using a new rel value, say, "futurecontent", and
| title (when used with <link>) or content (when used with <a>)
| giving the description of what will be found at the link when
| it is ready.
| themafia wrote:
| What if you want to change the URL between the time you choose
| the name and the time you decide to actually publish it? How do
| you resynchronize those clients? Or are you forced to now serve
| a redirect as well?
| oneeyedpigeon wrote:
| If you must change the URL then, sure, serve a redirect. This
| is exactly the same as all your existing URLs, so I don't see
| what the problem could be.
| themafia wrote:
| Unless you're using a third party service to provide this
| API. In any case, since this API likely won't manage the
| redirects for you, you're going to need to coordinate that
| separately. Seems to be against the use case this was
| intended to provide.
|
| "Technically possible" and "likely to work well" are two
| different things.
| oneeyedpigeon wrote:
| Exactly--you could also have a <link rel=next in the part 2
| document with that URL.
| warkdarrior wrote:
| "Would you like to receive notifications from this website?"
|
| No, thank you.
| stormbeard wrote:
| Isn't this just RSS?
| IshKebab wrote:
| No.
| maxbond wrote:
| The thing that's different with this proposal is that it's
| specified to be a one-shot notification. If RSS is a
| channel/topic than "let me know" is a rendezvous. You could
| build it on top of RSS (or ActivityPub, XMPP, webhooks, ...).
| nickelpro wrote:
| Then it's not a missing protocol. The protocol is RSS. They
| want some specific app that is doing a thing with RSS.
| maxbond wrote:
| Protocols are normally built on top of other protocols. RSS
| could be the transport for "let me know." (Though my
| recommendation would be ActivityPub, XMPP, or email.)
|
| Whether that is a protocol or an application running over a
| protocol is semantics, either interpretation is valid.
| deathanatos wrote:
| Any bog standard RSS app should work here.
|
| RSS, literally and with no modifications, solves the use-
| case outlined in the article. The URL is just a specific
| one-shot feed, and TFA's request is just a request for
| such a convention of one-shot feeds.
| yunwal wrote:
| No need for a separate protocol here. You can just read
| an rss feed until you get a hit on your filter and then
| stop reading it. Same data over the wire, just a
| different client.
| _QrE wrote:
| 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.
| wpm wrote:
| > Yes, it's more work on your side
|
| How much work, and is Part 3 gonna be so mindblowing to be
| worth it?
|
| > asking the creator to manage updates for whatever
|
| Managing updates in this case is...posting Part 3? Something
| they were already gonna do? Except now there's also some
| machine-only endpoint that needs to start returning "Yes"
| instead of "No"? Doesn't sound like a ton of work.
|
| > Why would you not involve yourself in the new hotness? You
| _can_ put AI into this.
|
| Because just involving yourself with the new hotness just
| because it is the new hotness is pathetic. I _can_ put AI into
| this, but why would I? Why would I add all the heft and
| complexity and stupid natural language bullshit talking to a
| computer when I could just press a button that will do this for
| me deterministically?
| yunwal wrote:
| How is this different than just curling the endpoint? It
| seems like you might be asking the producer to be able to
| execute any arbitrary calculation across their (codebase?,
| website? Thing?). The reason it's never been implemented is
| because it's impossible
| rambambram wrote:
| 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. ;)
| neilk wrote:
| Seems a bit like webhooks?
|
| https://en.wikipedia.org/wiki/Webhook
|
| Although your model is polling rather than making the other
| server push something.
| IshKebab wrote:
| Webhooks are not relevant to this use case.
| oreilles wrote:
| Webhooks would be much closer to a sane solution to this use
| case. Why would you spam a web server asking repeatedly
| wether something has happened or not, instead of just
| providing him with an adress so that he can simply let you
| know in due time ?
| IshKebab wrote:
| Because then you have to maintain a publicly accessible
| server, and he has to maintain a database of everyone who
| has clicked the button. It wouldn't be "spamming", just
| loading a tiny endpoint once a day (or less!) is a trivial
| amount of traffic.
|
| Doing it your way would be completely unworkable.
| wpm wrote:
| It's not spamming any more than me opening their website
| myself in a browser, loading their entire webpage, looking
| "Is part 3 posted yet", and doing that every day until part
| 3 is posted.
|
| Except this idea is automated, and wouldn't need to load
| the entire website.
| SethMLarson wrote:
| Filtered RSS with some automation (ie: to delete the
| subscription) will do this for you.
| octagons wrote:
| 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
| maxwellg wrote:
| 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.
| 0xCMP wrote:
| 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.
| Martin_Silenus wrote:
| RSS for lazy people who can't bother filtering their RSS reader
| is probably a very promising concept.
| wpm wrote:
| Well, yeah, who wants to sit and dick around with filters? I
| just want to know when "Part 3" is posted or whatever. I don't
| want to "subscribe" I don't need a feed of every thing they've
| ever written being filtered, just go fetch "is part 3 up yet".
|
| I could sign up for e-mails too and just use mailbox filters. I
| bet something for "lazy" people who have better things to do
| than sit and dick around with their mailbox filters is a
| promising concept.
|
| "wow part 2 was good, can't wait for part 3!" _clicks Let Me
| Know_.
|
| vs
|
| "Wow part 2 was good, let me subscribe to the RSS feed and go
| somewhere else and figure out a filter for part 3"
|
| If I gotta go somewhere else, switch apps, whatever, I'm not
| interested, and it's not gonna happen. My brain has already
| moved on.
| throwaway81523 wrote:
| 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.
| wpm wrote:
| Part 3 itself would be the thing the gobblers are interested in
| though, right? THis Let Me Know thing can just hit a URL and
| get back a "yep, 200, its up" or a "nope, 204, not yet".
| AndrewKemendo wrote:
| 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)
| cbdumas wrote:
| 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
| nateroling wrote:
| 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.
| jagged-chisel wrote:
| Marketing has, and will continue to, ruin notifications. One
| time notification paint is ready? Surely, they think, they can
| upsell you on other related and tangential products. You know,
| to ~~keep the cash flowing~~ help you be more successful at
| your DIYing.
| 01HNNWZ0MV43FF wrote:
| Improvements are still improvements.
|
| How does a good actor do this in good faith right now?
|
| Email? Costs money. SMS? Costs money. RSS? Wildly unpopular.
| ActivityPub? Can't be statically hosted and fairly unpopular.
|
| Right now they basically use fucking Facebook and fucking
| Twitter, and even then you're subscribing to an entire
| stream.
| deathanatos wrote:
| > _Marketing has, and will continue to, ruin notifications._
|
| This is one of my personal "Laws", except it's not just
| notifications. _Any communications medium_ will eventually be
| ruined by spam. What makes a medium useful to legitimate
| consumers /users is what makes it a target for "marketing",
| i.e., spam.
|
| I've seen multiple media ruined by marketing in my lifetime.
| This isn't a technological problem.
| sneak wrote:
| It is technically trivial to make a forwarding email address
| that works once and only once.
| bborud wrote:
| That was the first thought that struck me when I saw the
| headline and tried to guess what the posting was about before
| clicking the link. At least 2-3 times per week I find myself
| wanting something like this. Often it involves leaving my email
| address or my phone number to have someone contact me. Or
| having to check back.
|
| In its simplest form, this isn't all that hard to build. The
| tricky bit is to get people to use it. And perhaps even to
| explain what it does and possibly how it works.
|
| If someone knows how to sell it, I'd be willing to build it.
| arendtio wrote:
| 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).
| cigarette66 wrote:
| 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.
| p1necone wrote:
| This criticism basically boils down to "what if the site is a
| bad actor/incompetent", which I guess is a legitimate concern,
| but would be just as meaningful of a criticism against
| basically any feature I can imagine. Alas we continue to have
| useful interactions with third parties despite this.
| samantha-wiki wrote:
| 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
| 01HNNWZ0MV43FF wrote:
| Email is very hard because all the big providers want to
| defederate from all the single-user instances.
|
| You can use something like ntfy.sh, where you create a channel
| on a public relay and do pub/sub
| mockingloris wrote:
| > Email is very hard because all the big providers want to
| defederate from all the single-user instances.
|
| Hard truths. Reinforces this authors reasons for a edging for
| a solution.
|
| |
|
| +-- Dey well; Be well
| singpolyma3 wrote:
| You want an RSS feed filtered to only the events you are looking
| for
| gurjeet wrote:
| 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
| RiverCrochet wrote:
| 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.
| m82labs wrote:
| 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.
| yunwal wrote:
| 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.
| hoistbypetard wrote:
| The protocol is not being specified. Requirements for such a
| protocol are being proposed. Though my assumption from reading
| these requirements would be that the user-agent would be
| performing an HTTP GET request.
|
| Whether proposing requirements for a protocol without proposing
| a specification is ragebait or not has more to do with the
| individual reading the proposal than the proposal itself; I did
| not find it the least bit enraging.
| yunwal wrote:
| What requirements are being proposed here? It seems like
| we've got a requirement for a separate endpoint, but no
| explanation as to why it's necessary (as opposed to just
| requesting the endpoint(s) you're interested in). Then we've
| also got a response format with no proposed request format
| for a task that as described is impossible to specify.
| mattnewton wrote:
| 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'
| tbeseda wrote:
| 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/
| bborud wrote:
| Nothing kills my will to try to solve a problem like trying to
| express it in terms of something that was intended for a
| different purpose and didn't really succeed at that.
|
| Your suggestion is a valid one, but I think the best way to
| solve something like this is to _first_ look at how you'd solve
| it from scratch. Or at least try to figure out what problem you
| actually want to solve.
|
| I usually avoid looking at how other people have solved a
| problem until I have had a chance to think about it myself.
| Then, when I have given it some thought, I go back and look at
| what other people have done. This occasionally leads to novel
| ideas.
| themafia wrote:
| 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.
| mockingloris wrote:
| @themafia Adding to your nice suggestions:
| "expected" in place of "delay" "modified" in place
| of "when"
|
| _My addition:_
|
| - Include retry logic: Add a "retry_policy" field (e.g.,
| exponential backoff) for failed callbacks
|
| |
|
| +-- Dey well; Be well
| weinzierl wrote:
| 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.
| weinzierl wrote:
| 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?
| paulmooreparks wrote:
| 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.
| posix86 wrote:
| 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.
| quadhome wrote:
| WebSub[1] has been a standard for real-time notification of
| changes for at least a decade.
|
| [1] https://en.wikipedia.org/wiki/WebSub
| TheFuzzball wrote:
| 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.
| mrbluecoat wrote:
| > 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.
| bayindirh wrote:
| They want a one-time feed. The browser or agent can unsubscribe
| from that single event feed when that thing happens.
| anjanb wrote:
| couldn't he use google alerts ? I've used google alerts to alert
| me about events
| deanebarker wrote:
| I followed up with this:
|
| "The Missing Service: Notify One Time"
| https://news.ycombinator.com/item?id=44890642
___________________________________________________________________
(page generated 2025-08-13 23:02 UTC)