The Missing Protocol: Let Me Know
deanebarker.net
deanebarker.net
You know which one.
Ditto for power adapters. Every laptop now uses USB-C instead of weird barrel plugs.
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 not (really) a technical problem. It's a cultural one—getting people to actually make hyperspecific micro feeds available.
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
Anyways the convention isn’t too hard it’s the adoption by authors and software that will be tricky
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.
"Technically possible" and "likely to work well" are two different things.
> 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.
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.
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.
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)
It was conceived for social networking, but social networking doesn't have to be just 140 characters in a timeline.
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.
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 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.
"expected" in place of "delay"
"modified" in place of "when"
- Include retry logic: Add a "retry_policy" field (e.g., exponential backoff) for failed callbacks
│
└── Dey well; Be well
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 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.
"Practice makes perfect" was such a silly idea, after all.
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.
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.
https://en.wikipedia.org/wiki/Webhook
Although your model is polling rather than making the other server push something.
Doing it your way would be completely unworkable.
Except this idea is automated, and wouldn't need to load the entire website.
"The Missing Service: Notify One Time" https://news.ycombinator.com/item?id=44890642
No, thank you.
- 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
You can use something like ntfy.sh, where you create a channel on a public relay and do pub/sub
Hard truths. Reinforces this authors reasons for a edging for a solution.
│
└── Dey well; Be well
- "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 the proposed anonymity and ephemerality could provided by that approach if there is enough interest.
What kind of magic was expected? Technology isn't clairvoyant (yet) so pubsub or callbacks is the expected advice.
Whether that is a protocol or an application running over a protocol is semantics, either interpretation is valid.
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.
Also a nice blog in general, I subscribed with RSS. ;)
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.