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.
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.
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.
"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?
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.
> 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.
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?
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.
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.
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?
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
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
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'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.
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.
> 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.
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.
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)
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.
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.
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".
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'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.
This almost seems like a web-i-fied 'reminder' system - and I've found one-and-done memory-aid-type reminders to be the area least addressed in current systems.
I think this can be easily implemented with the Distill Web Monitor browser extension [1]. Just monitor the post listing page, set a CSS selector for the post titles, and add a text condition (e.g., "Awesome Blog Post Series").
From there, you can choose how often it checks and how you want to be notified (e.g., browser notification, email, etc.).
You can run it for free on your browser or pay for the cloud version.
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.
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.
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'
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.
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.
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.
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 ?
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.
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.
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).
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.
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?
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.
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, ...).
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.
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.
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.
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.
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.
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.
Isn't this what RSS is for though?
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.
It could be implemented as some type of extension to RSS.
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.
100% this. Per-topic RSS feeds solves this perfectly.
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.
"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?
https://xkcd.com/927/
You know which one.
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.
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.
> 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
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
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
Ah yeah, simple manual methods are tight.
> 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.
Exactly—you could also have a <link rel=next in the part 2 document with that URL.
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?
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.
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.
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.
> 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?
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
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
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).
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.
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.
> 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.
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.
It is technically trivial to make a forwarding email address that works once and only once.
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.
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)
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/
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.
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.
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".
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'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.
@themafia Adding to your nice suggestions:
My addition:- Include retry logic: Add a "retry_policy" field (e.g., exponential backoff) for failed callbacks
│
└── Dey well; Be well
This almost seems like a web-i-fied 'reminder' system - and I've found one-and-done memory-aid-type reminders to be the area least addressed in current systems.
I think this can be easily implemented with the Distill Web Monitor browser extension [1]. Just monitor the post listing page, set a CSS selector for the post titles, and add a text condition (e.g., "Awesome Blog Post Series").
From there, you can choose how often it checks and how you want to be notified (e.g., browser notification, email, etc.).
You can run it for free on your browser or pay for the cloud version.
[1] https://distill.io
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.
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
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'
RSS for lazy people who can’t bother filtering their RSS reader is probably a very promising concept.
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.
I agree, your brain has already moved on.
"Practice makes perfect" was such a silly idea, after all.
WebSub[1] has been a standard for real-time notification of changes for at least a decade.
[1] https://en.wikipedia.org/wiki/WebSub
I followed up with this:
"The Missing Service: Notify One Time" https://news.ycombinator.com/item?id=44890642
Filtered RSS with some automation (ie: to delete the subscription) will do this for you.
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.
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.
Seems a bit like webhooks?
https://en.wikipedia.org/wiki/Webhook
Although your model is polling rather than making the other server push something.
Webhooks are not relevant to this use case.
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 ?
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.
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.
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
"Would you like to receive notifications from this website?"
No, thank you.
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
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
> 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
https://visualping.io is exactly that agent... give it a url, a description of what change is important to you, and how frequent should it check...
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.
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.
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?
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.
> 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.
They want a one-time feed. The browser or agent can unsubscribe from that single event feed when that thing happens.
You want an RSS feed filtered to only the events you are looking for
Isn't this just RSS?
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, ...).
Then it's not a missing protocol. The protocol is RSS. They want some specific app that is doing a thing with RSS.
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.
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.
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.
No.
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.
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.
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.
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. ;)
couldn't he use google alerts ? I've used google alerts to alert me about events