Many of the questions about RSS.chat center on how do we make this centralized. I don’t want this, I want feed readers to add some features and then we can connect these systems together in a million different ways. They just have to think differently about subscription lists. Not radically different, even. #
New docs for the browser JavaScript interface to the RSS.chat API. #
Wanted to switch but nothing I tried is as great a driving experience the Model Y is. Instead I’ve had a lot of fender benders and haven’t gotten any of them fixed.
I don’t know if it accomplishes anything but to me it feels like retribution of a sort.
It’s what we used to call a coral reef. A deliberate attempt to get people to do more than it does. To think about the web the way it was meant to be thought of, as small pieces loosely joined, with the emphasis on small. If you have formats and protocols that connect the pieces, you can make anything you want out of the pieces. If we don’t try to capture our users, instead we try to serve them.
This all sounds nice in theory, I imagine, but — there’s a practical side to it. I wrote about this in a comment in a thread on rss.chat repo. The key point is this, you can do what you want with the data. And if you want to build new data that includes this stuff, go right ahead. RSS is extensible. It’s all about working together in a web of people, because you can’t have a web of pages if the developers aren’t web’d.