Bookmarking to read later
When 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 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.
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?
Je prends quelques jours de vacances à la plage 😊
Detailed rapport on the HF intrusion by rogue OpenAi
There 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 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.
Depuis 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.
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.
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.
Prenons trois instances indépendantes, hébergées par trois personnes différentes, sans rien de commun sauf le web.
rsc.rmdes.be. Le billet part dans le flux de l’instance.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.rmdes.be, lit la réponse d’Alice et rejoint le fil depuis son site.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 4685 thr: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.
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 :
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.
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.
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.
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.
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-env puis make prod-up suffisent : 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 core sans 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 application web (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.
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
Interesting read as always !
I wish we had the full story here…this article is interesting but there is definitely something missing on what happened…
Not a fork… an implementation from scratch in the case of RSC :)
RSC — 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.
RSS 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.
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.
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.
Stumbled upon a few (local) #AI tools that made me really curious
Hmmm I wasn’t expecting THAT :)
Good 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
Show HN: RSC, a feeds-native social timeline you can self-host (rsc.rmdes.be)
edit : name changed
So this is a social network built on top of RSS feeds in very short, its also federated, bob.rmdes.be and alice.rmdes.be users can interact with RSC and the whole thing gets properly threaded in every instances
Well the cat is out of the bag : if you like #RSS and the idea of a social layer on top of the existing web without lockin, ads and algorithms try it : https://textcaster.app #Fediverse #ATproto #ActivityPub
Well the cat is out of the bag : if you like #RSS and the idea of a social layer on top of the existing web without lockin, ads and algorithms try it : https://rsc.rmdes.be #Fediverse #ATproto #ActivityPub
The technical aspect of Odyssey IMAX filming is in itself astounding work.
I had no idea it was this complex and old-school to produce an IMAX movie.
Makes me want to watch it again… In a IMAX screen this time 😅
Working on something really cool, but its too soon to show, all I can say is its about RSS Reader, Micropub and Webmentions
Interesting…
Changed on my side !
à lire…malheureusement…
I can now use Phanpy properly using my AP/Fedify implementation for Indiekit !
This is a test
I recently got around this but using another approach, bookmarking this so I can compare…
Nice work !
Interesting read I want to come back later
Gotta check this later… Cos the only reason I bought this Geekom IT15 was to run Ableton.
Now if I can do this on my framework 16 I’d jump on the occasion
Testing Phandroid via Obtainium/F-Droid
This post is published through my Micropub endpoint, which creates a new entry in MongoDB. Eleventy then retrieves that entry during the build process and generates a static version of the post.
Any reactions or replies should trigger a Webmention, which is then received and processed by my Indiekit site.
Interesting…
Il y a quelque chose d’absurde dans notre manière de répondre à l’urgence climatique.
À chaque nouvelle canicule, on nous parle de volets, d’isolation, de climatisation, de fontaines, de piscines publiques temporairement accessibles et de quelques arbres plantés au milieu du béton. Toutes ces mesures peuvent être utiles. Certaines sont même indispensables. Mais elles restent des rustines posées sur une machine que personne ne veut arrêter.
Le débat ne porte plus vraiment sur la manière de stopper le réchauffement climatique. Il porte sur la manière de continuer à vivre à l’intérieur.
On ne demande pas comment réduire radicalement la production de gaz à effet de serre, transformer nos modes de production, organiser la sobriété énergétique ou mettre fin à certaines activités manifestement incompatibles avec la stabilité du climat. On demande comment adapter les maisons, refroidir les bureaux et protéger les villes sans modifier les fondations économiques qui produisent le problème.
Autrement dit, nous ne sommes plus dans une politique de prévention. Nous entrons dans une politique de protection sélective.
Tout le monde ne pourra pas s’adapter de la même manière.
Les plus riches vivront dans des logements isolés et climatisés, entourés de végétation, équipés de panneaux solaires, de batteries et de systèmes automatisés capables de maintenir une température idéale. Ils pourront partir lorsque certaines régions deviendront trop chaudes, acheter l’accès à l’eau, à l’ombre, à la sécurité et à un air plus respirable.
Les autres subiront.
Ils vivront dans des appartements mal isolés, dans des quartiers minéralisés, près des routes, des industries et des infrastructures qui concentrent la chaleur. Ils travailleront dehors, dans les cuisines, les entrepôts, les maisons de repos, les transports ou sur les chantiers. Ils seront les premiers exposés aux coupures d’eau, à l’augmentation des prix alimentaires, aux maladies, aux déplacements forcés et à la destruction progressive des services publics.
La formule politique du futur semble déjà écrite :
Le changement climatique devient ainsi une nouvelle machine à fabriquer du privilège. La possibilité de s’en protéger devient un produit. La survie elle-même devient un marché.
Les plus fortunés fantasment déjà sur des bunkers, des propriétés isolées et des territoires autonomes. Ils imaginent des sous-sols dont ils pourraient contrôler la température, l’accès, l’énergie et la sécurité. Comme si l’on pouvait détruire les conditions collectives de la vie tout en achetant une petite capsule privée d’habitabilité.
Ce n’est pas une réponse au changement climatique. C’est l’abandon assumé de la société.
Le problème est encore plus profond, car le climat n’est pas le seul système soumis à l’inertie.
Le système climatique possède sa propre inertie. Une partie des conséquences de nos émissions actuelles continuera de se manifester pendant des décennies. Même une transformation immédiate ne ferait pas disparaître instantanément les dégâts déjà accumulés.
Mais nos systèmes économiques et politiques sont eux aussi gouvernés par l’inertie.
Les infrastructures ont été construites autour du pétrole, du gaz, de la voiture individuelle, du transport mondial de marchandises et de la consommation permanente. Les entreprises doivent protéger leurs investissements. Les États redoutent les réactions électorales. Les gouvernements repoussent les décisions difficiles. Les citoyens dépendent matériellement d’un modèle qu’ils peuvent intellectuellement désapprouver, mais dont il leur est presque impossible de sortir individuellement.
Personne ne tient nécessairement le volant. Pourtant, la machine continue d’avancer.
Cette inertie permet à chacun de reporter la responsabilité sur quelqu’un d’autre. Les gouvernements attendent les entreprises. Les entreprises attendent les consommateurs. Les consommateurs attendent des alternatives abordables. Les pays riches accusent les économies émergentes. Les économies émergentes rappellent, à juste titre, que les pays riches se sont développés en brûlant massivement des énergies fossiles.
Pendant que tout le monde explique pourquoi il ne peut pas agir le premier, la concentration de gaz à effet de serre continue d’augmenter.
À cette paralysie s’ajoute désormais la promesse de l’intelligence artificielle.
Les mêmes entreprises qui construisent des centres de données gigantesques, augmentent leurs besoins en énergie, en eau, en métaux et en infrastructures nous expliquent que l’intelligence artificielle trouvera les solutions au changement climatique.
Elle optimisera les réseaux électriques. Elle découvrira de nouveaux matériaux. Elle améliorera les prévisions. Elle rendra les bâtiments plus efficaces. Elle inventera peut-être une technologie miraculeuse capable de capter le carbone à grande échelle.
Certaines de ces innovations seront probablement utiles. Mais le problème apparaît lorsque l’innovation future devient une excuse pour ne pas réduire les dégâts présents.
Le progrès technologique n’est plus présenté comme un outil. Il devient un acte de foi.
Nous plaçons dans la balance, d’un côté, la viabilité connue de notre planète et, de l’autre, la promesse d’une technologie future dont nous ignorons encore les capacités réelles, les coûts et les effets secondaires. Nous parions que les machines de demain répareront ce que les machines d’aujourd’hui continuent de détruire.
C’est une forme de pensée magique, mais avec des centres de données.
Nous vivons à une époque où nous devrions réduire radicalement notre empreinte matérielle, mais où chaque nouvelle industrie prétend nécessiter davantage d’électricité, davantage d’eau, davantage de calcul et davantage de ressources. Et chaque augmentation est justifiée au nom d’un futur où la technologie nous permettra enfin de consommer sans conséquences.
Nous sommes peut-être déjà au-delà de Don’t Look Up.
Dans le film, la catastrophe est niée ou transformée en spectacle. Dans notre réalité, elle est reconnue, documentée, mesurée et commentée. Nous savons qu’elle arrive. Nous savons même qu’elle a déjà commencé. Mais cette connaissance n’entraîne pas nécessairement l’action.
Elle produit des applications météo, des cartes de chaleur, des recommandations sanitaires et des publicités pour des climatiseurs.
La catastrophe est intégrée au marché.
La véritable question climatique n’est donc plus seulement de savoir combien de degrés supplémentaires nous allons atteindre. Elle est de savoir quelle société nous construisons pour y répondre.
Une société fondée sur la solidarité, la transformation collective et le partage des ressources ?
Ou une société de triage, dans laquelle ceux qui possèdent suffisamment d’argent achètent leur protection tandis que les autres sont abandonnés à leur capacité individuelle d’adaptation ?
La question du climat n’est pas limité à la destruction des écosystèmes. Elle révèle la nature de nos choix politiques. Elle montre quelles vies nous sommes prêts à protéger, quelles activités nous refusons d’interrompre et quels sacrifices nous sommes disposés à imposer — généralement aux autres.
Il ne s’agit pas uniquement de sauver « l’espèce humaine », comme si l’humanité formait un bloc homogène. Il s’agit de préserver les conditions d’existence d’innombrables espèces, mais aussi de décider quels humains seront autorisés à vivre dignement dans un monde plus chaud.
La catastrophe climatique n’est pas seulement ce qui nous arrive.
Elle est aussi la société que nous choisissons de construire en réaction à ce qui nous arrive.