If this is really distributed, then off the top of my head I imagine you could possibly make some sort of reputation-based filter list wherein trusted admins can subscrbe to each other's filter lists such that when one admin blocks are user, it quickly propagates to other admins' lists. Somewhat similar to how email domain spam block lists work.

[seemingly negative thing] which is a decision (after hindsight), rather than a gap [scope creep]

Ownership of namespaces is such a hard problem, our society has had to form global organizations and some of our most secure distributed systems to make it happen.

Working in the p2p space, scalable namespace ownership that doesn't get instantly ruined by perverse incentives is the holy grail. I don't think it is actually tractable in any "central authority free" system. Don't get me started on blockchains that tether names to the most perverse systems available and call it victory.

> which have been a nightmare on mastodon

Why?

Why would they need to "create servers" instead of just throwing UDP packets at you like a normal DDOS?

That sounds pretty load-bearing.

Temporarily delete messages from unknown servers.

And then, all galaxies move away from us.

This is why we can no longer have nice things...

Bans are per server (for what I have seeing). Federated rooms continue to exist if a server drops off, as no server "owns" them.

This is an AI-generated summary of TFA?

can any layman user simply use it without running their own instance?

Unfortunately XMPP is an absolutely terrible protocol. IRC's not much good either, but at least it has the excuse of being ancient and limited in what it wanted to achieve.

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.

That is currently still the differentiator between people producing code and shipping something and people who care and actually have years of experience shipping. At the current state how well you steer the LLM and which questions you ask still matters, maybe in the future "build me an app" will give amazing results, but right now you still need to know what you are doing.

In this case, it's just a waste of tokens as something not very unique was generated that doesn't have a real use case, or solves anyone's problem. As with many AI generated projects, I'm willing to bet that OP themselves will not using it any more in a month.

or maybe they know about XMPP and prefer IRC. I have always wanted to build one of these on top of IRC. I grew up on IRC and sometimes just the nostalgia of familiar tech is what drives us to build towards it not how good it is.

I've done this a few times. If I had to gesture at the root cause I'd say: LLMs lack curiosity and are trained to complete assignments, not to question their validity, so both the research phase and the questioning of intent tend to get short shrift prior to building anything.

”There’s a specific downside to LLM-based development that people can get neck deep in a new project without interfacing with the existing work in the field.”

That’s because it’s a paradigm shift, not meant to be planned or organized by humans. The prior paradigm was that there were subject-matter experts who were human. The new paradigm is that the only author of all code is to be a machine. This new paradigm requires removing all prior authors (who happen to be human), and removing them simply requires overcrowding their output such that it’s not locatable or trustworthy.

Sit back, grab some popcorn.

> I half expect the LLM would have mentioned that at some point, but the repository does not.

The repository does not even mention this software is LLM-generated.

I wonder when/if the collective realization will land that LLM's failure to retain provenance during training means the code it generates exists in an indeterminate state of public domain / IP trap.

LLMs could be asked to research extra projects.

It's valid that someone just wanted to build something like this for their own purposes.

Ya, ive stopped interacting with all new projects, the amount of slop written by people who have no business remotely putting something out there for others to use is untenable.

The system has broken under the noise.

XMPP is massively bloated protocol that is badly managed for last 2 decades

IRC linking is a mess, in part due to the spanning tree requirement. Also the server to server protocol in the RFC is spoken by zero servers so you have to pick which unofficial protocol you like best. May as well invent your own that actually fits your use case.

I have a harness built on top of pi that uses XMPP for all agent communication with me and between agents[0]. It works well, I text them from my phone and from my browser (or anything else that supports xmpp). They can communicate with each other over group chats and can schedule agent tasks using a GitHub project and a cron job.

The agents run on my NixOS server in their own unix account, this is the real secret sauce. This lets me use unix perms to limit their access to things, and it allows them to handle server administration. I've given them access to a cli mail and calendar client[1], github, and they have the ability to deploy updates whitelisted services. NixOS lets them install whatever they want in ephemeral shells, and it's not possible for them to break the server in a way I can't trivially roll back.

They can modify the caddy config, so there have been times I've entirely built and deployed new services on a new domain from my phone on the bus.

The harness is called pi-msg, I've done a writeup of my machine's setup on my site.[2]

[0]: https://github.com/zachpmanson/pi-msg [1]: https://github.com/zachpmanson/docket [2]: https://notes.zachmanson.com/the-fleet/

I prototyped it, and - in my experience - it didn't work as well as having them just communicate by spawning processes.

I know that people in the Hermes agent community have been using Continuwuity/Matrix to do agent communication.

Oh my pi does it, not sure if that’s something from upstream or just a fork feature but from my experience it seems to work well

Internet drama was so much better back then.

Cool. I did something like that so agents and people could communicate with a Jira instance using Websocket-aware IRC and a browser-based client based on superchat.

Put the issue context in a #channel and invite external parties/entities, bring the results back to the work.

I have tested it but the complexity didn't justify the results in my experiment. I couldn't get it accepted into Atlassian Marketplace, either.

That is always a concern, yes. You can block users, and entire instances, that spam.

That seems to be similar on this one. &room is local, while #room is federated.

Curious, why the interest in building your own ntfy client (instead of using the one already built/available)?

By the way, for years now, i have used a little python (cli) app to send messages into a private matrix room. This room has 2 people in it: me and a bot. (The bot is simply the matrix account that sends the messages.) I went this route because i did not want to install another app - such as ntfy - on my mobile simply to receive server notifications, etc. And, since i had ben on matrix already chatting with friends, it happened to be a low-effort approach. To clarify, i am no longer self-hosting my own synapse home server...so i'm simply piggybacking on the matrix.org one...but that has helped at least unify my notifications and comms to a good degree.

Now, if you were to aske me to implement my "notifications system" via a different approach, funny enough, i would gauge between XMPP and ntfy to see which is lighterweight....because i believe them to both be quite light on the need for resources. I don't know which is lighter (sorry, i know i'm not answering your question). however, i *think* the ntfy server is less hasle....Only because xmpp takes a little more work to setup...at least that was my experience a couple of years ago. I cast no shade on either xmpp nor ntfy - because to me boh are awesome...i' m merely saying that resources needs aside, i wonder if ntfy might need less time from YOU.

>I'm searching for a simple, self-hosted chat system that allows me to host unlimited bots and send messages (with notifications) to my iPhone easily.

I do this with IRC. I used to have a blog post up about it, back when blogs weren't just training data providers for LLMs, but I'm afraid it's been deleted.

tl;dr IRC works great, but you need to wire up push notifications. For android I used pushbullet, for iOS I am still evaluating the alternatives but pushover looks okay. IRC itself is nice because the protocol is shit simple, to the point that if you can type fast enough to respond to the pingpongs you can cosplay as a bot using nothing but telnet. As a text protocol it's easy to inspect and doesn't require binary decoding of packets for debugging.

I recommend the Ergo ircd. It ships as a single binary (golang), can support tens of thousands of clients, is at the forefront of the ircv3 modernization initiative, and is under active development.

Email?

you should look at celld

clearly.

Or matrix

A lot of the design reads like almost but not quite ActivityPub.

[flagged]

The idea (what's encouraged) is that's so simple you can run it yourself. If you email me (email on profile), I can create an account for you on mine.

You're in luck: Some people already thought of this, submitted an RFC to the IETF and implemented it. It goes by the name XMPP.

Many earth rotations ago, I was IMing through an mIRC bot because I refused to install MSN. This kind of reminds me of that too.

[flagged]

Sorry, I am sure it is the HN effect.

You can link servers (Libera, for example, has many), but they are not federated, nor decentralised (services are used for registration, etc.).

Closed federations. Only trusted servers

To be fair, if i recall correctly, some of the folks who started up matrix protocol (and associated project) came from/and loved the IRC world (e.g. the rooms concept, etc.)...so it stands to reason that matrix and irc have at least some *conceptual* similarities, and hence other stuff that spins off from or leverages IRC may also appear similar to matrix.

Instead of TCP+XML it's HTTP+JSON

The IRC is just a front end. Could use any front end

Slack is pretty centralized, and also closed. You can't self-host at all.

Slack is a *different* bait and switch.

Different use case no? I thought slack was enterprise focused from day one.