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.
> 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?
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)
Readit News
You know which one.
This is the tricky bit thou and will come down to chicken and egg problem of adopting some convention
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
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.
Deleted Comment
> 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?
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.
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.
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.
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.
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)