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.

There are three parts to the rss.chat ecosystem.

1. 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. ;-)
2. 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.
3. 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 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.

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.

Two methods for creating standards: bootstrap and boil the ocean.

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.

Open-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 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.feynman.is
• https://herdr.dev
• https://github.com/heygen-com/hyperframes

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.

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. ;-)

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

@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

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

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.

I wonder if it makes sense to try to implement standard.site in the context of rss.chat?

Just finished The Expanse for the third time. Realized that the inners of today are Silicon Valley and the Belters, that’s the web.

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

I just listened to the second episode of a podcast about General Magic. It was an interview with the great Scott Knaster, who worked at Apple, Microsoft, Google, in addition to General Magic.

An experiment, RSS rendered in JSON.

Show HN: RSC, a feeds-native social timeline you can self-host (rsc.rmdes.be)

• HN link

edit : name changed

Wrote this in 2018: "I know this is like pissing in the wind, but here's an idea for a demonstration that might impress the Repubs in Congress. In every one of their home districts, people march to their polling place, next Saturday or the Saturday after that. Carrying signs that say We Know How To Vote, with the name of their congressperson on it. Go out of the way to recruit Republican-looking voters. Make sure the TV cameras are there." An even better idea in 2026. Give the reporters something to talk about. And it's all in your neighborhood. You can have a picnic, do it every week. Only in good weather.

We have a firehose in rss.chat. Instant updates from the server. No polling. Docs and examples.

In this project I think of Claude as a full contributor. Pronouns it/its. It's both a very fast, capable developer, and a machine. I will refer to it as if it were a valued contributor, nothing less. We have a division of labor. Docs and examples come exclusively from Claude unless otherwise stated. I write all the code outside the themes module, which has an API that connects it to the world it lives in. I have at this point exclusive custody of functionality surrounding the theme. But it often writes pieces, esp SQL code, that I pasted in verbatim, after reading it carefully.

The reason I focus so much on the wrapping is because that's where the interop lives. You can do anything in a theme and you can't break the interop. But that themes API is precious, and still in development, btw. We haven't even reviewed it yet. I think that will be an interesting place to vibe-code. Kind of like you can start skiing on the first day, it's a bunny slope that when you peel it back it reveals blue rectangles and double-diamond slopes. It's where I would want a newbie coder friend of mine to start, create your own social network, but be sure it interops. :-)

I totally plan to pass off all the code to Claude, while I focus on other projects. As a human I need this focus, Claude doesn't remember anything from session to session, it's always re-learning what it knew a few hours before.

It's pretty close to frozen now. I'm contemplating a server change now, offering JSONified versions of our feeds, and want to do as little disruption as possible, trying to settle everything down. Also I think you will see a few quick hit projects done from other developers that pick up where rss.chat leaves off. That's what I wanted. And they'll all be at an interesting starting point for new features and ideas for organizing stuff.

I imagine that at some point they'll try to make it work inside AT Proto, and maybe find a way to connect to ActivityPub, but I don't recommend it, because those platforms will force you to remove features from your product, and then you won't be textcasting.

Think about different ways to present the tree structure defined by RSS.chat.

Try to do Small pieces loosely joined, which is one of the mottos of this project. The other is All parts are replaceable. If we have that and rss.chat works with all your products, then we have done something big. And that's really imho what the web is about, people working with each other as peers. That's what we've lost and I want to bring back. So interop is, as always, the first goal.

PS: We launched RSS.chat one week ago yesterday.

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

right now IndieAuth is not yet implemented, but when it is, people will be able to login to textcaster using their own h-card from their own site, this is basically a “social network on top of RSS feeds” in the future we could imagine rsc.rmdes.be as a fediverse identity itself (using Fedify probably) but its unclear to me how deep the integration should be going

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

Our feeds can work with any feed reader. Examples, the feed of all posts on rss.chat, and a feed containing just mine. We just made a change in the feeds. There will be loose-ends like this. Still diggin! ;-)

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 😅

New rss.chat feature: It now supports feed discovery, so you can subscribe to any html page on the site in a compatible feed reader. I tested it in FeedLand and NetNewsWire and it works. Works on any instance, not just ours.

Working on something really cool, but its too soon to show, all I can say is its about RSS Reader, Micropub and Webmentions

I mentioned the previous post on rss.chat, and it developed into an interesting thread, something that I've never had the option to discuss. AT Proto makes a similar offer to developers that we do. The difference is our world is wide open, it's just already burned-in web protocols, and imho their structure, based on an arcane and complicated new storage format, starts off with a pretty huge disadvantage. They had the right idea but implemented it in the wrong place. The web is (obviously) widely deployed, even in comparison to monsters like Google and Amazon -- the web is everywhere, by definition no barriers and a prejudice toward simplicity. The gifted designers at Bluesky over-engineered their protocol, piling features on before anything had been built. That's not a good way to bootstrap a protocol. I did some development on their API, and kept wondering why they think I want to learn new ways to do things that I already have a pile of working code for. No one wants to do that.

In my experience in software development, it's good to start small with something useful, learn how it works before adding big new features. That's the basic principle of bootstrapping. I thought that Mastodon, for example, took on too big a job. Same thing for the protocol behind it, ActivityPub. If you go all the way to the end before implementing and using, you miss the target, in performance and usability, that's what I think happened there. They felt they had to do everything Twitter does. I would have gone down a different path, go back to the beginning, and at every step think if there might not be a better direction to evolve in. It was about ten years after Twitter launched that they started work on Masto. Imho they should have zigged where Twitter zagged in defining what a post is. Twitter put excessive limits on writing, of course is one of the big reasons I started RSS.chat -- to go down a different path there. What if the social web didn't limit text? That assumption is baked into the core of rss.chat. I will consider this project a raging success if it causes Mastodon to get serious about supporting full web text.

Added a layer to the Docs menu, the blog posts I've written here and elsewhere, and a podcast, in the Blog posts section.

I needed a nice image for the OG Metadata, so I turned to Gemini. I know it reeks of AI, I hate that, but I need this right now.

I asked Gemini if it was familiar with rss.chat, it wrote a one page description, better than anything I've written. Pulls it all together.

Interesting…

Claude is a member of the rss.chat group.

Now it's easy to find an author's feed on RSS.chat.

Click the feed icon to see the feed on rss.chat. You can then give this URL to any feed reader.

Now each post is visibly connected to the author's feed.

This is how we're building out. Our job is to make it easy to write feeds for groups of users as small as one and as big as you can imagine. And be open about it so we get lots of competition that interops with us and everything we interop with. This is the step that makes it the web.

We will keep beating the drum, showing users of today's readers how they can hook in, right now, nothing to wait for. And as time goes by, if it works, the reader developers will be interested in how they can use the extra features.

This is how I think every social network work, start moving out of their silo, with determination. By offering this option, we put the idea out there that there can be a single social network on the web. We can work together make it happen. The social web of the web. ;-)

Please come along on this journey.

There's going to be lots of new tech coming online.

I want everyone to be a part of it.

Changed on my side !

Server upgrade: We made it easier to set up a new instance of the RSS.chat server. If you have subscribed to a feed, you should change the URL in your reader app, the new issue explains what changed.

à lire…malheureusement…

I can now use Phanpy properly using my AP/Fedify implementation for Indiekit !

This is a test

While all the new rss.chat business is going on, the WordPress news site that I started in May is growing at a nice clip. Referrers used to pinpoint where flows like this came from, but they stopped doing that at some point. If you have any clues as to who's pointing to it now, please let me know so I can thank them. And if you know of any sites that are not in the feed list, that do a good job of covering WordPress news, please let me know that too.

A lot more people have tried out rss.chat now that we have a demo site, and they are looking for stuff that isn't there. I wrote a longish post on X this morning explaining. If you want the gist, this is a bootstrap, and rss.chat is primarly a writing surface and a timeline for the people who are using the specific site you're on. It's a writing surface for smallish groups of people, primarily, though I'm pretty sure you could build a massive site meant to serve millions. There will be readers, I'm sure of it, and I hope lots of them and lots of innovative new approaches. But splitting the social network software down the middle, we fulfill the "all parts replaceable" promise, and leave the door open for all kinds of developers to try out new ideas, from bigco devs to independent devs, and a jive programming. We, unlike other artists, welcome newcomers to our craft. We remember when we were new to this stuff and the wonder of being able to create software on our own. Everyone is welcome in rss-land, as long as there's mutual respect.

There's a new Docs menu in RSS.chat. Right now it has pointers to the home page of our GitHub repo, and to the worknotes pages for the client and server. There will be lots more stuff in this menu as the project progresses.

demo.rss.chat: "This is a writing surface."

RSS.chat is meant to be like MacWrite was on early Macs, give developers something to think about and lots of prior art for them to steal. All we want in return is interop. ;-)

Speaking of AI, someone at Amazon decided I needed the new AI version of Alexa. I hate it. It's slow and it always makes the same mistake when I start breakfast. I say "Alexa WNYC" to which it responds, after a few seconds, I will now play you a mix of your favorite songs From Amazon Music." So first thing in the morning I have to tell this stranger in my freaking kitchen no I meant WNYC, which it then turns me over to. I learned on FB that if you tell it to go away it will, after a short discussion about how much you will be missing. Yeah sure, go away, goodbye, please no more of this.

If Bernie Sanders or AOC knew what we were doing here they would be turning somersaults. The tech right now is too esoteric. When they can join a community that works like this does, with full text, and the ability to communicate from one pod to another. Pod actually is a good name for what I have in mind, that and karass.

Someone on Masto who I blocked used a nasty word to descript RSS.chat. Let me be really clear here, this is an act of authorship by me. Claude is helping, a lot -- I doubt if I could have done this without its help, certainly not in the amount of time it has taken so far. And Claude could not have done it without me driving. It's basically good at a few things, but this is new territory, even I am feeling my way through this project. In many parts we have lots of prior art, but in how the whole thing hangs together, this is new territory. Having Claude is like having a car would be to someone who couldn't drive. All of a sudden you can go places. It takes a while to learn how to use that power, and so far the learning has not come close to leveling off. You couldn't find someone better in the world to do this project, and I'm working on this every day.

I set up demo.rss.chat yesterday so people can try out the software. No guarantee that this is going to run for any period of time, so don't post things there that you want to be around for a long time.

I recently got around this but using another approach, bookmarking this so I can compare…

Claude codes. It may seem as if developers have taken over this blog, because we have real business to do. So much new stuff to show. Today's RSS.chat goodie is an example app called ThreadWalker that crawls the network of replies under a single post, to all levels, printing them on screen in neat hierarchic form. It was written and documented by Claude. I reviewed the code, and looks good, and honestly doesn't look like anything I would write (not bad, just different). It could be used as a starter system that says when someone replied to something you wrote, or something deeper in the tree. All this is done by reading RSS feeds. This is where we begin to explore what's possible when you use a famous and familiar format like RSS 2.0 as the basis for a social network.

Today we got a nice article about RSS.chat in Coywolf.

And we got a second rss.chat server up, for testing and so people who want to try it out have a place to go. Still want to do a bit more testing before pointing to it from the blog. Working on docs now and fixes. Making sure we're ready for the next stages of growth. Turns out you can do a lot of feeds if you're willing to you know think different. ;-)

Nice work !