Basically linkblogging. I'm not sure this needs to be a separate feed; JSON Feed has a dedicated `external_url` field:
> If `url` [optional] links to where you’re talking about a thing, then `external_url` links to the thing you’re talking about.
I'd be shocked if Atom/RSS didn't have equivalents.
This kind of "repost"-ish behavior may just be obscured in the tools people use to construct feeds, so they remain obscure features of the standards. The designers had syndication in mind, very much like what you're describing — ingesting feeds, reprocessing/mixing/extending them, and exposing the result as another feed.
Using RSS for this seems reasonable for people who already have the ability to host a feed. I was thinking more about the Twitter-alikes for the "normies" who don't have a place to host a feed. I don't just want to see recommendations from bloggers. I'd like to be able to pull recommendations from a wider net of "content consumers" as well as "content creators".
I can't come up with an economic model that would work to run a hosting service for feedreader-generated feeds except in the case of for-profit feedreaders. There's abhorrent models there like, say, peppering the recommendation feeds with "sponsored content", or extracting demographic data from the participants and selling it. Making the recommendation feed a fee-based service also seems like a bad model, too.
That was why I look at the Twitter-alikes for the recommendation feeds-- because the transport is "free" (or, at least, not something where I'd have to worry about the business model).
The RSS spec has the 'source' sub-element, which should point to the original source feed to give credit while forwarding/reposting. I guess one can apply this spec loosely and point it to a webpage url instead of an RSS feed.
After about a decade of experimentation (NetNewsWire, Feedbin, Miniflux...), I'm self-hosting a feed reader I wrote myself, running on a free hosted LibSQL db.
- NetNewsWire was slick, but wouldn't work on my phone.
- Feedbin was excellent, but eventually I decided to do some subscription cost-cutting.
- Miniflux worked fine, but 1) I found it a pain to set up with remote hosted Postgres and 2) it burned through the Neon free-tier usage limits in a couple days.
So I built one myself and run it on a Raspberry Pi home server.
Made a great little weekend project. The feed standards are known quantities, so a little AI assistance with boilerplate goes a long way.
Deciding you need a new feature and just adding it is refreshing — e.g. I wanted a "read it later" feature like Feedbin's (something missing from Miniflux), and now I have it.
> An RTO mandate is also an excellent thing for a CEO to show investors they are doing, if they are not making money and lack better ideas.
I think of Jeffrey Pfeffer's "social contagion" arguments a lot — first with regards to layoffs[^1], but increasingly also to RTO policies and tracked AI use.
It seems very unlikely execs (esp. in small organizations) are taking the time to read and seriously evaluate research about RTO or AI and productivity. (Frankly, it seems much less likely than them doing serious modeling about layoffs.) At some point, the "contagion" becomes a matter of "best practices" — not just a way to show investors what you're doing, but part of the normal behavior shareholders expect.
And for each CEO, those shareholders are mostly the same people.
It's easy to get sucked into thinking this is just the way the world works but really we've just enshrined a local and temporal phenomenon. Layoffs aren't a physical law. There are places and times where this would not happen.
Let me put my investor hat on: hiring at the top and firing at the bottom is a predictable inefficiency and represents a CEO failing at their responsibilities. You don't get to be a CEO and claim ignorance of market cycles.
Just how software engineers are in the hacker news thought bubble you have the VC and CEO thought bubble. It roughly goes like this: Someone has some productivity or whatever problem and RTOs. That costs money, they lose people, so they can’t later admit it was a wash or a net negative. So they go on Twitter or LinkedIn and trumpet how great their hardcore 996 RTO is going. Now others see this and fomo kicks in. They start their own RTO which they are then again highly incentivized to report as successful. Rinse and repeat.
A practical guide for integrating a custom linter into your Go project, a [light] screed against golangci-lint, and a defense of a simpler Go metalinter I’m experimenting with: glint.
It's a good post, super clearly explained. I have to admit it makes me a little nervous about the future of Go packages — of course interfaces aren't intrinsically bad, but omitting them in early versions of the language discouraged reflection and walled out a good deal of this complexity (in exchange for verbosity).
I wind up feeling grateful for simple interfaces, especially the ones disseminated in the standard library.
Strongly statically typed languages let you safely refactor in ways that would otherwise be risky. This is my trick for one very common example: lifting an interface out of a concrete type.
This seems like an upstream concern with distribution, no?
Nothing in this announcement indicates YouTube Music will attempt to control distribution. YouTube might give exclusive content a try (a la Spotify), but — to your point — that won't be a "podcast" in the strict client-agnostic-syndication sense.
As long as podcast creators are publishing mp3s to RSS/Atom feeds, YouTube Music is just another podcast client (like Google Podcasts was) which you're free to avoid.
> YouTube Music is just another podcast client (like Google Podcasts was) which you're free to avoid.
My partner uses Google Podcasts because it was preinstalled. The vast majority of folks don't know that they have a choice, let alone that they should find/choose an app. Hell, that's really the only reason Apple Podcasts has any traction: it came preinstalled.
"Normal" people don't know what an RSS feed is, they don't care, and they don't want to learn. They just want to listen to podcasts.
I don't understand how this pertains to my comment. Nobody's arguing whether listeners will, as a matter of preference, avoid Google/Apple/Spotify podcast clients. Nobody makes a claim about how many people know of RSS.
It's up to the podcast producers to decide for/against distributor-exclusivity, determining whether OC has to use YouTube Music.
> The vast majority of folks don't know that they have a choice, let alone that they should find/choose an app.
That's... fine. What matters is whether they do have a choice if they go looking for one — again, that's up to podcasters, not up to Google.
The websites for podcasts often seen to hide the RSS feed/mp3 files while having giant buttons all over the place for Apple podcasts and spotify. They feed their listeners to those platforms on a platter.
Yes, but if you search for the podcast by name with your favorite podcast app, it will be found. Unless it is a fake podcast (like a Spotify exclusive).
Agreed, but I suspect that a lot of them who already use Google Podcasts won't be thrilled to have to switch to YouTube Music and may be looking around for choices when the date of cancellation gets closer.
In one respect this consolidation makes more sense than the Play Music → YouTube Music switch: many podcasts cross-post episodes as YouTube videos and audio-only feeds.
If YouTube collates those feeds and lets users select between modes while maintaining a unified "already watched/listened" list... hey, that reflects how podcasts distribute/monetize in practice.
The YouTube Music app was a dismal replacement for Google Music, and never regained features for managing one's own library of uploads. Of course, that's not a problem for podcasts; episodes are already syndicated.
