No, thank you.
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.
> 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?
Also a nice blog in general, I subscribed with RSS. ;)
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.
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.
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.
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)
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.
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).
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.
- 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
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.
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.
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.
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.
I think the proposed anonymity and ephemerality could provided by that approach if there is enough interest.
- "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.
kmoser•14h ago
SirFatty•14h ago
baruz•14h ago
You know which one.
jjmarr•12h ago
Ditto for power adapters. Every laptop now uses USB-C instead of weird barrel plugs.
eqvinox•10h ago
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•14h ago
0x696C6961•13h ago
cxr•11h ago
This is not (really) a technical problem. It's a cultural one—getting people to actually make hyperspecific micro feeds available.
akoboldfrying•10h ago
waterproof•8h ago
akoboldfrying•4h ago
zaphirplane•12h ago
This is the tricky bit thou and will come down to chicken and egg problem of adopting some convention
01HNNWZ0MV43FF•12h ago
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•8h ago
dragonwriter•9h ago
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•8h ago