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 7 days ago | parent | next [-]

Isn't this what RSS is for though?

▲

kmoser 7 days ago | parent | next [-]

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 7 days ago | parent | prev | next [-]

It could be implemented as some type of extension to RSS.

▲

cxr 7 days ago | parent [-]

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 7 days ago | parent [-]

100% this. Per-topic RSS feeds solves this perfectly.

▲

waterproof 7 days ago | parent [-]

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 7 days ago \| parent [-]
		"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?

▲

baruz 7 days ago | parent | prev [-]

https://xkcd.com/927/

You know which one.

▲

jjmarr 7 days ago | parent [-]

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 7 days ago \| parent [-]
		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.

▲

zaphirplane 7 days ago | parent | prev | next [-]

> 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 7 days ago | parent | next [-]

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

	▲	zaphirplane 7 days ago \| parent \| next [-]
		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
	▲	losvedir 7 days ago \| parent \| prev [-]
		Ah yeah, simple manual methods are tight.

▲

dragonwriter 7 days ago | parent | prev [-]

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

▲

oneeyedpigeon 7 days ago | parent | prev | next [-]

Exactly—you could also have a <link rel=next in the part 2 document with that URL.

▲

7 days ago | parent | prev | next [-]

[deleted]

▲

themafia 7 days ago | parent | prev [-]

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 7 days ago | parent [-]

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 6 days ago \| parent [-]
		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.