Hacker News Reader

Comment by singpolyma3 | Hacker News Reader

So rooms are "global" between whatever hosts your host happens to know about? So it's one giant netsplit party forever and only your server admin can ban someone?

View on HN

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

> 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?

I am not the owner of the project, I just use it. Federated rooms have no owners, there will be no collisions (they would simply merge). Nicks are tied to their own servers, and hence unique and will not collide.

This has been an issue for as long as IRC itself has existed. There are solutions to resolve such "netsplits" and "netjoins", but they all rely on the servers in the network being trusted and not malicious.

With Parley, where anyone can bring their own instance, and they are not guaranteed to not to be malicious, that could be an interesting issue to solve.

CAP theorem suggests it is not solvable.

This like most federated systems is AP. Cut a federation link and you create two or more different state views.

From the screenshot on the project website, it seems "@serv.er" is part of any remote nickname, so I'm assuming the nicks are in per-server namespaces, which prevents any nick collisions.

Although it must wreak havoc on many IRC clients, since the @ sign has a very specific meaning in the IRC protocol. :)

That’s an old screenshot, which should be redone. We switched to :, so, it is now nick:example.com.

I believe Matrix does solve this, at least to an extent.

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

Reply on news.ycombinator.com