This is a really good idea, but to the point of not needing a different apps to read all the different social media sources, (and I might have missed the answers to these in the post), could the problem of participating in the communities be solved through one app too? How reading of different type of content should be handled,as some posts are just media, some are comments? Could there be something like "rss+social" spec?
> could the problem of participating in the communities be solved through one app too?
My thinking is that it's a good-enough solution to leave writing comments etc. to the separate community apps. Most of the benefit the "one app" thing IMO is to provide a single feed to check--I want to have a habit of checking only one place when I have a few spare minutes to read something. While it would be kind of nice to also be able to leave comments and such without leaving that app, it's not too difficult to click on the post and leave a comment via another app. So I'd leave that kind of thing off of this list since I don't consider it to be essential. But it could still be worth experimenting with after the essentials are in place!
Another aspect to this is that protocols and interoperability have a downside since they require more coordination between different parties and can thus slow down development of new kinds of features. I think it's important to find the right amount of interop. There needs to be enough interop so that people can build new apps without having to fight against (the lack of) network effects, but not so much interop that people are unable to experiment independently with new kinds of features.
That's a long-winded way of saying I think it's actually better to not worry about making community interaction happen over a protocol, because it gives community app developers more freedom to experiment.
> How reading of different type of content should be handled,as some posts are just media, some are comments?
It may be helpful if community apps include various metadata in the feeds they provide, so reader apps can distinguish different types of posts (e.g. perhaps include a "in reply to" field for replies). When possible, reader apps can also try to infer things about the posts, similar to my suggestion of inferring if a feed is a "social feed" or a "regular feed" by looking at the frequency (and probably also the length) of posts.
> > How reading of different type of content should be handled,as some posts are just media, some are comments?
> It may be helpful if community apps include various metadata in the feeds they provide, so reader apps can distinguish different types of posts (e.g. perhaps include a "in reply to" field for replies).
Fun Fact: The Activity Streams JSON-LD Vocabulary, which is used in ActivityPub, started, a long time ago, as a metadata extension for Atom (and RSS) feeds.
Additional Atom back in 2005 provided a minimal mechanism for copying feed items from one feed into a new feed – the "social feed" in your proposal – by specifying an element which references the original source feed.
Over the years people have put a lot of time and thought into distributed social media APIs and related specs and are still doing it. Current efforts like ActivityPub and the Indiewebcamp stuff are a direct descendant of some of these specs.
(If I were you, my first thought would be to simply read, what has happened in the last 20 years. At the very least it can never hurt to know, what other people found worth doing.)
Yep, I'd certainly recommend not adding new metadata extensions without first checking for existing ones that would suffice.
I'm interested if you have any reading recommendations? Indie Microblogging[1] is on my reading list. My impression so far of existing protocol-based social media efforts is that they're not really going in the same direction I'd like to go myself, but of course you're right that it doesn't hurt to have more background knowledge.
Both the Indiewebcamp wiki and Wikipedia often have pages on now defunct protocols and services. That is of course not a perfect approach but it gives one entry points.
I think RSS needs fixing first before building anything on top of it. At the risk of that xkcd meme about 15 competing standards, RSS + images is a total mess. Every reader supports different ways of rendering images. Sometimes it's inline HTML, sometimes it's the RSS <enclosure> element, sometimes its something entirely else.
Some readers either support <enclosure> or instead load inexplicably tiny/blown up/stretched/pixelated images, or just don't display any images at all.
Consider that podcasts use RSS - yet need a special namespace "itunes" in order to work:
This is one reason why it's important to not try to do too much over RSS. The question isn't "can we re-implement every social media feature using RSS," it's "what is the minimum amount of interop we need in order to for an ecosystem without gatekeepers to flourish," which hopefully will make things bearable.
Besides that, I also think this problem can be ameliorated to some extent by using and developing open-source feed parsing libs like Python's feedparser rather than using a plain XML parser and doing the rest yourself.
Having had to work with importing RSS feeds. I absolutely despise the tech. The sources generating RSS have almost no consistency on how things are done and the actual spec itself doesn't show much opinion on which of the 5 ways to do things is the preferred one. That's before you get in to the mess of invalid RSS and then invalid XML which is extremely common.
One of the problems is the spec tries to do everything. You have blogs, podcasts, random crap, and now social media all trying to cram in to the same spec. Ideally you want one spec per use case. With modern tech it's very easy to create a new JSON spec which is trivial to parse and serialize. And you can auto generate extremely accurate documentation.
I don't think we really need "another rss" which would just be fragmentation. We just do not need to be using RSS for social media just because you can.
Basically it's because decentralization has downsides, and I think the optimal amount of decentralization is less than what e.g. Mastodon/ActivityPub provide. See also my other comment: https://news.ycombinator.com/item?id=33976289
Why not ActivityStreams instead of RSS? It would have free and seamless interop with ActivityPub, with the only difference being a "pull" model as opposed to the "push" inherent in ActivityPub.
Anyone can host an RSS feed with just a web server. Everything from a shared host to a VPS to a Raspberry Pi at Home. It takes a lot more resources and administration effort to run an ActivityPub server.
That's true of current implementations, but the spec is flexible enough to allow much simpler ones. You can have an outbox which is a collection of activities (that could even be statically generated) and software could poll the outbox just like RSS. Existing software requires a push-based model, which means handling follows, which means a database, but fundamentally there's nothing stopping ActivityPub from being pull-based.
Maybe that'd work too! I'm honestly not very familiar with ActivityStreams. My main concern is figuring out a lowest common denominator/the simplest thing that works, and I think RSS is sufficient. I'll have to do some more reading + thinking on ActivityStreams.
Nice to see a different application of the same concept I'm pursuing with Hey Homepage. I chose to have the feed creator and feed reader in one-and-the-same app. Just like with Facebook or Twitter, where you can read and post in the same interface. It's combined with a microblog/timeline, that can just as easily be viewed by regular people in the browser who've never heard of RSS. Openness and accessibility are key, no walled gardens. My website system also publishes an OPML file and an accompanying list of recommended other websites (just like a blogroll or webring).
I subscribed to your feed and wish you luck with your nice projects! I did miss an RSS icon on your site, however. ;)
This is cool! Other People's Meaningful Links is great :). I've subscribed to your feed as well.
I actually haven't worried about the RSS icon on my site since I figure people who use a feed reader can just copy and paste the site URL and the reader app will auto-detect the feed, and people who don't use a feed reader can just subscribe with email. Maybe it'd still be helpful to link explicitly to the RSS feed I suppose, perhaps underneath the email subscribe box?
Thanks! Indeed, I auto-detected your feed with my system and you're right about the people who know about RSS will find it, but I catch myself looking for an icon first. It also signals that RSS is still alive.
I think somewhere close to the email subscribe box will do the job. I even check the footer a lot, or the blog section of pages.
> My main idea here is that every reading app should let you create shareable links where people can subscribe to an RSS feed and sign up for the reading app at the same time. If I want to invite people to join my community or subscribe to my social feed, I give them one of these shareable links.
This is close to the way podcasts work now, and it kind of sucks. I was just looking at a show on the Apple Podcasts site (because it was the first result that showed up in the search results), and it has social media sharing buttons for Facebook and Twitter and an icon to copy some markup to embed an iframe-based player. If you are not Facebook or Twitter or looking to embed an iframe, too bad. The reverse sucks as well: when I'm on the site of the podcast itself, and it gives me a bunch of options to subscribe using Apple Podcasts or Google Podcasts or watch on YouTube. If you use something else to consume podcasts, your best bet is to copy the link to the bare RSS feed and put that in. Problem is, some sites omit that one.
This is one thing that the fediverse is getting right, in comparison. If I use Mastodon and want to touch someone's post (i.e. react to it—by replying, starring it, or whatever), then I can trivially refer to that post with its URL. If I copy the link from my browser toolbar and then paste it into Mastodon, it works. (This isn't amazing. The workflows around it could use some polishing up, but the fact that it is at minimum possible is awesome.) For comparison, when I copied the Apple Podcasts show page URL and pasted it into the Google Podcasts search bar, it returns a message: "No podcasts found".
I think this is the same thing I was trying to address with this paragraph at the end:
> Another suggestion: provide browser extensions and iOS/Android sharing menu items so that it's easy to open an web page in the reading app. If there's one or more RSS feeds detected, throw in a subscribe button with checkboxes for each feed. The "shareable subscribe links" should include a link to the original RSS feed in the page metadata. Then if I click on the subscribe link but want to subscribe with a different RSS reader, I can do so easily.
i.e. we should be sure to provide smooth user experiences both for people who don't yet use a feed reader and for people who do. Agreed that Mastodon does this nicely, and I think adding in some browser extensions/mobile apps would help to automate things a bit more.
Suppose someone registered a vendor-neutral, collectively owned* domain `feedme.example`. A static site would be hosted there. Instead of everyone being compelled to do one-off integrations with the most popular commercial services, they would instead link to their own feed e.g. as <https://feedme.example/#!/https://meta.discourse.org/posts.r...>. The user's preferred reading app would be accessible in client-side storage for the feedme.example origin, and when the user actually lands on <https://feedme.example/#!/https://meta.discourse.org/posts.r...>, it redirects to the appropriate service, assuming the user has already set it up. If they haven't, the feedme.example SPA prompts them to set it up. Client software will be free to hardcode support for this well-known name and provide native equivalence to the purpose that the softcoded feedme.example serves. A sort of lame re-invention of Web Intents; alternatively, basically the same as registering a new URI scheme with IANA, except there's a web-based fallback.
* or collectively managed, at least; in the vein of w3id.org, for example
Good read! Aligns a lot with everything happening with the IndieWeb community[1] (including social readers[2]) and what I'm working on with Haven[3]. The additional piece (I know, more parts make everything harder for everyone) is using these tools for _private_ sharing. That's been my focus--publishing RSS with http basic auth for access control--while keeping subscribing as simple as copy/pasting a URL or using a browser extension that recognizes RSS auto-discovery[4].
Thanks--and I'm glad to hear you're working on access control. My current approach to that hairball has been basically to work on everything else first and think about it later. Maybe it's not actually a hairball, but the fear of it being one has been enough to keep me from thinking about it.
Very nice--I like all the "Follow in" links. The one for Feedly in particular is pretty much what I'm envisioning, since it shows a page for the feed itself even if you're not signed into Feedly, instead of just redirecting to the landing page/sign-in page like the other ones do.
Currently making my own social network from scratch and it's more media-based than text-based, but I love the idea of RSS feeds for everything. My only concern would be extra bandwidth requirements if there's a ton of readers out there constantly fetching updates.
It's better than someone F5-ing a page and redownloading all the assets, but feed readers check automatically on a (usually short) timer, so it's not really comparable.
Does YouTube still offer RSS feeds? I remember those being extremely useful when they swtiched from reverse-chronological to the recommendation-driven Home feed.
Youtube does still have feeds. The bandwidth can be reduced if readers use the If-None-Match and If-Modified-Since headers when requesting feeds (so if the feed hasn't been updated, the server can return an empty response). I also imagine that as feed readers become more mainstream, you'd start to see more intermediaries for fetching feeds like Superfeedr[1].
What would be the benefit of this, really? Easier consumption, I suppose, but RSS is a read-only protocol, and allows no participation. Users would still depend on centralized services to publish content, and there's little to no chance that these companies would interoperate using a standard protocol. Not only that, but why would a centralized service that depends on ads and promoted content allow you to use an open format to consume it? They _want_ to keep you on their platform as long as possible.
What decentralized protocols try to solve, and what the centralized web has failed us with, is data ownership. Users should have full control over the data they produce, and be free to migrate it to any other node without losing access to the service they're interested in.
Mind you, I don't think social media is worth reinventing. Connecting everyone on the planet is wrong on a societal level. But P2P services are a good fit for building smaller communities, which is a crucial missing component of the design of the WWW. I'm still hopeful that something built for the masses can take over the current mess we're in.
Easier consumption is pretty much it, yes. Specifically, it'd make it easier to stay engaged with publishers and communities even if they aren't part of a centralized platform, which means that people who develop publishing and community apps will have an easier time growing their user base.
> Users would still depend on centralized services to publish content, and there's little to no chance that these companies would interoperate using a standard protocol.
All you need is a blog/newsletter platform like substack, ghost, wordpress etc. They may not aggregate your social posts into another feed for you, but you can use a separate service to generate and host the feed, then link to it from your main site.
> Users should have full control over the data they produce, and be free to migrate it to any other node without losing access to the service they're interested in.
I’ve always thought a social api built on email as the transport and mailing lists for organization would be ideal. The infrastructure is there and scales.
I mentioned in another post I added the ability to comment on my items from RSS feeds with Mastodon accounts recently. Sure, it's not part of the protocol, but it does the job without any fuss and people who want to interact with me (the majority of them are on Mastodon, I guess this is the key point) in the context of certain RSS feed items can do so very easily.
Do you support web mentions as well? That was the first attempt at adding social to RSS, ActivityPub is very similar with an angle to federation instead of self hosting
Honestly I don't know much about web mentions. It would be very cool however, if when I add a HN/Reddit/Twitter/Mastodon comment by somebody to a curated feed, that that person could be notified by a web mention. From my limited understanding, though, I think this would require web mentions to be implemented wherever the comment/highlight originated from?
I like to think that I'm pretty technically competent, but I really struggle to understand a lot of the standards/protocols that the fediverse/indieweb is built on...
Well you're wrong that it doesn't allow participation. It just separates read from write. Participation can be in the form of additional feeds. It can be in the form of a feed remixer (moderation or aggregation).
Shout out to the h-feed / h-entry microformat https://microformats.org/wiki/h-feed, sadly underutilized but an extremely easy way to make the web much more syndicable.
They're comprised of standardized CSS class names to be inserted into HTML and enable meaningful scraping. Especially given that more and more sites are produced using JS frameworks, which have a harder time producing XML than older generation PHP and the like, h-feed seems a no-brainer.
I'd say that you are the perfect user for my new RSS reader/tracker https://lenns.io/. What is more, you assign priorities to both subscriptions and categories so that you can have the ones you care the most always at the top.
I don't read in my RSS reader. It's browser isn't as good and doesn't support adblockers or other add-ons. I read in my regular web browser with uBlock Origin and all my other add-ons.
I've made quite a few comments before on HN about how I have come to use RSS feeds- essentially as a way to distribute highlights rather than distributing entire articles or previews of entire articles with a meaningless blurb in the feed item body.
I curate RSS feeds on specific topics[1] and populate them with highlights from what I'm reading from across the internet- this can be a literal highlight from an article, a comment on HN, Reddit etc., a Kindle highlight from a book, anything really, as long as it is on-topic.
There is always a link back to the original context for subscribers to dig in deeper if they want to.
I think this is a real sweet spot. I cannot go back to feeds of anything and everything, a hodge-podge mixture of bad one-paragraph summaries or overwhelmingly long RSS item bodies.
I want to know what exactly grabbed somebody's attention that made them think that something was worth sharing, what gripped them about it, and if it also grips me, I'll gladly go to the original context and read further to my heart's content.
But I don't want a never ending queue of things that I have to put an outsized amount of effort into filtering through to even answer the question "is this something that interests me?"
With the explosion of Mastodon I also added the ability for my RSS subscribers to comment on RSS items from my feed using their Mastodon accounts. So far, so good!
I have used Diigo for a long time in a similar way - bookmarks are useless, and I only remember the sentences in the links I’m after, not the url, plus tagging them.
This seems like a much cleaner setup and can feed into indieweb as well.
Thanks for sharing, I wouldn’t have gone looking for this.
If somebody from Diigo is reading this: Why is there no content on the frontpage? It's a sleeping social network that could generate many more subscriptions.
The Share section could offer a feed of all content that users are willing to share publicly. There could be support for ActivityPub to make it a worthwhile investment of time.
It should be a better sales channel to get new users hooked on good content first instead of forcing them to commit to a new account before trying anything.
In addition to improving usability, it defeats attempts to measure clickbait summary efficacy, etc., since it breaks sites' ability to pull popularity / telemetry info.
I prefer the substack model personally: full article with a link to the substack at the top and bottom. I feel a bit yanked around otherwise, speaking for myself anyway
>I also added the ability for my RSS subscribers to comment on RSS items from my feed using their Mastodon accounts
How does it work? Looking at a feed.rss file, I don't see any links to Mastodon posts.
>I curate RSS feeds on specific topics
>I think this is a real sweet spot. I cannot go back to feeds of anything and everything, a hodge-podge mixture of bad one-paragraph summaries or overwhelmingly long RSS item bodies.
It is the sweet spot when it comes to consuming your feed on its own.
In the context of other feeds, and you may have resolved it with Mastodon feedback, it still takes some time to find the best links in your feed. That's a quality on its own, so please don't feel pressured for change. However, these points would make it sweeter for me:
* Showing the most popular highlights of the week, month and year, by user vote and by the popularity of the main article on social networks, as well as your personal favorites.
* Find like-minded collectors who have included the same highlight or for further drill-down, a set of highlights.
* It would also be interesting to see a note from you why you have selected a highlight, when that's appropriate. Further tags that could be used for sorting and ranking would also be nice.
It uses a "just in time" model to create a Mastodon post if it doesn't already exist when a user clicks on the "Comment" link (it also does a bunch of other stuff to handle truncation, fitting within the submission limits of the instance, making space for source links etc).
I think it's important to try and be a good citizen on Mastodon instances run by volunteers and minimize unnecessary load. The reality is that not everyone is going to want to comment on every single item in a feed, so in my mind there is no point trying to having a 1/1 parity between RSS items and Mastodon points.
Comments initiated by subscribers are posted on Mastodon with the "unlisted" visibility so they don't spam the public discoverability features in the instance timeline, but can be boosted by the curator at their discretion. The commenting user can also boost the highlight on their instance if they wish.
> It would also be interesting to see a note from you why you have selected a highlight, when that's appropriate.
I do this sometimes[1] - curators have an option to post a highlight directly to the public feed of their instance (ie. not unlisted), and then reply to that themselves with notes.
I think I'm a little overdue in writing a blog post about this new feature! Stay tuned for a submission on HN hopefully sometime in the next week!
I will wait for your post, but if you want to know what is still unclear to me:
>>for my RSS subscribers
>It uses a "just in time" model to create a Mastodon post
What is 'It'? notado.app for people who have logged in? There is no links to comments when not logged in. How can new users or people who don't want to create an account discover the comments?
>no point trying to having a 1/1 parity between RSS items and Mastodon points.
To me, the interesting part would be an n/1 relation: One comment section where everybody from all RSS streams can meet to discuss an article. Like HN/new, there is no incentive to comment on a 3 day old post because hardly anybody will read it. The economics change if the comment section can appear on various RSS streams because then, there can be readers and replies to a comment even years later.
Is it acceptable or even desirable to share your mastodon comment sections, or do you see them as a place for the people who follow you?
> How can new users or people who don't want to create an account discover the comments?
The links to initiate new comments on the public HTML versions of the feeds show only for people who are logged in, because unfortunately bots and scrapers are not as respectful as they should be.
As a user's feed homepage is designed to be shared publicly, it only takes one bad actor to click on every "Discuss on Mastodon" link for every item in all of a curator's feeds and put undue load on a Mastodon instance which makes the whole "just in time" approach moot.
Where Mastodon posts have already been created for discussion (by authed users, or by any users subscribed directly to the RSS versions of the feeds), those links (ie. to the Mastodon posts) get shown on the public HTML versions of the feeds.[1]
Otherwise, anyone who subscribes to the public RSS version of the feed (unauthed by default, doesn't require an account etc.) is presented with a "Discuss on Mastodon" link at the end of each RSS item on any feed for which the curator decides to enable comments, and this link can be used to initiate new comments/discussions with a Mastodon identity.
> One comment section where everybody from all RSS streams can meet to discuss an article
This isn't really something I'm interested in for Notado, but I wouldn't be surprised if someone sees your comment and runs with this idea!
> The economics change if the comment section can appear on various RSS streams because then, there can be readers and replies to a comment even years later.
It's not quite the same as what you're suggesting, but I am thinking of providing an API for https://kulli.sh where article authors can embed comments on their articles from across all supported platforms at the bottom of their articles. This could go a long way towards keeping discussions fresh regardless of the time that passes since the initial submission due to comments being embedded with the source.
I just need to really sit down and work out a pricing model (or maybe separate models for individuals vs organizations) for the whole thing.
> Is it acceptable or even desirable to share your mastodon comment sections, or do you see them as a place for the people who follow you?
I think this depends entirely on the curator. I personally don't have any issues with mine being shared more widely, but there are settings that I've made available to allow people to restrict comments to approved followers (on Mastodon).
The nice thing about the Mastodon API is that if you enable public comments, you can filter for your posts that have been created by the "Notado Feeds" OAuth app, and then filter again by posts that have >N replies, and then embed those discussions on your personal website (or anywhere else).
You definitely have thought this through. Is there a reason that you don't have a page with the posts with >N replies, or the posts with the most recent replies, available on the notado.app?
the problem with RSS is only one directional protocol also with no auth system. there's something like BlueSky's new ATP protocol that I think better to your case.
I don’t like self-promoting in comments but this feels incredibly coincidental. Just a few days ago I published an iOS app called Beluga which tries to reproduce a “Twitter-like” experience on top of JSON Feed (with some extensions) and RSS. The app does all the work on the device and uses an S3 compatible account to publish a feed and a statically generated mini-site.
But where do the ads go? How do publishers or authors (or content aggregators) monetize the content? The reason RSS is dead (unfortunately) and social media is very much alive is because of a pact between content aggregators, publishers, creators, and advertisers.
If we look to podcasts as a model — 490K new episodes in the last 90 days, delivered to users and to aggregators alike via "not dead yet" RSS — ads are placed inline with the content. There is no RSS-related "pact" that precludes the relationships you mentioned.
Yes--there's also plenty of money being spent on newsletter advertising. I make about $2k/month in revenue from that myself.[1] Publishers have lots of flexibility on how to monetize; you can do ads, or paid subscriptions, or a mix of both.... I'm planning to do paid subs + free with ads for Yakread.
I work in this space (podcast ads) and the podcast ads tech maturity is years behind other media, like video, due to RSS. This lag is also reflected in that advertisers generally spend less on podcasting.
RSS makes it very difficult to measure the performance of an ad. Most players in this space wrap a publishers hosted podcast link with their own tracking link, and the main metric of engagement is a download. Downloads themselves are a pretty crude measurement and don’t hold up to something like minutes watched/listened.
Placing ads into the audio directly also just isn’t as performant as streaming it into the media like in video. Publishers and advertisers want more fine grained control over where the ad is placed, when it’s placed, and how it’s consumed by the listener. Podcast ads currently don’t deliver on that.
> Publishers and advertisers want more fine grained control over where the ad is placed, when it’s placed, and how it’s consumed by the listener.
There you go.
Ad tech is behind when it comes to podcasts? Who fucking cares. Not the audience. Podcast advertising is the closest thing to traditional broadcast ads for TV and radio—when ads were still inert instead of sentient. There's not a damn person on this side of the divide that sees the things you mention as being a significant downside. Not having the self-awareness to realize it is pure déformation professionnelle; this entire comment reads like a burglar lamenting the fact that people keeping their money in the bank instead of at home under their mattresses makes it harder to break in and take it.
The podcasters care? Because if the advertisers can't quantify ROI and audience, then they're less likely to spend their money with you, and your potential revenue is capped.
You, like the previous commenter, are stating the obvious. What's mystifying is the general tone suggesting that what either of you are saying is supposed to be insightful.
I’ve been trying to think of an RSS driven daily newspaper.
I currently use Reeder. I source in my usual news sources and HN and twitter and some subreddits.
I’m working toward a place where I can setup a feed, a frequency, and a service to use both to make an “old timey” newsprint like PDF into my inbox (or an rss feed!) each day so I can still try for that “back when papers were good” feel.
I used to do this. A long time ago, I had a setup that would sync feeds from BBC, CNN, Janes [0], and a few other places; extract and sanitize [1] the text of the articles for the previous day; and ultimately prepare a nicely typeset, five column, landscape oriented PDF. It took some trial and error to get something usable, but the printed result was a pleasant way to stay informed.
That was many moons ago.
---
[0] Circa 2008, I could find several feeds from Janes that carried meaty non-subscriber extracts.
[1] LaTeX is picky about all sorts of "special" characters that are more common than one might expect.
In many cases, following the links in the item entries will get you full text. Just to get something going quickly, you can do a `links -dump <url>` to get just text and then cut it down with some bash-fu. That said, if you pull a lot from a given source, it's worth figuring out a reliable way of cracking out the title and text so you can format them sensibly.
Why not put RSS into something like Mastodon? Take the code of a project like TTRSS and merge it with Mastodon to allow people to subscribe to both activity pub and RSS feeds. They are both chronologically sorted. People could comment on RSS items which would simply turn into shares for their followers.
IMO it makes much more sense to do the opposite, and follow mastodon posts in the UX of a RSS reader.
I personally haven't been liking any content aggregation outside of RSS/reddit because I can't take the timeline model of unrelated things being streamed to my eyes without context. I tend to want to specialize what I read or otherwise I tend not to remember it or appreciate it as much (for instance I'd typically scan through news-like nodes during breaks and read art/science/in-depth feeds after work, but something that mixes both makes me uncomfortable).
But I do have a "people" node in my ttrss instance that aggregates from social network sources/blogs/shaarlis. Gives the best of both worlds, I think.
I know my Mastodon account has a RSS feed automatically. I am talking about following RSS feeds from within Mastodon. Then I don't need to have both an RSS reader and a Mastodon screen open. They are merged.
Consumers of content don't get to choose the system or protocol of the person they follow.
I want to see a good client that supports many different ways of following content: RSS, Atom, Twitter, Mastodon, nostr, youtube, whatever... with smart ways of dealing with different kinds of content (tweets versus blog posts versus videos).
Agreed, and this is actually my "top level" recommendation for anyone building apps in this space: if you make a reading app, make it read from anything; if you make a publishing app, make it readable anywhere; etc. Don't fixate on implementing a specific protocol. This is what I'm trying to do with Yakread.[1]
I see these RSS-related recommendations as the next step: what can an app developer do to reduce the effort it takes for others to interop with them?
ActivityPub was explicitly designed as a successor to OStatus, which was built on Atom and Pubsubhubbub (now websub), which was a successor technology to RSS (AP also integrated lots of fundamental design concepts from pump.io, which was an intermediate step between OStatus and AP). The RDF vocabulary it uses still has roots in the same RDF vocabulary used for OStatus (ActivityStreams 1).
Though it looks like ActivityPub is push, and RSS is pull. But one should be able to construct transformers between the formats of ActivityPub and RSS/Atom.
A related idea I have is to support subscription for OPML feeds. That way, instead of getting a private personal feed URL that merged hundreds of feeds that you follow on the server side, clients should support subscribing to an OPML feed, which can just be links to whatever you are following (games, posts, users, discussions etc).
The OPML feed changes, your RSS client picks up the changes and starts following the correct endpoints.
187 comments
[ 4.3 ms ] story [ 238 ms ] thread> could the problem of participating in the communities be solved through one app too?
My thinking is that it's a good-enough solution to leave writing comments etc. to the separate community apps. Most of the benefit the "one app" thing IMO is to provide a single feed to check--I want to have a habit of checking only one place when I have a few spare minutes to read something. While it would be kind of nice to also be able to leave comments and such without leaving that app, it's not too difficult to click on the post and leave a comment via another app. So I'd leave that kind of thing off of this list since I don't consider it to be essential. But it could still be worth experimenting with after the essentials are in place!
Another aspect to this is that protocols and interoperability have a downside since they require more coordination between different parties and can thus slow down development of new kinds of features. I think it's important to find the right amount of interop. There needs to be enough interop so that people can build new apps without having to fight against (the lack of) network effects, but not so much interop that people are unable to experiment independently with new kinds of features.
That's a long-winded way of saying I think it's actually better to not worry about making community interaction happen over a protocol, because it gives community app developers more freedom to experiment.
> How reading of different type of content should be handled,as some posts are just media, some are comments?
It may be helpful if community apps include various metadata in the feeds they provide, so reader apps can distinguish different types of posts (e.g. perhaps include a "in reply to" field for replies). When possible, reader apps can also try to infer things about the posts, similar to my suggestion of inferring if a feed is a "social feed" or a "regular feed" by looking at the frequency (and probably also the length) of posts.
> It may be helpful if community apps include various metadata in the feeds they provide, so reader apps can distinguish different types of posts (e.g. perhaps include a "in reply to" field for replies).
Fun Fact: The Activity Streams JSON-LD Vocabulary, which is used in ActivityPub, started, a long time ago, as a metadata extension for Atom (and RSS) feeds.
https://activitystrea.ms/specs/atom/1.0/
Additional Atom back in 2005 provided a minimal mechanism for copying feed items from one feed into a new feed – the "social feed" in your proposal – by specifying an element which references the original source feed.
https://www.rfc-editor.org/rfc/rfc4287#section-4.2.11
Over the years people have put a lot of time and thought into distributed social media APIs and related specs and are still doing it. Current efforts like ActivityPub and the Indiewebcamp stuff are a direct descendant of some of these specs.
(If I were you, my first thought would be to simply read, what has happened in the last 20 years. At the very least it can never hurt to know, what other people found worth doing.)
I'm interested if you have any reading recommendations? Indie Microblogging[1] is on my reading list. My impression so far of existing protocol-based social media efforts is that they're not really going in the same direction I'd like to go myself, but of course you're right that it doesn't hurt to have more background knowledge.
[1] https://book.micro.blog/
Both the Indiewebcamp wiki and Wikipedia often have pages on now defunct protocols and services. That is of course not a perfect approach but it gives one entry points.
Some readers either support <enclosure> or instead load inexplicably tiny/blown up/stretched/pixelated images, or just don't display any images at all.
Consider that podcasts use RSS - yet need a special namespace "itunes" in order to work:
<itunes:duration>30:00</itunes:duration>
Besides that, I also think this problem can be ameliorated to some extent by using and developing open-source feed parsing libs like Python's feedparser rather than using a plain XML parser and doing the rest yourself.
[1] https://feedparser.readthedocs.io/en/latest/
One of the problems is the spec tries to do everything. You have blogs, podcasts, random crap, and now social media all trying to cram in to the same spec. Ideally you want one spec per use case. With modern tech it's very easy to create a new JSON spec which is trivial to parse and serialize. And you can auto generate extremely accurate documentation.
I don't think we really need "another rss" which would just be fragmentation. We just do not need to be using RSS for social media just because you can.
I subscribed to your feed and wish you luck with your nice projects! I did miss an RSS icon on your site, however. ;)
I actually haven't worried about the RSS icon on my site since I figure people who use a feed reader can just copy and paste the site URL and the reader app will auto-detect the feed, and people who don't use a feed reader can just subscribe with email. Maybe it'd still be helpful to link explicitly to the RSS feed I suppose, perhaps underneath the email subscribe box?
I think somewhere close to the email subscribe box will do the job. I even check the footer a lot, or the blog section of pages.
> For example, give this here link a click: https://feedrabbit.com/?url=https://meta.discourse.org/posts...
This is close to the way podcasts work now, and it kind of sucks. I was just looking at a show on the Apple Podcasts site (because it was the first result that showed up in the search results), and it has social media sharing buttons for Facebook and Twitter and an icon to copy some markup to embed an iframe-based player. If you are not Facebook or Twitter or looking to embed an iframe, too bad. The reverse sucks as well: when I'm on the site of the podcast itself, and it gives me a bunch of options to subscribe using Apple Podcasts or Google Podcasts or watch on YouTube. If you use something else to consume podcasts, your best bet is to copy the link to the bare RSS feed and put that in. Problem is, some sites omit that one.
This is one thing that the fediverse is getting right, in comparison. If I use Mastodon and want to touch someone's post (i.e. react to it—by replying, starring it, or whatever), then I can trivially refer to that post with its URL. If I copy the link from my browser toolbar and then paste it into Mastodon, it works. (This isn't amazing. The workflows around it could use some polishing up, but the fact that it is at minimum possible is awesome.) For comparison, when I copied the Apple Podcasts show page URL and pasted it into the Google Podcasts search bar, it returns a message: "No podcasts found".
Related: Please make your products work with URLs (2020) <https://news.ycombinator.com/item?id=22038065>
> Another suggestion: provide browser extensions and iOS/Android sharing menu items so that it's easy to open an web page in the reading app. If there's one or more RSS feeds detected, throw in a subscribe button with checkboxes for each feed. The "shareable subscribe links" should include a link to the original RSS feed in the page metadata. Then if I click on the subscribe link but want to subscribe with a different RSS reader, I can do so easily.
i.e. we should be sure to provide smooth user experiences both for people who don't yet use a feed reader and for people who do. Agreed that Mastodon does this nicely, and I think adding in some browser extensions/mobile apps would help to automate things a bit more.
* or collectively managed, at least; in the vein of w3id.org, for example
[1]: https://indieweb.org/
[2]: https://indieweb.org/social_reader
[3]: https://havenweb.org
[4]: https://www.rssboard.org/rss-autodiscovery
See also https://github.com/RSS-Bridge/ and https://www.jsonfeed.org/
[0] https://discovery.thirdplace.no/?url=&q=https://tfos.co/
[1] https://discovery.thirdplace.no/api?q=https://tfos.co/
It's better than someone F5-ing a page and redownloading all the assets, but feed readers check automatically on a (usually short) timer, so it's not really comparable.
Does YouTube still offer RSS feeds? I remember those being extremely useful when they swtiched from reverse-chronological to the recommendation-driven Home feed.
[1] https://superfeedr.com/
What decentralized protocols try to solve, and what the centralized web has failed us with, is data ownership. Users should have full control over the data they produce, and be free to migrate it to any other node without losing access to the service they're interested in.
I think Nostr looks very promising in that sense: https://github.com/nostr-protocol/nostr
Mind you, I don't think social media is worth reinventing. Connecting everyone on the planet is wrong on a societal level. But P2P services are a good fit for building smaller communities, which is a crucial missing component of the design of the WWW. I'm still hopeful that something built for the masses can take over the current mess we're in.
> Users would still depend on centralized services to publish content, and there's little to no chance that these companies would interoperate using a standard protocol.
All you need is a blog/newsletter platform like substack, ghost, wordpress etc. They may not aggregate your social posts into another feed for you, but you can use a separate service to generate and host the feed, then link to it from your main site.
> Users should have full control over the data they produce, and be free to migrate it to any other node without losing access to the service they're interested in.
RSS and email do this pretty well I think!
I like to think that I'm pretty technically competent, but I really struggle to understand a lot of the standards/protocols that the fediverse/indieweb is built on...
Also has me thinking about how tools like logseq/obsidian could play in an RSS feed world. Never looked into it!
They're comprised of standardized CSS class names to be inserted into HTML and enable meaningful scraping. Especially given that more and more sites are produced using JS frameworks, which have a harder time producing XML than older generation PHP and the like, h-feed seems a no-brainer.
Then I remember when some RSS feeds stopped including the entire article, removing the "syndication" part of RSS. :(
Any feedback is greatly appreciated.
Question is, though, can we get a YC startup from that?
- you can assign priorities to your feed subscriptions or their categories
- you can limit the number of items you can see per feed so that they can't overtake your "dashboard".
https://lenns.io/ (p.s. thanks for any feedback)
I curate RSS feeds on specific topics[1] and populate them with highlights from what I'm reading from across the internet- this can be a literal highlight from an article, a comment on HN, Reddit etc., a Kindle highlight from a book, anything really, as long as it is on-topic.
There is always a link back to the original context for subscribers to dig in deeper if they want to.
I think this is a real sweet spot. I cannot go back to feeds of anything and everything, a hodge-podge mixture of bad one-paragraph summaries or overwhelmingly long RSS item bodies.
I want to know what exactly grabbed somebody's attention that made them think that something was worth sharing, what gripped them about it, and if it also grips me, I'll gladly go to the original context and read further to my heart's content.
But I don't want a never ending queue of things that I have to put an outsized amount of effort into filtering through to even answer the question "is this something that interests me?"
With the explosion of Mastodon I also added the ability for my RSS subscribers to comment on RSS items from my feed using their Mastodon accounts. So far, so good!
[1]: https://notado.app/feeds/jado
This seems like a much cleaner setup and can feed into indieweb as well.
Thanks for sharing, I wouldn’t have gone looking for this.
The outliner[0] feature allows you create someting similar to notado.
[0] https://www.diigo.com/outliner/start
The Organize section could be like https://ooh.directory/
The Share section could offer a feed of all content that users are willing to share publicly. There could be support for ActivityPub to make it a worthwhile investment of time.
It should be a better sales channel to get new users hooked on good content first instead of forcing them to commit to a new account before trying anything.
They went down once in many years and I couldn’t use the web until it was back up.
Here is a workaround that I've had good luck with:
https://www.fivefilters.org/full-text-rss/
In addition to improving usability, it defeats attempts to measure clickbait summary efficacy, etc., since it breaks sites' ability to pull popularity / telemetry info.
How does it work? Looking at a feed.rss file, I don't see any links to Mastodon posts.
>I curate RSS feeds on specific topics
>I think this is a real sweet spot. I cannot go back to feeds of anything and everything, a hodge-podge mixture of bad one-paragraph summaries or overwhelmingly long RSS item bodies.
It is the sweet spot when it comes to consuming your feed on its own. In the context of other feeds, and you may have resolved it with Mastodon feedback, it still takes some time to find the best links in your feed. That's a quality on its own, so please don't feel pressured for change. However, these points would make it sweeter for me:
* Showing the most popular highlights of the week, month and year, by user vote and by the popularity of the main article on social networks, as well as your personal favorites.
* Find like-minded collectors who have included the same highlight or for further drill-down, a set of highlights.
* It would also be interesting to see a note from you why you have selected a highlight, when that's appropriate. Further tags that could be used for sorting and ranking would also be nice.
It uses a "just in time" model to create a Mastodon post if it doesn't already exist when a user clicks on the "Comment" link (it also does a bunch of other stuff to handle truncation, fitting within the submission limits of the instance, making space for source links etc).
I think it's important to try and be a good citizen on Mastodon instances run by volunteers and minimize unnecessary load. The reality is that not everyone is going to want to comment on every single item in a feed, so in my mind there is no point trying to having a 1/1 parity between RSS items and Mastodon points.
Comments initiated by subscribers are posted on Mastodon with the "unlisted" visibility so they don't spam the public discoverability features in the instance timeline, but can be boosted by the curator at their discretion. The commenting user can also boost the highlight on their instance if they wish.
> It would also be interesting to see a note from you why you have selected a highlight, when that's appropriate.
I do this sometimes[1] - curators have an option to post a highlight directly to the public feed of their instance (ie. not unlisted), and then reply to that themselves with notes.
I think I'm a little overdue in writing a blog post about this new feature! Stay tuned for a submission on HN hopefully sometime in the next week!
[1]: https://hachyderm.io/@LGUG2Z/109479665631086833
>>for my RSS subscribers
>It uses a "just in time" model to create a Mastodon post
What is 'It'? notado.app for people who have logged in? There is no links to comments when not logged in. How can new users or people who don't want to create an account discover the comments?
>no point trying to having a 1/1 parity between RSS items and Mastodon points.
To me, the interesting part would be an n/1 relation: One comment section where everybody from all RSS streams can meet to discuss an article. Like HN/new, there is no incentive to comment on a 3 day old post because hardly anybody will read it. The economics change if the comment section can appear on various RSS streams because then, there can be readers and replies to a comment even years later.
Is it acceptable or even desirable to share your mastodon comment sections, or do you see them as a place for the people who follow you?
The links to initiate new comments on the public HTML versions of the feeds show only for people who are logged in, because unfortunately bots and scrapers are not as respectful as they should be.
As a user's feed homepage is designed to be shared publicly, it only takes one bad actor to click on every "Discuss on Mastodon" link for every item in all of a curator's feeds and put undue load on a Mastodon instance which makes the whole "just in time" approach moot.
Where Mastodon posts have already been created for discussion (by authed users, or by any users subscribed directly to the RSS versions of the feeds), those links (ie. to the Mastodon posts) get shown on the public HTML versions of the feeds.[1]
Otherwise, anyone who subscribes to the public RSS version of the feed (unauthed by default, doesn't require an account etc.) is presented with a "Discuss on Mastodon" link at the end of each RSS item on any feed for which the curator decides to enable comments, and this link can be used to initiate new comments/discussions with a Mastodon identity.
> One comment section where everybody from all RSS streams can meet to discuss an article
This isn't really something I'm interested in for Notado, but I wouldn't be surprised if someone sees your comment and runs with this idea!
> The economics change if the comment section can appear on various RSS streams because then, there can be readers and replies to a comment even years later.
It's not quite the same as what you're suggesting, but I am thinking of providing an API for https://kulli.sh where article authors can embed comments on their articles from across all supported platforms at the bottom of their articles. This could go a long way towards keeping discussions fresh regardless of the time that passes since the initial submission due to comments being embedded with the source.
I just need to really sit down and work out a pricing model (or maybe separate models for individuals vs organizations) for the whole thing.
> Is it acceptable or even desirable to share your mastodon comment sections, or do you see them as a place for the people who follow you?
I think this depends entirely on the curator. I personally don't have any issues with mine being shared more widely, but there are settings that I've made available to allow people to restrict comments to approved followers (on Mastodon).
The nice thing about the Mastodon API is that if you enable public comments, you can filter for your posts that have been created by the "Notado Feeds" OAuth app, and then filter again by posts that have >N replies, and then embed those discussions on your personal website (or anywhere else).
[1]: Example here that you can see when unauthed https://notado.app/feeds/jado/software-development#399920c89...
- https://news.ycombinator.com/item?id=33990568
- https://news.ycombinator.com/item?id=33976289
Here’s my mini-site https://beluga.gcollazo.com
App: https://apps.apple.com/us/app/beluga-social/id1626349771
If we look to podcasts as a model — 490K new episodes in the last 90 days, delivered to users and to aggregators alike via "not dead yet" RSS — ads are placed inline with the content. There is no RSS-related "pact" that precludes the relationships you mentioned.
Related analyst estimate: "US podcast ad spending will surpass $2 billion in 2023 and will account for nearly one-third of digital audio services ad spending." https://www.insiderintelligence.com/content/us-podcast-adver...
[1] https://thesample.ai/
RSS makes it very difficult to measure the performance of an ad. Most players in this space wrap a publishers hosted podcast link with their own tracking link, and the main metric of engagement is a download. Downloads themselves are a pretty crude measurement and don’t hold up to something like minutes watched/listened.
Placing ads into the audio directly also just isn’t as performant as streaming it into the media like in video. Publishers and advertisers want more fine grained control over where the ad is placed, when it’s placed, and how it’s consumed by the listener. Podcast ads currently don’t deliver on that.
... and? From the perspective of whom?
> Publishers and advertisers want more fine grained control over where the ad is placed, when it’s placed, and how it’s consumed by the listener.
There you go.
Ad tech is behind when it comes to podcasts? Who fucking cares. Not the audience. Podcast advertising is the closest thing to traditional broadcast ads for TV and radio—when ads were still inert instead of sentient. There's not a damn person on this side of the divide that sees the things you mention as being a significant downside. Not having the self-awareness to realize it is pure déformation professionnelle; this entire comment reads like a burglar lamenting the fact that people keeping their money in the bank instead of at home under their mattresses makes it harder to break in and take it.
I currently use Reeder. I source in my usual news sources and HN and twitter and some subreddits.
I’m working toward a place where I can setup a feed, a frequency, and a service to use both to make an “old timey” newsprint like PDF into my inbox (or an rss feed!) each day so I can still try for that “back when papers were good” feel.
That was many moons ago.
---
[0] Circa 2008, I could find several feeds from Janes that carried meaty non-subscriber extracts.
[1] LaTeX is picky about all sorts of "special" characters that are more common than one might expect.
Finding “full articles” is certainly a pain. I have little idea how reeder does it.
I personally haven't been liking any content aggregation outside of RSS/reddit because I can't take the timeline model of unrelated things being streamed to my eyes without context. I tend to want to specialize what I read or otherwise I tend not to remember it or appreciate it as much (for instance I'd typically scan through news-like nodes during breaks and read art/science/in-depth feeds after work, but something that mixes both makes me uncomfortable).
But I do have a "people" node in my ttrss instance that aggregates from social network sources/blogs/shaarlis. Gives the best of both worlds, I think.
I want to see a good client that supports many different ways of following content: RSS, Atom, Twitter, Mastodon, nostr, youtube, whatever... with smart ways of dealing with different kinds of content (tweets versus blog posts versus videos).
I see these RSS-related recommendations as the next step: what can an app developer do to reduce the effort it takes for others to interop with them?
[1] https://yakread.com/
https://www.nelsonstar.com/news/nelsons-blaine-cook-helped-b...
Wouldn’t that make ActivityPub a successor technology for RSS?
EDIT: maybe not — https://macwright.com/2022/12/09/activitypub.html
The OPML feed changes, your RSS client picks up the changes and starts following the correct endpoints.