Test post
Interesting..
Wondering if I shouldn't make # hashtags clickable 🤔
What do you mean?
Ready to test v1
Unless I'm missing something... I'm Not convinced that's how it works at all..
Standard.site is not a place.. It's a lexicon allowing different post formats into the AT Protocol
So the only place this will be consumable is an AtProto app view that is able to render that lexicon
V1 will be local terminal only but v2 should be running the mcp server side and allow other users to post, reply and view the timeline from their terminals
Working on a MCP for RSC
to be able to test and use RSC from the terminal
Fixed a bug in which markdown used at the source was not properly rendered here !
Not yet... But definitely want to Allow this other than using your rss feed as input 😊
Oops we are about to have an API now..
Still polishing a few things but you'll be able to use a user generated/governed api keys to read/write on your account and read the firehose
There is also a anonymous firehose entrypoint, this could allow anyone to create a completely different UI for any given RSC instance or God knows what other applications on top 😊
This is actually behaving as expected.. Everything added to RSC is public, this is why I renamed the tab Private to Following to avoid this confusion.
So Explore is all the posts on this instance plus all the feeds
Later on I want for users to be able to Discover new RSS feeds they would add to their Following by following feeds added by others users but that's not ready yet..
Currently traveling but I'm definitely going to read that!
Shipped a few fixes today..
D'ailleurs en mobile c'est mort.. C'est carrément le gros bug 😃
Oui ceci était aussi un moyen de tester le threading des commentaires sur un élément local :)
RSC n’a même pas un mois, mais son fonctionnement a déjà beaucoup évolué.
Cette semaine, j’ai supprimé une bonne partie du premier système de traitement des flux, devenu inutile après l’arrivée du nouveau modèle de conversations.
C’est du code en moins, moins de chemins parallèles et une base plus simple pour continuer.
J’ai continué à simplifier l’interface de RSC.
Moins de séparateurs, plus d’espace entre les publications, une meilleure hiérarchie entre le nom de l’auteur et les métadonnées, et le retour des avatars dans le fil principal.
Ce sont de petits changements, mais le fil est beaucoup plus facile à parcourir.
Le passage sur un design flat a fort changé l'expérience UI, je ne suis pas encore satisfait du résultat actuel, mais je vais continuer à itérer jusqu'à arriver à quelque chose de bien
je voulais limité lé côté interface Twitter et ce faisant l'intferface a perdu son côté immédiatement compréhensible, je ne suis pas certain du look actuel en fait, mais avant de me lancer dans un gros chantier je voudrais encore l'améliorer
Une instance RSC peut suivre beaucoup de flux, et certains publient énormément.
L’administrateur peut maintenant limiter le nombre d’éléments conservés par source, ou supprimer automatiquement les éléments distants trop anciens. Le but est d’éviter qu’un seul flux fasse grossir la base indéfiniment.
J’ai ajouté des actions groupées dans l’administration de RSC.
On peut sélectionner plusieurs sources ou utilisateurs, effectuer une action commune et voir le résultat pour chaque élément. Les actions destructrices demandent aussi une confirmation plus claire.
Les sources provenant d’une même instance fédérée étaient auparavant affichées comme une longue liste sans véritable relation entre elles.
Elles sont maintenant regroupées sous leur instance. Cela rend l’administration plus lisible et permet d’appliquer des décisions à une instance tout en gardant la possibilité de gérer une source individuellement.
Cloudron vérifiait que RSC fonctionnait en rechargeant régulièrement la page d’accueil complète.
Comme cette page doit construire le fil, une période chargée pouvait ressembler à une panne et déclencher des redémarrages inutiles.
Le contrôle de santé utilise maintenant une page minuscule dédiée à cette seule vérification.
La vraie instance a rapidement révélé un problème que les petites instances de test ne montraient pas.
Avec plusieurs dizaines de milliers d’éléments, certains fils devenaient lents et le serveur travaillait beaucoup trop. Quelques index manquants dans la base ont été ajoutés et la différence est très nette.
Sur un Web distribué, une publication peut disparaître alors que ses réponses existent toujours ailleurs.
RSC conserve maintenant la structure de la conversation et affiche « publication indisponible » à la place du message manquant, plutôt que de faire disparaître toute la discussion.
Un bug assez important empêchait de répondre à certaines publications reçues depuis un flux RSS ou une autre instance.
C’est maintenant corrigé : les publications distantes peuvent réellement devenir le point de départ d’une conversation locale.
Cette semaine, j’ai retravaillé la manière dont RSC affiche les conversations.
Le fil principal montre les publications qui démarrent une discussion, avec le nombre de réponses. On peut ensuite ouvrir la conversation complète sans mélanger toutes les réponses dans le fil.
Mobile menu is fixed.. Improved also
Can't wait to get webmention working so that comments here can be visible at the sources supporting it
Some people have been impeached for less..
As you can see I'm trying to bring a UI in which instances admins and users will have some control for their experience but there is still a few bugs to hunt down and fix
Next to that.. The backend admin UI could definitely get some love (working on it)
I'm leading RSC in the same direction, "connected instances" will have a export to OPML, so that other instance can import the same connected instance if they wish, users already have OPML import/export so that's done already
but then I want to go further with OPML, right now if you import an OPML into RSC, the "folders" within the OPML, how each RSS is categorized gets flatened, RSC just import the RSS feeds themselves, but very soon I want to allow the users to import OPML subscriptions and then display the feeds in the same way they are organized within the OPML, possibily adding filters in the UI to display/hide specific collections, so depending on the mood, hide politics, or hide sports etc..and only see on the screen what the user selected (politics, climate, sports, tech etc..)
the idea would be to make the reading experience tunable among other things, I'm also tempted to have a Explore tab, where users could subscribe to existing RSS feeds, effectively enabling shared pools/delivery for RSS items, without having multiple subscriptions/polling for the same feed for each user...not sure I'm being very clear here but I think there are quite a few stuff that we could improve in that area
On s'interop ? :)
Working on some improvements for the admin side of RSC but also, found some odd issue with our feed scheduler, slowish, impact is perceptible when a user change between local, federated tabs
it's not related to the SQLite database structure or missing production tuning, that part is all covered, still investigating the root cause :)
This is something I want bring as a feature, manage your feeds on feedland and use your OPML link from feedland to be consumed here.
We already have OPML imports working but with a dynamic OPML the subscription list would only need to be updated on feedland for it to be consumed with any client, including RSC
No, not as of now, we have inbound interop working but RSS.chat isn't interested right now to federate with other instances.
There is a fork of rss.chat which could federate with RSC, technically they speak the same language but not sure there is appetite for federation, not even between closed rss.chat instances apparently
Ping Pong
Welcome :)
Hmm we might need to differentiate federated and remote
so tabs would be local, remote, federated, personal, public
RSC (Really Simple Conversations) is a social feed where everything is distributed via RSS: posts, as well as replies, entire conversations, and corrections published afterward. Three independent sites can thus participate in the same feed without a common API, without a shared account, and without having to adopt a new protocol: if your site already publishes a feed, it’s already a node in the network. Open-source (MIT), installable on your own server with just two commands, in the tradition of Dave Winer’s Textcasting.
Shuuush 🤡
Oh that's coming...but before that some cleanup, v1 dead code is being cleaned up !
Testing Integration with micro.blog
the same is valid for Chatouk sadly
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.
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.
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.
| 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.
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.
source:inReplyTo now travels in every feed we publishThe 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.
This is a test
this is a quote
About to deploy this
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.
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.
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.
Instance operators get real tools to keep timelines healthy without
rewriting history:
Everything is reversible where it should be, permanent where it must be, and every action leaves an audit trail.
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.
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.
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.
Test
Standards-forward, few dependencies, no framework lock-in:
adapter-node) · carta-md +@cartamd/plugin-slash / -emoji (the Markdown editor) · the same unified