That would quickly get abused and cartels would form over the larger servers about who has access and where.

I get the impression that every attempt to make block lists ends up getting used to target people an admin of the block list doesn't like. I think the root of it is that the admins consuming the blocklist don't want to have to spend time on moderation and are remote from communities where the blocklist is happening. Also the scope of the blocklist is the instance. Compare that to community internal moderation (e.g. channel mods), where someone close to the community is invested in the health of the community and the scope of the block is the relevant community.

If you tweet something controversial once and the wrong person sees it, they can automatically tag you as a nazi across half the fediverse

gestures broadly is going to be one of the common answers from anyone trying to ward off spam

Given that this system already uses DNS for namespacing of user identifiers (via instances), it seems like it could use DNS for namespacing of channels too

Because throwing UDP packets requires a bandwidth advantage (aside from reflection attacks), whereas application-layer attacks can impose an outsized cost on the victim.

Actually it’s a footgun gate

Online communities are meant to be pharmed..

Relearning the lessons from the old days, I see. This situation is what created the Eris-Free Network.

> Federated rooms continue to exist if a server drops off

That doesn't answer the question.

How are you resolving things like... user name collisions when the servers reconnect?

It's a copy paste of the readme intro. Don't know why it's left as a comment here

Yes, you will need to know someone running an instance to create an account for you.

IRC is good in that it is open, durable, and slow moving. All of those points are intentional features that make it a stable cockroach in a nuclear world.

I briefly entertained building a modern chat experience on top of IRC when I came to this realization.

>Unfortunately XMPP is an absolutely terrible protocol

Can you provide more details here? I've never seen an issue with the protocol at all, more issues with feature difference between servers depending on what they have decided to implement or not.

I once implemented the presence and basic messaging functionality of XMPP for a web site, using a braindead bridge (that I also wrote; so, the meaningful logic lived in the browser).

Considering I'd never hosted an XMPP daemon and didn't know anything about the protocol (I'd used XMPP clients a little bit, but had never looked at the protocol) and got a server (that part, I didn't write), an auth connector for our website's authentication system (so the daemon would authenticate against that instead), prod-ready and the features I wanted all working smoothly and reliably in maybe three weeks of very part-time work (this'd be, like, 3-4 part-time days with LLMs now, tops, from the same starting point)... seems decent to me? I mean I did direct work with the protocol, didn't just glue together libraries, and it was pretty damn good. Also (and I know browsers seem to be retreating on this front, which sucks) being XML made it very nice to work with in a Web context, since you can just ask the browser to turn ~any XML into a DOM for you, and get a bunch of functionality for free.

What's wrong with it?

> I don't know how it just happens that sending text messages to people can manage to result in specs that are painful to implement.

This is what boggles my mind. We're talking: Text. Over the Internet. It should not be a complex, difficult problem! We've been sending text over the Internet from the moment the Internet went online. So how is it that 10 companies have managed to find 30 different ways to do it, which are all incompatible with each other? You have to TRY to fail this badly.

Why is it terrible?

You guys are way too critical and about the wrong things. "Waste of tokens"? Perhaps the author know of the tradeoffs and just wanted to build something.

How you went from seeing somebody's post to deciding they don't care is a pretty big jump, one that isn't warranted. This kind of post seems like the old but now more elaborated form of hating on something that you don't even know what it is.

It just isn't fair to the work that has been put in.

If telling people “build me an app” with no knowledge of technology worked, project managers would be good at their jobs already

That’s where we’d expect a mention in the README to play a part.

I'm not sure I agree. Seems to me to depend a lot on how one interacts with an LLM.

If you tell it to "build me an application X to do Y using programming language Z", it will comply.

If you interactively ask "I need X, can you suggest some options? use an existing product ? or build something using a library ? or build entirely myself ? can you suggest alternatives with pro's and con's ? Anything I should think of before deciding ?" then you will get an entirely different answer.

Maybe we need additional modes, aside from thinking mode, agentic mode etc. we need e.g. "sparring mode" ? or does such a thing already exist ?

Agreed, you have to ask them to look for prior work. But then they will do a good job finding it in most cases. I think it’s partly their universal tunnel vision and partly sycophancy.