[HN Gopher] How to rebuild social media on top of RSS
___________________________________________________________________
How to rebuild social media on top of RSS
Author : jacobobryant
Score : 50 points
Date : 2022-12-13 20:15 UTC (2 hours ago)
(HTM) web link (tfos.co)
(TXT) w3m dump (tfos.co)
| behindai wrote:
| Why? There are many other good decentralised solutions on the
| market
| jacobobryant wrote:
| 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
| lloydatkinson wrote:
| 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:
|
| <itunes:duration>30:00</itunes:duration>
| jacobobryant wrote:
| 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.
|
| [1] https://feedparser.readthedocs.io/en/latest/
| cxr wrote:
| > 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.
|
| > 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>
| jacobobryant wrote:
| 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.
| mawise wrote:
| 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].
|
| [1]: https://indieweb.org/
|
| [2]: https://indieweb.org/social_reader
|
| [3]: https://havenweb.org
|
| [4]: https://www.rssboard.org/rss-autodiscovery
| zozbot234 wrote:
| 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.
| giantrobot wrote:
| 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.
| shadowfacts wrote:
| 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.
| zozbot234 wrote:
| ActivityStreams can be hosted in the exact same way, hence
| the "pull" model. It's not the same as ActivityPub, although
| the latter builds on it.
| amadeuspagel wrote:
| Or even a static website that you can deploy on many free
| CDNs, such as cloudflare pages, vercel or netlify.
| jacobobryant wrote:
| 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.
| rambambram wrote:
| 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. ;)
| tommica wrote:
| 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?
| jacobobryant wrote:
| Thanks!
|
| > 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.
___________________________________________________________________
(page generated 2022-12-13 23:00 UTC)