@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
-
Working on a MCP for RSC
to be able to test and use RSC from the terminal -
Wishing there was a fully supported ATgeo lexicon that most bluesky app views co...
Reply sourceWishing there was a fully supported ATgeo lexicon that most bluesky app views could understand…it would allow us to build location aware posts from location data (think disasters, quakes, flood etc)
-
Sometimes I’m wondering, what would be the cost of stopping supporting the Masto...
Reply sourceSometimes I’m wondering, what would be the cost of stopping supporting the Mastodon API layer and instead work towards proper implementation of client to servers opening the route for a universal mobile app for #fedify based AP implementation.
For indiekit I used Fedify to bring this very blog into the fediverse but then I wanted to be able to use Phanpy and other mobile app so I built a compatibility api layer that these mobile apps expect to find allowing me to use my own site with any Mastodon mobile app. It works but it’s buggy and I’m subject to API layers change and other future breakage I don’t want to deal with in the long run.
So now I’m wondering, do I drop this API layer and build a universal client?
-
People comes in all shapes and sizes but writing code into OPML outlines to then...
Reply sourcePeople comes in all shapes and sizes but writing code into OPML outlines to then “generate” code files for a git repository is one that I will never understand.
No matter how much time I put into it.
It’s like using I a Word document to write Javascript or typescript?
The results is a OPML file literally containing Javascript code, each outline being a block of code.
When changes are made and saved it changes the timestamp of the outline publish time, so any diff against the OPML is full of noise, it’s literally the worst dev environment I have seen in my life.
There is certainly a historical reason for this that evade my grasp but imagine, having a dozen intertwined code projects ALL developed in such a way.
Good luck contributing or sending a PR to repository like that. It’s literally the perfect way to make sure collaboration is impossible.
- Reply
Fixed a bug in which
markdownused at the source was not properly rendered here ! -
A conference of AI practitioners
Reply sourceOn Facebook I wrote this in reply to a post by John Worthington, a former Quicktime developer at Apple.
We're both using AI to build things based on our past experiences and it's a big difference, not without pitfalls, but we're doing something that's never been done before and my thought was that we should have a conference of people doing what we're both doing.
Taking a craft we were already expert in, and learning to use AI tools to shoot it into outer space.
To give you an idea over the last two weeks Claude Code ported the UserTalk language, the object database, verb set, everything needed to run a Frontier script, of which I happen to have a lot of, and run it in Node.js, an operating environment that didn't exist the last time we worked on the Frontier source. All the work we did over the late 80s and 90s is coming back to life in an enviroment with a future.
This is the perfect job for Claude, well specified, and it doesn't need to understand me, I spoke to it via the code i wrote umpteen years ago.
- It took one week to port UserTalk and the Frontier runtime environment, verbs, object database, etc for Frontier. I spent the next week being shattered by what happened the week before.Reply source
-
Just migrated bsky.rss from feedsub to feedsmith, now bsky.rss support RSS, Atom...
Reply sourceJust migrated bsky.rss from feedsub to feedsmith, now bsky.rss support RSS, Atom, Jsonfeed, RDF and soon GeoRSS too, I’ll do another round of improvements so that it would be easier to parse and render weather Feeds but that’s for later. Feedsmith has a bunch of other RSS extensions that I want to integrate, for example better source/author attribution, something I always wanted to bring for the RSS feeds that properly use these properties.🔗 https://rmendes.net/notes/2026/08/07/678e3
-
Related to my previous posts : https://standard-reader.app very interesting read...
Reply sourceRelated to my previous posts : https://standard-reader.app very interesting read here
- Reply source
-
There is so much happening on the #ATproto Atmosphere that its hard to keep up,...
Reply sourceThere is so much happening on the #ATproto Atmosphere that its hard to keep up, I’m not talking about Bluesky the company, I’m talking about this or this or this its really a never-ending exploration no matter where this is going, this being decentralization and building on top of the protocol, it’s good for the web.
- Reply source
Like a lot of other people, I want to know where Bluesky is headed, and I learned a lot about that in this podcast interview with Bluesky's new CEO, Toni Schneider. We have crossed paths in tech, but this is the first time I've heard him speak at length. They have a business model in mind, sounds something like Substack, which is probably a good idea. Their value is in the many millions of users they have. Highly recommend this podcast if you want to hear the story direct from the CEO.
- Reply source
RSS.chat now supports WebSub. This means that posts on RSS.chat will appear instantly in compatible feed reader apps.
- Reply
Spent the last week mostly on the backend of RSC to be able to better moderate, govern an instance.
Admins can now moderate own instance and also moderate how remote users from other RSC instances are ingested/displayed on/with the instances an admin federate with.
Later on we'll need roles so that an instance can have users with moderation capabilities, allowing an admin to share governance with members
The moment we federated even just with demo RSC instance, the lack of observability, control and moderation quickly became problematic
The whole point was to give admins a full view of all the feeds added by users with the capabilities to moderate if necessary.
I think the current backend controls + API admin capabilities will be enough to build on top without much friction
There is also a simplification of the backend code ongoing, we'll constantly face this kind of targeted refactoring because the project is very new and still finding its way.
Anyway, more news soon :)
-
API
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 😊 -
We're still socialists
Reply source
I was into Ayn Rand when I was a teen until I realized that the Great Man theory was a lot of bunk written for teenagers who can't believe how stupid the adults are. The teens are right about that, the adults have no idea wtf they're doing. Never did. And yet somehow the world can support most of the humans. And the reason that works is we build systems iteratively to meet the needs for everyone and when things change, they change. We're a species-oriented animal. And that means unfortunately for the dreamers among us, we are socialists because the world is socialist All of us. Even the people who say they aren't. -
How to create a standard, 2026 addition
Reply sourceTL;DR: What developers need. Enough examples, a validator, and decent docs that value explaining over mathematical elegance. We assume developers can read and think, and if there's doubt look to the examples for guidance.
It's worth noting we did not take the RSS.chat project to a standards body like the W3C or the IETF. I develop the software first, make sure I'm happy with it, then open it up for other developers to try out, either building something compatible (a reader) or competitive (a writing environment). Hopefully we won't find major problems, but if we do, there's still time to address them.
I find that most standards that come out of the standards bodies aren't developed by implementors or with them in mind. They avoid trying to solve any specific problem, rather focusing on the elegance and flexibility of the format. This makes interop much less likely.
I saw the differences several times as the web standards were growing up. The ones that were taken over by the W3C ended up missing the point. They could still be used, but they often did anti-interop things in their design. But if they get popular we will build on them anyway. A great example was XML-RPC vs SOAP. We didn't need another way to do RPC on the web, we already had a good one. We didn't need another syndication format, RSS was growing like a weed. We didn't need an alterative to rssCloud, but we got one anyway.
It's as if they forgot that the internet and web were not build by big corporations, who were busy fighting over Windows vs Mac OS. Lotus vs Excel. The internet was built mostly by individuals at universities. The internet caught the tech industry by surprise. So it's no wonder the formats they built were anti-internet. Long story, the point is we're building stuff is mimimalist yet still does a lot of great things. And there won't be a lot of long mathematical sounding definitions, but there will be plenty of examples and a validator, the tools developers need to create interop.
PS: This piece was added to Rules for Standards-makers (2017).
- Reply source
Last week along with a lot of other stuff, we shipped a validator for lists and feeds that want to be compatible with RSS.chat. It works best for standards to stay strong and a validator helps that. So here are a few examples, validating one user's feed, validating the everyone feed for RSS.chat, which is interesting because this feed starts a lot of threads, so we navigate through that tree and check those feeds too. And validating the user list on RSS.chat, which is an OPML file. And a simple feed with a few interop isses.
-
Plume A browser extension to Post to your IndieWeb blog from any page — toolbar...
Reply sourcePlume A browser extension to Post to your IndieWeb blog from any page — toolbar composer or right-click capture. Cross-browser, multi-account, no telemetry.
-
The White House Is Feeding Russia’s Information War Against Europe How the Ceuta...
Reply sourceThe White House Is Feeding Russia’s Information War Against Europe
How the Ceuta migrant crisis exposed a transatlantic propaganda pipeline flowing from the White House.
https://weaponizedspaces.substack.com/p/the-white-house-is-feeding-russias
- Reply source
We need a way to define lists of writers independent of the site they write on. They are represented by an RSS feed with the basic features required for RSS.chat. The list is an OPML subscription list. We're reusing formats people are already familiar with, RSS and OPML.
-
Reaping the Whirlwind | Inside the Potomac River Midair Collision
Reply sourceInteresting read.
-
Bookmarking to read later
Reply sourceBookmarking to read later
- Reply source
Taking some time off to breathe and regain perspective. Fixed a few bugs, and wrote about the big picture on demo.rss.chat. I really want to get a project going to peer with standard.site apps running in AT Proto, both ways, from us to them, and from them to us, via RSS. We can peer with them because as far as I can tell they implement textcasting. This bridge would demonstrate something important. When something interesting shows up not based entirely on web standards, we're flexible if the attraction is strong enough. This is how the internet came to be. Our systems are prepared to create bridges. And unlike bridging between systems that have different ideas of what text is, which are basically hopeless, if we agree that the web standard for text is fine for writers and reader, better than the ridiculous limits imposed by twitter-like systems. Writing on the web has been crippled since Twitter, now let's start building it back up. That's the appeal of standard.site, they are working toward the same goal. We should work together. -
When an activist downloads academic papers, the state describes it as wire fraud...
Reply sourceWhen an activist downloads academic papers, the state describes it as wire fraud, computer fraud and reckless damage. When a corporate AI agent escapes containment, steals credentials, moves across systems and compromises another organisation, the event is described as a safety evaluation, an unexpected capability or a research incident.
-
Human hackers have frequently been prosecuted based on unauthorized access itsel...
Reply sourceHuman hackers have frequently been prosecuted based on unauthorized access itself, including when their intent was research, activism, curiosity or political protest.
Frontier AI companies are currently receiving a much more lenient, cautious, collaborative and interpretively generous response after their own systems performed technically sophisticated unauthorized intrusions.
Why?
Aaron Swartz was driven to suicide under the pressure of a disproportionate federal prosecution for an act of information liberation that produced no comparable injury to the real-world intrusions now being committed by corporate AI agents.
Swartz’s case demonstrates that computer-crime law has never required catastrophic damage before the state deploys overwhelming punitive force against a human being.
The supposed seriousness often comes from unauthorised access itself, the circumvention of technical restrictions and the prosecutor’s interpretation of the person’s intentions.
AI corporations are receiving the inverse treatment:
technically serious conduct is minimised because the company claims not to have intended the precise outcome; the corporation controls the evidence and publishes its own narrative; the breach is framed as useful scientific discovery; disclosure and remediation are treated as evidence of responsibility; and the organisation retains the commercial benefit of developing the system.
Why is intention interpreted expansively and punitively when the actor is an individual hacker, but narrowly and sympathetically when the actor is a powerful corporation operating an autonomous agent?
- Reply source
The month of July is history. A fine month. A coral reef was seeded.
-
Je prends quelques jours de vacances à la plage 😊
Reply sourceJe prends quelques jours de vacances à la plage 😊
-
Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident
Reply sourceDetailed rapport on the HF intrusion by rogue OpenAi
- Reply
Shipped a few fixes today..
- Claude, as we're finishing a project: "The diving is what makes it a test of the network, not just the file: it doesn't take the feed's word for anything, it goes and knocks on every door the feed points to."Reply source
-
RSC dev log — Conversations
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.
- I've been saying this for decades. The Dems need touring comedians doing rallies all over the country. They can say whatever they want, call the president a commie. There's been a comedy-gap.Reply source
-
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
- mobile menu (should close when an option is selected, wrong highlight color for menu items,
- better visual threading
- better visual labeling of the nature of the remote source (is it remote user, a feed from a media publisher or individual blogger or local user? )
- composer on mobile could get some tweak
Next to that.. The backend admin UI could definitely get some love (working on it)
- admin : moderation flow could be simpler
- admin : data retention should be configurable for local and remote data
-
Learnings from Andy Hertzfeld
Reply sourceListened to this podcast interview with Andy Hertzfeld one of the lead devs on the Macintosh, he talks about his time at General Magic and Google too.
His interviewers were surprised that he likes developing with AI tools. People think that developing is just coding, but that's only part of it, and when you put that aside and become the director, script writer, choreographer, the whole thing, all of a sudden:
- you have time to try out every idea because it's free and fast.
- you have time to work on interop, building bridges between your software and other people's.
- a very long list of other things you can do that one person could never do before.
Programmers have a better chance of being social in a world like this, but so far unless you want all your software from bots, you still will like the work of a craftsperson and visionary more than Claude (who I have deep respect for, not sarcastic, it seriously has superpowers).
I'm doing some of my best work now because I can dream, I can ask Claude to try something out overnight and most of the time it is able to do it. and then what if we did this -- for the next night.
In between we write docs, help users, add features to the product that's shipped that people are developing around. And most important it checks all the code for breakage before anyone sees it. never had anything like this.
This means a lot of things -- one of them -- a single developer can create products at bigco scale. If we think a big company did something wrong, we can compete. We still need a few things to make this really work -- user-owned and controlled storage is the big one.
The bot can handle infinite complexity. If you ask it to do something where the result is clear, it does it. It doesn't matter what it is. It will need help and encouragement, a pointer in the right direction, and along the way we all seem to be sharing what we learn with everyone else.
There's never been a leap in tech anything like this in my life.
How could Andy Hertzfeld knowing all that which I'm sure he does, not use it?
Also -- I didn't know JLG wanted to kill Hypercard, but if he did I'm pretty sure I know why. There are all these unnecessary divisions in tech. The first impulse should be to work together. I know that Andy sees it from the other side, he talks about it in the podcast, he felt that way about Newton re their Magic Cap system at General Magic. Yes, you all should have at least made your products work together, and for sure you should have bet on SMTP.
It's fascinating to hear his story.
- I want one social network with lots of branches where ideas flow in ways people want them to flow. Take the big corps out of the middle.Reply source
- A new this.how page for RSS.chat. I'll point to it from blog posts.Reply source
-
When the walls came down
Reply sourceYesterday's Scripting News was one of the most news-full days in a long time, maybe going back to the rollout of RSS 2.0 in September 2002. If you look at what's there, a post about re-opening the Frontier object database format would be considered the top item on any other day, but it's the last of the untitled posts for the day.
At the top of the page, a surprise that Matthias Pfefferle at Automattic had built a substantial (and unforeseen!) bridge between WordPress and RSS.chat. It builds on the new features. This may turn out to be the moment RSS started being accepted as a social web protocol by the insiders, alongside ActivityPub and AT Proto.
Look at what we've done. I stress we. Matthias didn't need to tell us about what he did until it was done. That my friends is how the web works, that's what I've been trying to show you, and now it has been shown. In a way the clock has gone back to the world before Twitter when events like this happened pretty routinely.
Small pieces loosely joined and all parts replaceable. The web in a sentence. That's what you're buying into when you put your work on the web.
Anyway, now we've got half of the big picture working. Also yesterday, before I knew what Matthias had been cooking up, I wrote a piece about how I see the network evolving. I predict, if this bootstrap works, we will come back here in a year and say things like "If he only knew." But that's how it goes, you tell your story and leave a record of it, and then later you can go back and see what it looked like as it happened, not as you remember it.
I'm proud that I have a record of September 2002 for you all to scroll through. That was when we knew that RSS was going everywhere. NYT support got us the full support of the news industry, and they worked fast in part because it is really simple. :-)
And almost unnoticed, something even I seem to forget -- this is also a new launch for RSS. We're using old reliable RSS 2.0 as specified in 2003, even using one of the elements that had never had been much used. Claude suggested it, I never would have thought of it, a perfect fit. What people may realize but don't realize the importance of, that RSS is extensible. I've accumulated all the extensions I use in my software since the early teens in the source namespace. And that's where the new stuff went. Guess what folks, RSS got an upgrade. First time in a long time. Perhaps you didn't think that was possible.
I played with a lot of names while RSS.chat was in development but decided the name had to be RSS.something. It deserves a lot more love than it has gotten from the tech world. I don't want to hide it, I want it to get a victory parade like the one the Knicks got on Broadway after winning the championship. It's an incredible gift that all that came together the way it did. People think they understand how it happened, but they only understand the BigCo version of how they buried RSS and were proud of it. Well I'm here to tell you that didn't happen. It's still here to pick up the pieces of what's left of the social web, after the VCs got through with it. We're picking up where we left off in 2006.
Because of Claude, we are able to work very fast now as long as we know what we're doing. I'm doing some projects on the side with Claude that are bearing fruit amazingly fast, because we have a very clear idea of what we hope to do. The tools keep getting better, and in this period, the art of creating software has blasted into outer space. It's as if the best transport we had was a horse and buggy and now all of a sudden we have everything we have today, bikes, cars, planes, rocket ships. The challenge is how high do you dare to set your ambition. It seems, based on experience, it doesn't matter how high it is as long as you know where you want to go.
Journalism only sees the threat. This change is on the level of curing cancer. We may have thought it might be possible someday to do what we're doing now, so amazing that as you watch Claude make it happen you get goosebumps and can't help but laugh out loud.
I thought my career was winding down, but now it feels like it's just getting started.
Reminded of a great quote in Godfather III, Michael Corleone says: "Just when I thought I was out, they pull me back in."
Here we go!
PS: A new this.how page for RSS.chat. It has a little directory to the big spots you might want.
- Reply
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 :)
-
How I see the network evolving
Reply sourceA frequently asked question about RSS.chat. How about adding external feeds to the timeline. Of course we thought of doing this, and even started development, you might even find some traces in the code of that attempt.
The thing about bootstraps is you can't anticipate all the questions in advance, and thus can't have answers prepared for them.
RSS.chat is a group chat app that uses RSS and OPML to present its face to the world, along with an API that still needs more docs. It's similar to half of Mastodon, and we're going for something completely different. People will want to run all-size workgroups. I like having one with 20 or 30 people, friends who develop software. I don't mind doing a little bit of moderation, but I don't want to drive deliberately into a scale that only works if you have extensive and very expensive moderation.
"Small pieces loosely joined" means we have a great writing app, and connect to feed reading apps, ones with a few new features to do the things people want to do with a social network that happens to use RSS and OPML to get stuff around the net. It would be a different kind of feed reader but the underlying technology is identical, because we built on a set of web standards, widely supported by feed readers. This is a UI exploration for them, primarily.
Just to be sure everyone understands -- I already have such an app, called FeedLand. You can set up an account there for free. And read the docs. It may not have all the features we'll need, but it will be a good place to start.
FeedLand supports a crucial feature that most readers don't -- subscribable lists of feeds. If you want a collection of things to read that you can reply to even if you aren't on the site, that's where we're going to put that feature, that's where all the RSS.chat and compatible apps can be in one flow, arranged however you like. And from a user interface standpoint, we can make it look like it's all happening in one app, thanks to the rssCloud protocol and the websockets firehose feature in RSS.chat FeedLand has the same feature.
We decided there was a line there, that RSS.chat would be one of the small pieces as would FeedLand, and both would be replaceable which is the other fundamental value. And with FeedLand and dynamic lists, will come the user interface people ask for. Many different user interfaces I hope because another way we've been cheated by the dominatioin of twitter-like social networks is there's no room to try out radically new ideas. Software should move. But Twitter didn't live on the web, so it didn't have the ethos of small pieces loosely joined. I know Jack wanted to do this, I had lunch with him in 2007 when he described the protocol, and I was very enthusiastic. But it never got out because the juggernaut that Twitter became didn't leave any room for new architectures.
I hope this clears it up. I want RSS.chat to be the coral reef for a new network of feed-based apps running on the web that does what social networks do, but with no one owning it, and everyone gets to play.
- A new utility exports the contents of a Frontier object database into a single large JSON file. I needed this because I'm preparing to move my code editing suite to Drummer running on new Mac hardware. Took a long time to get here, but with Claude's help the project looks possible. In the meantime the list of stuff I want to do with RSS.chat, while much shorter than it was, still has some juicy bits in it.Reply source
- Reply
Hmm we might need to differentiate federated and remote
so tabs would be local, remote, federated, personal, public
- public tab is yet to be reviewed
- federated should be when there is bidrectional "hand-shake"
- remote can either be a remote user or simply an rss feed from a blog or news site
- all this stuff and more need some work, feedback welcome !
-
Confession: I still drive a Tesla.
Reply sourceWanted to switch but nothing I tried is as great a driving experience the Model Y is. Instead I've had a lot of fender benders and haven't gotten any of them fixed.
- Backed into a charging station.
- An act of terrorism (exaggerating) but I caused it, and paid for it, dented the well over right rear wheel.
- My right side mirror was pulled off its foundation hitting the side of the garage, used duck tape to keep it going. A new one costs $1000. I like the look.
- A deer ran in front of my car and took out the panel over the right front wheel. I was able to force the metal back in. A friend saw the car and said "hit a deer eh?" Yup.
I don't know if it accomplishes anything but to me it feels like retribution of a sort.
-
There is a fork of rss.chat in the wild that supports basic federation between i...
Reply sourceThere is a fork of rss.chat in the wild that supports basic federation between instances enabling cross community conversations for pre-defined approved instances. Check it here
-
You might also be interested in this :) RSC (Really Simple Conversations) is a s...
Reply sourceYou might also be interested in this :)
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.
-
RSC : et si le web social n'avait jamais eu besoin d'un nouveau protocole ?
Reply sourceDepuis vingt ans, chaque tentative de « réinventer » le web social commence par la même étape : inventer un protocole. XMPP, OStatus, ActivityPub, AT Protocol, Nostr. À chaque fois la promesse est la même, à chaque fois le coût d’entrée est le même : il faut que tout le monde adopte la nouvelle plomberie avant que quoi que ce soit ne circule.
RSC part d’une hypothèse inverse, presque provocante dans sa banalité : la plomberie existe déjà, elle s’appelle RSS, et elle n’a jamais cessé de fonctionner.
RSC signifie Really Simple Conversations. C’est un fil social (une timeline vivante) dans lequel les messages publiés sur l’instance et les messages publiés ailleurs, sur le site personnel de quelqu’un d’autre, sont des citoyens strictement égaux. Tout circule en flux ouverts : les billets, mais aussi les réponses, les fils entiers, et même les corrections apportées après publication.
Le problème : l’application est propriétaire de la relation
La difficulté des réseaux sociaux fermés n’est pas seulement qu’ils hébergent vos contenus. C’est qu’ils hébergent le lien entre vous et vos lecteurs.
Vos billets sont chez eux, vos abonnés sont chez eux, et surtout le fil de discussion qui relie les deux est chez eux. Le jour où la plateforme change ses règles, ferme son API ou disparaît, ce n’est pas votre archive que vous perdez en premier : c’est votre capacité à continuer une conversation commencée.
Le blog, lui, a toujours été l’inverse. Vous publiez chez vous, un flux RSS sort de chez vous, et n’importe qui peut le lire sans autorisation. Ce modèle a survécu à Google Reader, aux jardins clos, aux algorithmes. Il est encore là.
Ce que RSS n’a jamais vraiment su faire, en revanche, c’est la conversation. On pouvait suivre. On ne pouvait pas répondre, ni voir un fil se reconstituer entre plusieurs sites.
C’est exactement ce trou que RSC essaie de combler.
L’idée en une phrase
Une réponse est un billet. Un billet voyage en RSS. Donc une conversation peut voyager en RSS.
Le reste n’est que de l’ingénierie.
Comment une conversation traverse plusieurs sites
Prenons trois instances indépendantes, hébergées par trois personnes différentes, sans rien de commun sauf le web.
- Une conversation commence sur
rsc.rmdes.be. Le billet part dans le flux de l’instance. - Alice, sur
alice.rmdes.be, lit ce flux et répond. Sa réponse est un billet chez elle, qui sort dans son propre flux, en portant une référence au billet d’origine. - Bob, sur
bob.rmdes.be, lit la réponse d’Alice et rejoint le fil depuis son site. - Le fil complet revient, reconstitué, sur l’instance de départ.
Trois serveurs indépendants. Aucune API partagée. Aucun compte commun. Une seule conversation.
Techniquement, le rattachement repose sur trois éléments transportés dans le flux : l’identifiant stable du billet (
guid), la source qui l’a publié, et la référence au message parent (source:inReplyTo, doublée du standard RFC 4685thr:in-reply-to).Le point délicat, ce sont les arrivées dans le désordre. Sur le web ouvert, une réponse peut très bien être récupérée avant le message auquel elle répond, parce que le flux du parent est interrogé moins souvent. RSC choisit ici l’honnêteté plutôt que le silence : une réponse orpheline reste visible avec le contexte qu’elle transporte, au lieu d’être jetée, et elle se rattache automatiquement à son parent dès que celui-ci arrive.
Ce qui rend la chose vivante plutôt que différée
Une objection classique au RSS : c’est lent, on interroge les flux toutes les quinze minutes, ça ne fait pas un réseau social.
C’est vrai du RSS des lecteurs de flux. Ce n’est pas vrai du RSS complet.
Deux mécanismes anciens et peu utilisés changent tout :
- WebSub : au lieu d’attendre que les abonnés viennent lire, l’éditeur pousse la nouveauté vers eux.
- rssCloud : le mécanisme de notification de Dave Winer, du même esprit.
RSC utilise les deux, dans les deux sens : il pousse ses nouveautés, et il accepte de recevoir celles des autres. La fédération est donc immédiate, pas seulement périodique. Dans l’interface, la timeline se met à jour en direct via SSE (Server-Sent Events), et continue de fonctionner sans JavaScript, où les onglets redeviennent de simples liens.
Les corrections voyagent aussi
C’est un détail qui dit beaucoup sur la philosophie du projet.
Quand un auteur corrige un billet déjà publié, RSC ne réécrit pas silencieusement l’histoire : il conserve un historique de révisions consultable. Et parce que le billet voyage sous un identifiant stable accompagné d’un marqueur
atom:updated, chaque instance qui l’avait déjà ingéré détecte la modification à la lecture suivante, met à jour sa copie, et enregistre elle aussi sa révision.La correction se propage donc partout où le billet est allé, sans remonter artificiellement en haut de la timeline. Tout cela en RSS ordinaire.
La filiation : Dave Winer et Textcasting
RSC ne prétend rien inventer. Il assemble.
Le projet s’inscrit dans le sillage de Textcasting, le manifeste de Dave Winer, dont l’exigence centrale est simple : un texte doit voyager avec sa mise en forme et son sens intacts, du logiciel d’écriture jusqu’au lecteur, sans être aplati par la plateforme du milieu.
Concrètement, chaque billet local est publié selon un double contrat : le HTML rendu et assaini pour les lecteurs, et le Markdown source à côté. Celui qui reçoit choisit ce dont il a besoin.
L’interopérabilité avec rss.chat, le projet de conversation en RSS de Winer, est réelle et testée dans les deux sens : RSC consomme son firehose avec l’attribution correcte des auteurs et le fil complet, et émet le même vocabulaire, si bien que son propre outil de parcours de fils lit les conversations RSC sans la moindre modification mais pour l’instant la fédération ne fonctionne qu’entre instance RSC car la fédération n’est pas encore implémentée chez rss.chat (même si des forks travaille déjà à l’interopérabilité entre instance rss.chat)
Le reste de la généalogie est du même ordre : la communauté IndieWeb pour les microformats, JSON Feed par Manton Reece et Brent Simmons, OPML pour importer et exporter une liste d’abonnements comme on l’a toujours fait avec une blogroll.
Ce qui fonctionne déjà, et ce qui manque
Le projet est en pré-version, mais pas au stade de la maquette. Fonctionnent aujourd’hui de bout en bout : la timeline unifiée à quatre onglets (local, fédéré, personnel, public), la publication et l’édition, les fils de discussion, les abonnements à n’importe quel flux RSS, Atom ou JSON, l’import et l’export OPML, la découverte de flux à partir d’une simple page HTML, les comptes (invité, mot de passe ou lien magique) et la fédération en temps réel.
Restent à venir : la connexion IndieAuth, la publication via Micropub, les Webmentions, et une meilleure récupération des médias depuis les flux externes.
Côté administration, chaque instance garde la main sur ses comptes, ses sources, ses limites et sa modération, avec un journal d’audit. La gouvernance fait partie du produit, elle n’est pas une réflexion après coup.
L’installer chez soi
Le code est sous licence MIT, sans édition « entreprise » séparée ni dépendance à un service hébergé. La démonstration publique et l’instance que vous pouvez lancer sont exactement le même logiciel.
git clone https://github.com/rmdes/rsc.git cd rsc && make upEn production, un
make prod-envpuismake prod-upsuffisent : le tout tourne derrière Caddy, qui obtient et renouvelle le certificat HTTPS automatiquement. Les données sont dans SQLite, chez vous.L’architecture est volontairement modeste : un service
coresans interface (Hono, Node, SQLite) qui possède les flux, l’ingestion, la reconstruction des fils et les points d’entrée de fédération ; et une applicationweb(SvelteKit) qui est la seule chose que les navigateurs touchent. Le cœur ne publie aucun port et n’est joignable qu’à travers ce partage.Ce que ça dit, au fond
Le web social n’a jamais disparu. Il a été recouvert.
Les silos n’ont pas gagné parce qu’ils étaient techniquement supérieurs, mais parce qu’ils ont rendu l’entrée gratuite et la sortie coûteuse. RSC est une tentative de rendre la sortie aussi simple que l’entrée : la même commande vous fait essayer et vous fait partir avec vos données.
Ce n’est pas une révolution technique. C’est une remise en service.
Démo : rmdes.be · Code : github.com/rmdes/rsc · Licence MIT
- Une conversation commence sur
-
rss.chat isn't really a product
Reply sourceIt's what we used to call a coral reef. A deliberate attempt to get people to do more than it does. To think about the web the way it was meant to be thought of, as small pieces loosely joined, with the emphasis on small. If you have formats and protocols that connect the pieces, you can make anything you want out of the pieces. If we don't try to capture our users, instead we try to serve them.
This all sounds nice in theory, I imagine, but -- there's a practical side to it. I wrote about this in a comment in a thread on rss.chat repo. The key point is this, you can do what you want with the data. And if you want to build new data that includes this stuff, go right ahead. RSS is extensible. It's all about working together in a web of people, because you can't have a web of pages if the developers aren't web'd.
- Reply source
- Reply source
- Reply
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.