@ricardo — following
Follow buttons here act as you, not as @ricardo.
@ricardo follows
| Label | Kind | State | Action |
|---|---|---|---|
| @admin | local | — | |
| scripting.com | source | — | — |
| rmendes.net | source | — | — |
Timeline
-
Curious : Linux VM in your browser 🤔
Reply source -
Testing Integration with micro.blog
-
We can't federate or be able to reply to a rss.chat instance because nothing is wired on their side so that different rss.chat instance can talk to one another. much less interop with a different textcasting implementation, which is what RSC is all about.
it's a bit sad but it's not a blocker. - Reply
Shipping v2: how this instance got a new engine mid-flight 🚀
This post is being written on the thing it describes. A few days ago, every RSC instance you're reading this from swapped its entire data model — the part that decides what a post is, who wrote it, and how conversations hang together — while staying online. Here's the story, with the numbers.
What changed underneath
The old model did what most feed readers do: fetch a feed, keep the latest copy of each item, overwrite on change. Simple, and quietly lossy.
The new model — we call the read side of it the projector — works like a courtroom instead:
Never store conclusions. Store evidence — every delivery of every item from every source, every version observed, every attribution claim with its strength — and derive what the reader sees, fresh, at read time.
That one idea is why moderation is instant and reversible, why an author's name comes from their attribution instead of whatever arrived last, and why a blocked source's posts vanish everywhere at the next read without deleting a byte of evidence.
The build, in numbers
verticals shipped 4 (control plane, logical items, moderation + verification, migration) commits on the branch ~140 tests at cutover 1,084 core + 330 web defects caught by review before deploy ~30, including 5 that only a whole-system pass could defects found by dogfooding, fixed same day 12 The dogfooding finds were the humbling part. My own blog showed up as a publisher named "Interesting read as always !" — the pipeline had promoted an item title to an author name. Replies arrived before their parents and stayed orphaned forever because a scheduler was built, tested, and never wired in. Podcasts carried audio in the data model and the UI just... never rendered it. Every one of those is now a regression test.
Cutover day
The flip itself is one atomic transaction at startup: convert every legacy user, post, follow, and push lease into evidence — same IDs, same permalinks, byte-exact WebSub leases — write a marker, open for traffic.
If it crashes halfway, nothing changed and it retries next boot.
It worked. And then the timeline took six seconds to load. 😅
SQLite never indexes foreign keys for you, and the projector looks things up per item. On a table of 32,000 identity keys, every lookup was a full scan:
EXPLAIN QUERY PLAN SELECT key FROM logical_identity_keys_v2 WHERE logical_item_id = ?; -- before: SCAN logical_identity_keys_v2 (478ms for a 50-item page) -- after: SEARCH ... USING INDEX (1ms)Two migrations later every foreign key in the model is indexed, a CI guardrail reflectively walks the schema and fails the build if any future table ships an unindexed key, and the timeline renders in ~40ms — faster than v1 ever was.
What you actually get
- Real bylines — posts from federated instances show their author, not the instance's hostname
- Conversations that reassemble — replies thread across instances, in both directions, because
source:inReplyTonow travels in every feed we publish - Podcasts play in the timeline — native audio, no player library
- Edit history you can read — every version, honestly labeled, including
silently overwritten"changed on arrival" timestamps - Moderation with receipts — hide, quarantine, block, purge: every action ledgered, every effect reversible
The old model is still in the codebase, dark, waiting for its retirement release once this soak period ends. The feeds never stopped.
That was the whole point: conversations travel as RSS, and the plumbing underneath them should be replaceable without anyone's reader noticing.
Built in the open — the repo, the specs, and every review document live at github.com/rmdes/textcaster.
-
RSS.chat has an API
Reply sourceIt's a standard REST API.
Here's the server side of the API.
Here's how you call it from browser-based JavaScript. You can include that code in your apps.
Here's an example app that implements a simple blog builder for my recent posts on RSS.chat. We were thinking about doing this as a project for Claude and myself but decided it would be more fun to let devs see what they can do here. :-)
And finally here are the docs for the API itself.
- Reply source
How can you tell you’re working on the web? When you do something new and innovative you help your competitors‘ users without forcing them to use your product. They are free to stay where they are and still get the benefit. People choose your product because it’s better for what they’re doing, or it feels better now, or whatever. We want the web to be the platform and it's cool because there is no platform vendor. - Reply
About to deploy this
- Reply source
RSS.chat worknotes are a feed now. Updated when there's a new feature or fix. Same info is on the worknotes pages in the repo.
-
Interesting read as always !
Reply sourceInteresting read as always !
-
Dear podcast client devs
Reply sourcePodcast client developers -- don't give up like this guy did. Yes RSS is delicious but you all haven't done anything new with it since 2004 or so. No wonder the competition is catching up, they're actually delivering new features while you all haven't done a thing. RSS is like other web stuff, if you want to move forward you have to do things that will help your competitors. Stick your neck out, innovate, and smile when your competitors copy it. There is more to do.
Subscribable subscription lists would allow anyone to maintain a list of great podcasts, curated -- like a mutual fund, or a top 20 list. This has always been the problem with podcasting. Find me something good to listen to now. All the shows tend to repeat. I've heard that cast before, I say as I tell Pocket Casts not to add it to my queue. Discovery needs to be easy. This one feature will give me infinite options. And give other developers, not client devs, to enhance the whole field of podcasting. The user would just tell you which sub service they're using, and the rest is code. And not particularly difficult code.
I want to subscribe to a list that's maintained by people who listen to 100s of casts. And when I get tired of them, I'll fire all my guides and add some others.
This is one step more complex than handling OPML subscription lists for import and export, which you all already do. Now if you don't understand this, and why it's appealing them imho your client deserves to die a honorable death. If your mind is alive, then get with it, and I will help, and btw we can easily create apps that make it easy. We just need nodes on the network whose purpose is to maintain sub lists.
Here's the deal. I really did put together the system that makes podcasting work. Top to bottom. Would it kill you to listen to what I think the next step is? I can't hurt you, and I don't want to. I just want to see the thing that we all created by unwittingly working together, where you have to be overt in the working together to have a chance of surviving the boredom users feel by these products only getting superficial upgrades.
It's time to rock the f'ing boat! :-)
Podcasting forever!
- Reply source
-
What happened to thenumbers.com ?
Reply sourceI wish we had the full story here…this article is interesting but there is definitely something missing on what happened…
- Reply source
Amyloo, a longtime friend from the early days of podcasting, has made an appearance on demo.rss.chat. So happy to see her. Here's one of the bits we did, back then in the very early days of podcasting in 2005. A duet of Green Acres. Ten seconds of dead air at the beginning, it was pretty common in those days. But I think the spirit of it is lovely. BTW fwiw I cracked my voice on purpose. 😄
- Reply source
A new feature on rss.chat, images. Up to 2MB per. User interface couldn't be simpler, get the image on your clipboard, start editing your post, put the cursor where you want the image, paste. Prior art was GitHub and Slack. It was driving me crazy not having this feature. I think perhaps I should add this to textcasting. It's a feature I needed to be reminded is essential. The first browser to support inline images came from Univ of Illinois in 1993, NCSA Mosaic. It didn't come from TBL, but it is most definitely a standard feature of the web. - Reply source
Early this morning we got a report of a security issue in the rss.chat server, quickly fixed and tested the new version. So, if you're running your own instance of rss.chat, you please follow the instructions and do the update asap.
- Reply
What's coming to RSC: smarter sources, cleaner timelines, honest attribution
We've just finished designing the biggest under-the-hood upgrade RSC has had since launch. It's being built in four stages, and while most of the work is invisible plumbing, all of it exists to change what you actually see and trust in your timeline. Here's what you'll get.
One story, one card
Today, when the same post reaches RSC through more than one feed — a personal blog you follow and a newsletter that republishes it — you can end up with duplicates in your river. After the upgrade, RSC understands that these are the same item.
You'll see one card, showing the best version available,
with clear credit to the person or site it came from. If a better copy arrives later (say, the author's own canonical version), the card quietly upgrades itself.Know where things really come from
Anyone can put a name on a feed item. Soon, RSC will be able to check.
When a post claims to come from a particular site, RSC can verify that the post actually appears there — and content that passes gets the strongest attribution. Impersonation gets harder; genuine authorship gets the credit.
A safer, better-kept neighborhood
Instance operators get real tools to keep timelines healthy without
rewriting history:- Hide an individual post clear record of what was done and why.
- Purge a bad source completely — and it stays gone: renamed or redirected copies of a purged feed can't sneak back in.
Everything is reversible where it should be, permanent where it must be, and every action leaves an audit trail.
Your subscriptions, upgraded in place
When the switch happens, you don't have to do anything.
Everyone you follow, every feed you've subscribed to, every post and conversation, and the instant-update connections that make new posts appear live — all of it carries over automatically.Each instance is backed up before the switch, the changeover happens in one atomic step, and if anything looks wrong we
restore and try again another day.What doesn't change
RSC stays RSC. Posts, replies, and conversations still travel as plain RSS that any reader can consume. Your data stays yours, in open formats, with no lock-in.
Everything above works without JavaScript, in both themes, on the web you already use.
When?
The four stages ship in order, each fully tested behind a switch before it's turned on.
We'll announce here as each one goes live — starting with the foundations, which are being built right now.
- Reply source
Something to keep in mind in press reports with AI apps breaking out of their sandbox, it works the other way too. If you give a big piece of code to Claude and ask if it to find any security issues, it not only finds (at least some of) them, but it also suggests fixes. Quickly. I've done it the other way, where you have a small team, and someone discovers a hack, and you have to find the right answer and implement it, asap.
-
How the web got gunked
Reply sourcePosted on Twitter in the middle of last night, written on iPad.
I use twitter these days because it’s where the people are.
The distributed ideas, masto, threads, blue-sky, did not gain critical mass as far as I can see.
Threads and blue-sky are not distributed. distributable is not the same as being distributed. It’s like saying the 1962 Mets were able to win the world series. In some fashion perhaps in an alternate universe, in reality, not gonna happen.
At some point we will give up on that approach and adopt the only model that could work, the web, because it forced us to work together, which goes far beyond open source in building the kind of freedom that open source advocates promise.
We need to go back to the source of freedom we enjoyed in the approx 14 year period between the inception of the web and its exploitation, via Cory Doctorow’s doctrine, getting shit on and in. Don’t just blame the vendors, the people wanted the shit too, they wanted their billions, and the web turned from a freedom machine to a gunk works.
Working together is the only way out of the shit we’re living in, in every aspect of life. Working together. Say it again and again until you do it. Underneath the mess, the beauty of the web is there still to build on, but only if we momentarily suspend our search for great wealth, and instead seek our humanity. Working together is the way.
PS: Elon Musks twitter may suck to some but I praise him and it for giving us the space to rant, something the great masto, threads and blue-sky refuse to.
- Reply source
- Reply source
Elsewhere: "Threads and Bluesky are not distributed. Distributable is not the same as being distributed. It’s like saying the Mets were able to win the World Series in 1962. In some fashion perhaps in an alternate universe, in reality, not gonna happen."
- Reply source
RSS.chat now supports SQLite. Simpler and faster to install. You don't have to host a database, it's now built into the server. Full instructions. Questions or issues.
- Reply source
Reminder: We have a demo server for anyone who wants to try RSS.chat. I'm glad we set this up. It's sort of like support, and bug catching.
-
Not a fork… an implementation from scratch in the case of RSC :)
Reply sourceNot a fork… an implementation from scratch in the case of RSC :)
- Reply source
RSS.chat -- I don't have enough places to fit all the ideas these days. But we have been digging and the pieces fit together pretty well.
-
Three-part ecosystem
Reply source
There are three parts to the rss.chat ecosystem.- Writing. Today's rss.chat product is a group writing system, designed for a school department, a team of developers, a family, a magazine or group blog, or just as well, a single author. I don't think it would work well with 1000 users, because it doesn't implement the concept of "follow." And imho it's important that the people are colleagues, family or friends, people invested in real world relationships with each other, so they don't drop a turd in the conversation and just expect to walk away. I've found that dynamic works most of the time. But important point -- all kinds of writing tools can exist. Any social app can to be part of this, all they'd have to do is support inbound and outbound RSS and textcasting. Small pieces loosely joined and every part replaceable. And we do it with the web, we don't try to invent a new web. I will keep beating that drum because it's the difference between using twenty editors or one. As a writer I know that one is the best, with choice among 20 editors, because maybe somedays I feel like writing in a different editor. To make the web a real writing environment, you have to think like a writer. ;-)
- Reading. This can be as simple as a current-day reader like Feedly or NetNewsWire, or more, using the new features in RSS.chat feeds.
- The unknown: We're allocating in our minds (Claude and I) room for a fair number of unforeseen products created by independent software devs in the cracks between reading and writing, and in a larger world (search, navigating through structures, etc. We have really good thread support baked into the protocol. And a bit of docs about how the pieces fit together.
I'm thinking in these terms because I'm starting to work on how my reader will work. I have some ideas, not sure when I'll be ready to write about them. And to be clear there will be no requirement that you use our writing tool to use our reader or vice versa.
Every part replaceable.
-
RSC — Really Simple Conversations — is a feeds-native social timeline: people wh...
Reply sourceRSC — Really Simple Conversations — is a feeds-native social timeline: people who post here and people who post on their own site are equal citizens. Everything travels as RSS — posts, replies, whole conversations — so following, threading, and federation work with nothing but open feeds.
My goal with RSC is not just to publish the code of how it operates and interop but also to publish the spec/plans used to build the code itself.
- Reply source
Evening: Very productive day. We rolled through some UI stuff that had been on the list for a while. Set up for a big job tomorrow, server side. The worknotes for client and server apps.
- Reply source
Two methods for creating standards: bootstrap and boil the ocean.
-
RSS can absolutely participate in virality. If a million people subscribe to a f...
Reply sourceRSS can absolutely participate in virality.
If a million people subscribe to a feed, read a post, and some of them redistribute it through their own feeds, websites or social accounts, the post can become viral. Virality is an emergent pattern of circulation, not a button owned by a platform.
What RSS provides first is distributed visibility: reach created across many independent readers and publishers, without one algorithm deciding what everyone should see.
-
Open-source collaboration in the age of AI I am not going to reconstruct the ent...
Reply sourceOpen-source collaboration in the age of AI
I am not going to reconstruct the entire disagreement that prompted this post.
Some of the public exchanges have been deleted. Other parts happened privately or by email. I have no interest in tracing every sentence, assigning blame line by line, or producing a forensic account of who said what. That would only prolong a conflict that has already taken up too much space.
But people noticed that I removed my participation from the project, and I have started receiving emails from strangers asking what happened. So I want to explain the broader issue, without turning a personal disagreement into public theatre.
Open-source collaboration does not necessarily become easier because AI makes it easier to inspect code, identify bugs, produce patches, and write detailed issues. In some ways, it becomes considerably harder.
You can spend time formulating an issue carefully and professionally, only for it to be perceived by the repository owner as a list of orders.
That owner is, of course, entirely free to reject the contribution. They can close the issue, say that it is outside the project’s scope, explain that it is not on the roadmap, or simply decide that they do not want to pursue it. There are thousands of legitimate ways to govern an open-source project.
Governance by burnout is not one of them.
When you use an AI tool to help document a problem, the resulting issue may contain precise examples, references to specific lines, screenshots, reproduction steps, and concrete observations gathered by running the software outside the environment of its original author.
That can be useful. It can also be overwhelming.
The problem is that the intention behind such a contribution may not survive the way it is received. You may believe that you are documenting a bug thoroughly. The maintainer may see a wall of text, an unsolicited audit, or an attempt to dictate the project’s direction.
You can ask questions first. You can soften the language. You can repeatedly state that the maintainer is free to ignore the suggestion. None of that guarantees collaboration when the other side does not experience the contribution as collaborative.
Most of my experiences have been different.
I have submitted issues and pull requests to several projects, including repositories connected to my professional work. Some of those contributions were written with the help of AI—not because I could not be bothered to write them myself, but because the tool already had the context: the code, the logs, the behaviour I had observed, and the steps that exposed the bug.
When the issue was valid, it was investigated. When the patch fixed a real problem, it was reviewed. Sometimes it was merged directly. Sometimes the maintainer rewrote it to match the project’s architecture, conventions, or preferred way of working.
That is normal. A contribution is not an instruction. It is material offered to the project.
For Indiekit, for example, I submitted a skeleton pull request of roughly two thousand lines containing the foundations of a Microsub plugin. It was not something the lead developer could review immediately. It required time and several email exchanges. But the contribution was handled professionally.
That first pull request opened the way for further work, with the plugin I already use in production gradually being reviewed and reconstructed under the oversight of the person responsible for the project.
I have seen similar responses in projects such as Dolibarr, Odysseus, and ComfyUI. A suspected bug was investigated. Its existence was corroborated. A fix was discussed or implemented. Everyone using the project could then benefit.
That is one of the core ideas behind open source.
This is not an argument that AI is inherently good or bad. It is an argument that collaboration still depends on people who actually want to collaborate.
A project can publish its code under an open-source licence without being socially open to outside participation. That is entirely legitimate, but it should be understood honestly. Otherwise, openness risks becoming more of a posture than a practice.
The recent conflict also showed me how easily both sides can misread each other.
The maintainer indicated that they could not follow or process what I had written because it was too much. I interpreted this as a request for greater clarity and replied with another comment summarizing my previous points, together with screenshots from my implementation.
I believed I was reducing the burden.
In reality, the person was angry. They had perceived my earlier issues as orders and felt overwhelmed by my participation as a whole. My attempt to clarify the situation therefore became another contribution to the very problem they were describing.
I later tried to explain myself privately and apologized. I was also transparent that some of the issues and comments had been written partly, or sometimes almost entirely, with Claude’s assistance.
Again, this was not because I had randomly asked a model to invent criticisms of somebody else’s project. The tool was helping me work on the implementation. It already held the context of the bugs and limitations I had encountered, so using that context to draft an issue was the most direct workflow.
But the origin of the text does not erase its effect on the person receiving it.
Everyone is overwhelmed. Maintainers especially are often expected to write the software, review code, answer questions, manage releases, handle support, moderate discussions, and absorb the emotional reactions of users—all without compensation.
Adding more explanations, even explanations intended to correct a misunderstanding, can simply produce more pressure.
My response was therefore to withdraw. I removed my contributions and comments where I could, apologized for the parts for which I could take responsibility, and moved on.
That was not a protest against my work being rejected. Nobody is required to accept an issue, a patch, an idea, or a contribution. In a world where AI makes bootstrapping increasingly accessible, people can fork a project and take it in another direction. That freedom is essential, and it should not change.
The issue is not rejection.
The issue is the growing potential for misunderstanding, misperception, and misjudgment between people working at radically different speeds, with radically different expectations, using tools that can generate more material than any small project is equipped to absorb.
Over the coming years, situations like this will become common.
Contributors will have to learn that the ability to identify ten problems does not mean that a maintainer can process ten issues. The ability to generate a detailed analysis does not mean that detail is always helpful. A technically correct contribution can still arrive in a socially destructive form.
Maintainers, in turn, may need clearer ways to communicate what kind of participation they want, how much they can realistically review, and whether outside contributions are genuinely welcome.
We are entering largely uncharted territory. The tools are evolving faster than the social practices around them.
We will need to rediscover some old rules of collaboration and invent new ones: smaller contributions, clearer boundaries, explicit expectations, consent before large interventions, and a better awareness that attention—not code—is often the scarcest resource in an open-source project.
AI can help us produce more.
It cannot make us ready to receive more.
Whoever reads this, I came and go in Peace, I will keep doing my part the way I see fit, but I have definitely learned a lesson here and for that, I’m thankful.
-
There is a Ideas markdown file in the RSC GitHub repo but I want to share on my...
Reply sourceThere is a Ideas markdown file in the RSC GitHub repo but I want to share on my blog some of the things currently in development :
-
Better user management Users should be able to cancel and remove their accounts and cascade removal of their posts and replies.
-
better moderation and governance for feeds
creating an open publishing system is easy, moderating it is a pain in the A, so before this goes into a direction I don’t want I want to be able to have the tools to moderate feeds the system ingest.
I want to be able to differentiate an RSS feed from a compatible textcasting instance and RSS feeds added by users.
Currently, there is no difference between a user a a “remote user” representing an RSS feed subscribed by a user, not all feeds are textcasting feeds so we need a way for admins to decide which other instance they federate to, think subscribe bidirectionally and users added RSS feeds.
If/when an item comes from a remote feed I want to be able to moderate it, hide it, remove it, block the source if needed.
Inevitably someone will use one the demo sites to publish unwanted content or subscribe to a dubious feed just to see How it goes…
- Gated community Currently registration is open and users can even make temporary posts to try the app, these guest users without a formal registered account are wiped periodically unless they verify their email registration.
I want this to be configurable, each instance will have different requirements, RSC need to come up with tools to help operator handle an instance.
-
Better enclosure support Right now the system doesn’t support enclosure (podcasts) obviously the underlying tech support it, it’s RSS after all but the web front-end doesn’t know what to do with it, I want a shiny play button where needed and the ability to properly display media elements.
-
Better integration with YouTube, Funkwhale, SoundCloud, Spotify A link from there should display an embedded player and fallback to link if no JS
There is probably a tons of things I’m not including here, my brain is fried today.
-
-
Stumbled upon a few (local) #AI tools that made me really curious https://www.fe...
Reply sourceStumbled upon a few (local) #AI tools that made me really curious
- Reply source
John Johnston got inboundRss working, so now he can automatically post to his WordPress blog from demo.rss.chat. These are the kinds of things that "just work" when standards are used to connect to the outside world. WordPress, as I've been saying so long, has all the right hooks to be the place where text and publishing meet on the web. They've been reluctant to step into that role, but I think it'll be realllly good for Matt's company and the community. A lot of fresh developers can come in via the web. That's how I personally approach WordPress. A place to send text so it can be widely read. A growing foundation for a community to build on, and would imho help the web enormously. - Reply source
Howard Rheingold is just the kind of person rss.chat was designed it for. And here he is asking what it is. Very fortuitous. And if you're wondering how a person can think of it in July 2026, it's for you too. ;-)
-
What is RSS.chat for Howard Rheingold
Reply sourceI am longtime friends and an admirer of Howard Rheingold, who expressed an interest in RSS.chat. I asked Claude to read my blog posts and summarize, in the third person.
RSS.chat is a small social network built from the web's own parts. It looks like a chat room or Twitter -- you write short posts, people reply, conversations thread -- but underneath, every person's posts are an RSS feed, the same technology that makes podcasts work. When you post, you're adding to your feed. Anyone, anywhere, can subscribe to it with any feed reader -- no account needed, nothing to sign up for. There's also a feed of everyone's posts together, and a public list of all the members.
Why does that matter? Think about how podcasts work: anyone can publish one, anyone can listen with any app, and no company sits in the middle deciding who can talk to whom. Text on the web works that way too -- that's what blogging is, and there are still places where writing gets full support: WordPress, GitHub, the new AI tools. They don't try to limit you. But the vast majority of the text people write goes into social networks, which stripped writing down: no links, no titles, length limits, no editing, and your words locked inside their walls, not part of the web. Dave's term for the idea is textcasting -- the idea that a piece of text should work like an MP3: it plays everywhere. No one would accept a rule that songs can only be 300 seconds long. That's the rule we've been living under for text.
rss.chat is a bootstrap, the same way blogging and podcasting were. It starts deliberately small -- a network for a group of friends and collaborators, what Vonnegut called a karass -- running on a small server. It is not trying to be the next Twitter. The idea is lots of small networks like it, run by anyone, all able to connect, because they share the same open formats. Every part is replaceable: the writing app, the reading app, the server -- swap any piece and the network still works. Small pieces, loosely joined. There is no platform vendor. It's like the web because it is the web.
The app you see is only a third of the picture. It's the writing surface. Aggregation -- following many feeds in one place -- is what feed readers and FeedLand already do. And the third part is whatever other developers build. The software was written with Claude, an AI, and the whole thing is documented so that anyone can have their AI build a compatible piece, or clone the whole thing and change anything about how it looks and feels. The one rule of the club is interop: stick with the open formats underneath, so everything connects. Not locked in -- locked open.
If you looked at Dave's blog in 1994, you couldn't have extrapolated Twitter -- but every step was there. This is that kind of beginning.
Written by Claude.
- Morning: Today on RSS.chat we are knocking off quick hit bug fixes. We've been focusing on big hit examples for the last few sessions.Reply source
- Reply
Textcaster is now RSC — Really Simple Conversations
Same project, new name and new home.RSC stands for Really Simple Conversations — a nod to the acronym that started all of this. It also says what the project actually does that a feed reader doesn't: posts, replies, and whole conversations travel as RSS, so following, threading, and federation work with nothing but open feeds.
New homes:
- rsc.rmdes.be — this instance
- alice.rmdes.be and bob.rmdes.be — the two federation peers
- the source code
Every old textcaster.app link still works (for a year) until the domain die.
The old domains now issue permanent, path-preserving redirects to their counterparts, so existing permalinks, feed URLs, and any conversation already federated out there keep resolving. Posts published before the move keep their original GUIDs on purpose — remote instances and readers won't see a flood of duplicates, and threads stay intact.
If you subscribe to a feed here, you don't need to do anything: the redirects are 301s, so well-behaved readers will quietly update their subscriptions to the new address.
One small thing if you have an account: you'll be signed out once. Session cookies are namespaced to the app name, so the rename invalidated them. Log back in and you're set.
-
@wjmaggos@liberal.city it doesn’t have that… At most if a lot of different insta...
Reply source@wjmaggos@liberal.city it doesn’t have that… At most if a lot of different instances existed, and were interlinked you would have distributed reach, can that be called social media boost? I don’t know… So yes currently #RSC is a social network with integrated RSS feeds, literally made for small communities with specific topics… Albeit it could also be used in different ways
- Reply sourceToday we have our first example app for WordPress. We started with an app I wrote that keeps scripting.com in sync with daveverse.org, a WordPress site. I have the app running in a tab on my desktop, you don't need a server for this. We use WordLand to bridge us, but if you have good WordPress code that uses their API, you won't need that. This is also a firehose app, it doesn't read the feed, it lets rss.chat tell us, over a websocket when something new has been posted or updated. We need to break through in Inbound RSS. If every social site supported it, that would be the end of lock-in in the social web. Great place for WordPress to lead.
- Reply source
Way back in March as I was starting to work with Claude Code, I think -- we put together a pretty nice outliner that is remarkably feature-rich. I barely remember doing this. It's what got me moving in this direction, and next month we started doing what became rss.chat.
- Reply source
I wonder if it makes sense to try to implement standard.site in the context of rss.chat?
- Reply
Your personal feed reader is open — subscribe & manage is live
The per-user feeds milestone is complete. SP1 built the engine, SP2 gave you the four tabs — and now the part you actually touch is here: subscribing to feeds and managing who you follow, fully self-serve. No admin required.
Subscribe, right from home
There's a subscribe form on the home page now:
- Paste any feed URL —
https://their-site.com/feed.xml - Say what it is: a site or publication, or an individual
- Hit Subscribe
Where you land depends on what you subscribed to:
You subscribed to… …you land on a person or a web feed Personal, filtered to your new feed an instance / peer Federated a feed on this instance (even your own) Personal — resolved locally, no duplicate shadow It's rate-capped and SSRF-checked — you can't blow past the per-user limit or point it at internal addresses. And like everything here, the form is a plain post: it works without JavaScript.
Manage who you follow
Your following page is now a real manager:
- Your own
/u/<you>/following→ "Your subscriptions," each row with an Unfollow button, plus a "Follow someone" box. - Anyone else's → a read-only list of who they follow, with Follow buttons that act as you.
Personal river looking empty? Home nudges you: "follow people and feeds to fill it."
For admins
A new Settings tab under
/adminexposes Max subscriptions per user — tune the per-user cap live, no config edit.So that's the whole loop: subscribe → read your Personal river → manage → done. Textcaster is a feed reader with a social layer now, end to end. 📡
- Paste any feed URL —
- Reply source
Just finished The Expanse for the third time. Realized that the inners of today are Silicon Valley and the Belters, that’s the web.
- Reply
🔜 Coming next: subscribe & manage (SP3)
The engine is live but the web still needs to catch up. Next up:
- A self-serve subscribe form on home — paste a feed URL, pick person or web feed, done. (No more admin-only "add" button 403-ing everyone.)
- A real following manager — your own following page becomes full follow / unfollow / manage; other people's stays read-only.
- An admin Settings tab for the subscription cap.
- Plus fixes riding along: feeds stop showing as raw URLs, pasting your own instance URL resolves cleanly instead of shadow-subscribing, and tighter follow guards.
Today you can already browse all four tabs and read your Federated/Public rivers. Soon you'll wire up your Personal river with a couple of clicks.
- Reply
Per-user feeds (SP1 / SP2 shipped, SP3 next)
Textcaster is becoming a feed reader — with a social layer
Until now Textcaster had one timeline: the instance firehose. We're rolling out per-user feeds in three parts — the first two are live right now.
✅ Shipped: the subscription engine (SP1)
Every registered user can self-serve their own subscriptions. Feeds carry a type:
personandwebfeed→ anyone can subscribe (registered, rate-capped, SSRF-checked).instance→ admin-only. These are the federated peers (the Connected instances), shown to everyone.
Under the hood: a capped
POST /me/subscriptions, follow/unfollow with orphan cleanup, OPML import and export, and an admin-configurable subscription cap.✅ Shipped: the four-tab home timeline (SP2)
Home is now tabbed — four lenses over the same live pool, each with real-time prepends and each a plain
?tab=link (no-JS friendly):Tab Shows Local posts written on this instance Federated all peer/instance content across the network Personal your river — only the people & web feeds you subscribe to Public the wide-open public firehose Signed in, you land on Personal by default. Guests land on Public. Your profile at
/u/<you>is where "just me" lives — it isn't a tab. - Reply
Shiped today Multi-session
Two accounts, one browser, zero re-logins
Textcaster now supports multi-session: keep several accounts signed in on the same browser and switch between them instantly — no logging out, no re-typing passwords.
Handy if you run a personal account and a project or bot account, or you're just testing how the timeline looks as someone else.
How to use it
- Sign in to your first account as usual.
- Open your Accounts page (
/accounts, linked from settings). - Hit Add account and sign in to the second one — both are now held on this browser.
- Back on Accounts, click Switch next to any account to become it. That's it.
On the Accounts page you get
- A
currentbadge on whoever you're posting as right now. - Switch — one click to jump to another held account.
- Log out — sign out of just that account, staying on the others.
- Log out of all accounts — clear the whole set.
You can keep up to 3 accounts signed in per browser. It's registered-only — guests don't see the switcher.
Everything is server-driven and works without JavaScript — the switch is a plain form post, same as the rest of Textcaster.
-
Hmmm I wasn’t expecting THAT :)
Reply sourceHmmm I wasn’t expecting THAT :)
-
Good work! Both the explainer and the implementation! I’m using indiekit which b...
Reply sourceGood work! Both the explainer and the implementation! I’m using indiekit which basically comes with IndieWeb batteries included! https://rmendes.net and I’m working to get it implemented on RSC https://rsc.rmdes.be
- Reply
Posts in here need a better
timestampGoing to add this to road map
- Reply
New today: you can edit your own posts now.
The interesting part isn't the edit button — it's that posts here are RSS, so an edit stays current everywhere it's travelled. Change a post and it carries an atom:updated marker on its stable permalink; every instance that already pulled it in notices on its next poll or push, updates its copy, and keeps its own revision history. No silent overwrite — and it doesn't jump your post to the top of the timeline.
We tested it live today: edited a post right here, then watched it propagate to two other instances, each independently recording the previous version. Posts that stay current, wherever they've been.