jacobobryant

The dumbness is a feature. See my other comments:

- https://news.ycombinator.com/item?id=33990568

- https://news.ycombinator.com/item?id=33990738

- https://news.ycombinator.com/item?id=33976289

Thanks! Feel free to email me if you want any ideas for contributing; I have a never-ending supply :). Email's in my profile.

Nothing in the proposal is at odds with building mobile apps, and yes I would encourage people to do that.

The proposal isn't to make a twitter clone that just happens to use RSS under the hood. I'm basically just saying we should take the existing trend of smaller, focused communities (like you find on slack or discord) and try to add a bit of glue so it's easier to keep tabs on a large number of communities. That's about half of the proposal, anyway.

A lot of the questions you ask are already resolved in the newsletter ecosystem.

Yep--a core feature of Yakread (the reading app I'm developing, mentioned in the article) is that it uses algorithmic curation.

In this proposal, interactivity would happen within the community apps (discord, slack, forums, whatever new ones are built in the future) and not over the protocol. You use a reading app to get a feed with posts with the various communities you're in, and if you want to leave a reply/reaction, you click on the post and get switched to the relevant app/website.

Agreed, hence the importance of treating RSS as an implementation detail rather than a user-facing feature. I'd also love to see more reading apps experiment with algorithmic recommendation too; that's been one of my own focuses for a while.

I think interactions should be done within community apps. No need to do it over a protocol. See my other comment: https://news.ycombinator.com/item?id=33976289

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?

[1] https://yakread.com/

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.

[1] https://thesample.ai/

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.

RSS and email do this pretty well I think!

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].

[1] https://superfeedr.com/

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.

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.

[1] https://book.micro.blog/

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.

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?

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.

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.

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/

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

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.

This was stated:

> The last straw was Elon Musk sending lunatics and bigots against former employees and leaning into conspiracy theories.

Not really--the whole point of htmx is basically that it helps you get by without using a JS framework. It works great if you use it with a traditional server-side framework like rails, django etc.

Highly recommend https://htmx.org/. Makes it easy to create "good enough" UIs with minimal effort, and while spending most of your time writing backend code. Pair it with whatever the recommended C# web framework is. I'm using it for my own solo dev projects/startup and enjoying it a lot.

The main ways that XTDB has been useful to me personally are:

- Immutability, which makes it fit well with the functional programming style used in Clojure. You can create a database connection object that represents a snapshot of the database at a specific point in time (usually the current time), and queries made via that object will ignore any transactions that occurred later. So you can effectively pass the entire DB around as an argument and your functions stay pure. (That also makes it easy to inspect historical snapshots, similar to looking through old git commits--I don't do it often, but it's very nice to have when you need it.)[1]

- Datalog instead of SQL. I find Datalog queries to often be more compact than the equivalent SQL, especially thanks to the implicit joins--you can query for things from multiple "tables" without having to type up a bunch of JOIN expressions. And there are various other handy doodads like pull expressions[2].

- Clojure ergonomics. You can store Clojure maps as XTDB documents as-is without needing to write code to translate them to records.

[1] XTDB's bitemporality also has some benefits over e.g. Datomic (https://www.datomic.com/, another immutable, Clojurey database), though I haven't needed to use it yet--Datomic's "monotemporality" would be sufficient for my current needs.

[2] https://docs.xtdb.com/language-reference/datalog-queries/#pu...

Rum is used throughout, though mostly via middleware[1], so you (almost) never see any calls to `rum.core/render-static-markup`. But all of the hiccup-style data structures (`[:div "foo"]`, etc) do get rendered by Rum.

htmx doesn't render anything on the backend; rather it gives the frontend more ways to interact with the backend. e.g. say you make an inline form--htmx gives you the ability to display/submit that form without refreshing the entire page, but all the html that's sent to the frontend is still getting rendered first by Rum.

[1] See https://github.com/jacobobryant/biff/blob/6353c406adef034448... and https://github.com/jacobobryant/biff/blob/6353c406adef034448...

> Btw, giving a special address would increase the lock-in, IMHO. The newsletter owner would be dependent of Substacks benevolence forever.

It is possible, but at least writers would have the option of importing those addresses or not. Those who are suspicious that Substack will lock down the app more down the road can always opt to "rip the band-aid off" and not import the Substack app addresses.

Perhaps my main argument is "If Substack doesn't let writers migrate without forcing a behavioral change on their readers, then it is solid evidence that Substack doesn't actually care that much about reducing lock-in." The inverse is not necessarily true, and certainly I'd advise anyone who's already convinced of the consequent to not write on Substack :).

I'm a big fan of ghost (especially for anyone into self-hosting!), but the lack of a free plan makes it harder to use as my default recommendation. (Also the lack of single opt-in signup is a deal breaker for me personally, though I understand many people don't care/prefer double opt-in anyway.)

I think https://beehiiv.com is another good alternative, though the styling isn't as nice as on ghost, and I personally found the editor to be glitchy and infuriating to use. Maybe it's just a problem on Firefox. I'd probably use that as my own recommendation for anyone looking for a newsletter platform and cross my fingers that they have better luck with the editor :).

Perhaps check out Matter[1] or Readwise[2]? I haven't actually used either myself (Matter requires an iOS device, though once installed you can also use a web app; Readwise was in private beta when I was first looking at it, but I think is opening up access now/soon). But they look nice. I used Feedbin[3] previously but found the mobile web interface a bit frustrating (I kept accidentally swiping things while trying to scroll).

[and the self-promo bit] I've also made one called Yakread[4], however it is quite unusual and won't be for everyone. Re: your requirements: it does 1 (via integration with pocket/instapaper) and 3 (it's a responsive website at least, no native app) but not 2 /exactly/. It has a home feed which is driven by a ranking algorithm, which is intended to solve the "too many newsletters/bookmarks clogging up your reading" problem, but might be a heavier solution than what you're looking for.

[1] https://hq.getmatter.com/

[2] https://readwise.io/read

[3] https://feedbin.com/

[4] https://yakread.com/ (see also https://tfos.co/p/introducing-yakread/)

The biggest immediate downside for writers of Substack's centralization IMO is that they've started introducing some subtle lock-in with their reader app. Substack is quick to say that you can always export your email list and move to a different newsletter provider. But if your readers have built a habit of reading things in the Substack app instead of their email inbox, then moving your email list somewhere else means your readers will be less likely to engage with your newsletter.

If Substack actually cares about preserving writers' independence, they should provide a way for writers who switch platforms to continue delivering their newsletters to the app. Switching platforms should not force behavioral changes on readers. For example, they could give app users an @inbox.substack.com (or whatever) address. Anything sent to that address will show up in the app. When you export your list of Substack subscribers, you get both their regular address and the @inbox.substack.com address, so you can continue delivering to both their email inbox and the Substack app.

Until they do that, I'll continue to view their claims of putting writers in charge with a measure of wariness. I do think Substack/Substack's founders are sincere, actually. I don't think they're twirling their mustaches, thinking "How can we lock people into our platform?" They're just way too confident in the righteousness of their cause, and as a result I don't think they look inward enough in situations where the interests of Substack, writers, and readers conflict.[1]

(And no, using a paid subscription model instead of ads doesn't magically make all incentive alignment problems go away.)

[1] For example: https://twitter.com/bmorrissey/status/1501568928799244290. When the app was launched, by default they stopped sending emails to people who installed the app, which would hasten the inbox->Substack app behavioral shift I discussed above, strengthening lock-in. They switched it to opt-in after backlash from writers.