Earlier quoted context omitted.
For those who want to try it, movim.eu is a federated social network build on this XMPP extension.
Do you know if there is a name for that XMPP/Atom pubsub service, and if web publishers can put up some kind of icon so people know they can subscribe to that kind of a feed?
RSS is back as an underpinning to SlackOps
121–130 of 135 posts
Re: RSS is back as an underpinning to SlackOps
#122RSS has been alive this whole time. Blogs usually have it by default, the big news organizations have it. The only thing I'm not satisfied with reading news on RSS, is that news organizations push too many articles, to the point that reading the headlines alone takes quite some time. There's nearly 100 articles per day per source sometimes. Unlike a newspaper, which has a natural structure of priority and hierarchy,…
We need to get back to a world where we’d have daily or weekly issues of news that we all read so that we can’t point at the same thing and say, “that’s right” or “that’s wrong”.
Re: RSS is back as an underpinning to SlackOps
#123Earlier quoted context omitted.
What exactly is Sourcehut doing?
The same thing GitHub is doing: throwing a bunch of source files into a repo—i.e. the sort of thing that came before wikis (and the reason why wikis were invented in the first place—to displace those kinds of systems)—but then calling that a wiki. It qualifies certainly as what GNU calls a "Massive Multiauthor Collaboration Site". But to call it a "wiki" is wildly inappropriate—like saying "integral" when you're talk…
Re: RSS is back as an underpinning to SlackOps
#124It... wasn't ideal though, in hindsight we should've hacked together a UI so that the people sending the message could confirm the message and see how many people would be receiving it first. There have been a few Incidents of accidental test messages sent out. One was my fault, early on, because production and test were the same machine. The other was the operators' fault, but by then the app had two million installations and it caused a bit of a social media storm that day (#hajo).
It was funny to see that one play out, and how quickly there are print companies making and advertising merchandise about whatever is trending on twitter that day.
Re: RSS is back as an underpinning to SlackOps
#125RSS has been alive this whole time. Blogs usually have it by default, the big news organizations have it. The only thing I'm not satisfied with reading news on RSS, is that news organizations push too many articles, to the point that reading the headlines alone takes quite some time. There's nearly 100 articles per day per source sometimes. Unlike a newspaper, which has a natural structure of priority and hierarchy,…
newsboat supports regex filters and macros/outside scripts which can be powerful
Re: RSS is back as an underpinning to SlackOps
#126That reminds me of a project we did years ago for a large Dutch public transit company. We built an app with push notifications, and sometimes they needed to do big announcements to all users. We made our push notification back-end poll an RSS feed from their CMS every minute or so, if there was a new one on there it would get broadcast to all users. It... wasn't ideal though, in hindsight we should've hacked togethe…
Re: RSS is back as an underpinning to SlackOps
#127All I see is people claiming RSS is dead, but I never stopped. Moving between various readers and landed on Feedly for iOS a few years ago. Love it.
One thing that's been corrosive to rss the past couple years have been podcast platforms. I find more podcasts (free ones) that can only be accessed through platforms like Google podcasts, Stitcher, Spotify, or Anchor, with no rss feed link to use in a platform agnostic podcatcher app.
I migrated my podcasts to GNOME Podcasts app by selecting the RSS link manually from Google Podcasts app when I switched to a Linux phone.
Re: RSS is back as an underpinning to SlackOps
#128Earlier quoted context omitted.
The same thing GitHub is doing: throwing a bunch of source files into a repo—i.e. the sort of thing that came before wikis (and the reason why wikis were invented in the first place—to displace those kinds of systems)—but then calling that a wiki. It qualifies certainly as what GNU calls a "Massive Multiauthor Collaboration Site". But to call it a "wiki" is wildly inappropriate—like saying "integral" when you're talk…
Whats missing from GitHub/SourceHut "wikis" that would make them actual wikis? At least with GitHub wikis you can edit them from the web like the wikis that came before GitHub.
Many of these new-gen collaboration sites that bill themselves as having wikis result in a request for approval (pull request) instead of an actual edit when you attempt to make a change. (And in the Git-backed ones, the process is usually more egregious; see below.) This proposal/review/approval cycle is exactly what a wiki isn't. GitHub no longer imposes this workflow—there's now an option at least to turn your wiki into, you know, an actual wiki—but even today that option remains off by default so all pages are closed to changes unless the owner makes an effort to toggle the right setting[1]. What these are aren't wikis—they're anti-wikis; if you have a "wiki" that only you can edit, then stop calling it a wiki. (Notably, GitHub's setting doesn't control whether it will continue to advertise it as a wiki or not—instead of just, like, the "docs" tab or something.) Most of these are static sites with extra/fewer steps.
SourceHut is even worse than present-day GitHub, because for all its docs in the man.sr.ht namespace, this is the process you have to use to edit one of its anti-wikis: spot the typo, note the title of the page you're currently on, find the corresponding repo URL in the page footer, leave your browser to clone the repo to your machine, open that directory and locate the source file based on the page title you noted earlier, edit it, make a commit, and then (probably**) push your changes to the original repo. This flies in the face of the definition[2], etymology[3], and entire spirit of the word[4][5].
* Maybe you hit a wall because the specific page has been locked. Fine. Raise your concerns through linked resource for discussions. The fact that individual pages can be locked because e.g. they have a history of being the target of abuse does not negate the meaning of "wiki". If every page is locked down (including pages that don't even exist yet, so you can't go create them), then that makes a material difference—it makes it not a wiki.
** It may not actually be the case that trying to push your changes makes them immediately live on SourceHut—it very well may result in a request for approval by the project owner. No idea. I've never gone through the process on Sourcehut because of how much contempt is deserved by projects that have contributed to the campaign of debasing the term "wiki" to it-means-what-we-feel-like and who-are-you-to-say-that's-wrong levels of uselessness.
1. https://docs.github.com/en/communities/documenting-your-proj...>
2. https://en.wiktionary.org/wiki/wiki#English>
3. https://en.wiktionary.org/wiki/wikiwiki#Hawaiian>
4. https://www.mediawiki.org/wiki/wiki>
5. https://meta.wikimedia.org/wiki/The_wiki_way>
Re: RSS is back as an underpinning to SlackOps
#129All I see is people claiming RSS is dead, but I never stopped. Moving between various readers and landed on Feedly for iOS a few years ago. Love it.
I dropped Feedly because I found that 90%+ of my feeds would only put the article title and the first sentence into the feed, then require I click the URL to pull up the full article. It wasn't very fun constantly having to switch between my RSS app and my browser, so I just stopped using it.
Re: RSS is back as an underpinning to SlackOps
#130It wasn't long before people discovered that and began using our service to deliver relevant stories to their Slack teams and stakeholders. As the author says, RSS is the closest thing to an open MVP-style API that "just works," and hasn't been plagued by a company's closed garden rules.
I am wondering, what else could one use RSS for.
Long live RSS!