
Goircd: Minimalistic simple IRC server written on Go - stargrave
https://git.cypherpunks.ru/cgit.cgi/goircd.git/tree/README
======
antirez
500 lines of code IRC server I wrote in Tcl in 2004:

[https://github.com/antirez/tclircd/blob/master/ircd.tcl](https://github.com/antirez/tclircd/blob/master/ircd.tcl)

IRC simplicity is magical.

~~~
sitkack
What impact did IRC have on the design of Redis? You have spoken about the
simplicity of Tcl, are there other systems that you think have interesting
design properties?

~~~
antirez
I believe IRC and other old school text based protocols definitely inspired
the idea of the protocol itself. But there is also kinda of a complementary
aspect to that: in the past I had to write, for work, things like a non
blocking POP3d for busy mail servers. The way the normal implementations
worked was pretty terrible, so I developed a lot of appreciation for event-
driven designs like the one in Redis, that tend to be very efficient. About
IRC and the other text based protocols of the early days of Internet, I always
thought that their inefficiency for certain tasks was never about the fact of
being text-only, but because of the lack of prefixed length information. No
prefixed length means two terrible things, an EOF signal of some kind but
especially a way to quote such EOF in case it is present in the data part
itself. Then HTTP arrived and showed that it was possible to do great things
with text protocols, and now, the irony, it is a binary one as well :-D So
Redis uses a prefixed-length but otherwise textual protocol for this reasons.

~~~
u801e
> No prefixed length means two terrible things, an EOF signal of some kind but
> especially a way to quote such EOF in case it is present in the data part
> itself.

For SMTP and NNTP messages, a CRLF.CRLF terminator is used to indicate the end
of the message. If the message itself contains a line that started with a .,
then the client would prefix that line with another . (dot-stuffing). The
receiver on the other end would remove the extra dots from the line before
storing the message. So, quoting part of the EOF is one viable solution and
doesn't result in too much overhead in those cases.

~~~
antirez
Unfortunately that's a lot of overhead: you want to read an email as a whole
blob of data, not splitting it by lines (that is effectively processing every
byte) just to tell if there is a ".." prefix.

~~~
u801e
What I do in perl is to set the line terminator to CRLF.CRLF, read from the
socket into a buffer, and then try to read a line (where a line is now defined
as something that ends in CRLF.CRLF) from the buffer and check whether it ends
in the terminator. Once I've read the data including the line terminator into
the buffer, I run a s|\r\n\\.{2}|\r\n.|g on the buffer and then write it to
disk.

Though it does consume more memory since I have to store the message in a
buffer, it doesn't involve splitting the string line by line. It just
processes the entire email message at once.

With a size prefix, I would still have to read into a buffer and check its
size to see whether I've read enough data.

Though checking the length of a string or size of a file involves less work
compared to checking for a line terminator and removing the dot-stuffing, if
the amount of data we're dealing with is not large, then there probably isn't
really that much difference in the amount of work done for those checks.

------
diath
IRC-anything gets thumbs up from me, I always thought that IRC bots are a
great way to learn a new language, just a nice project that you could do in a
day that would teach you the basics of the language, string manipulation,
networking and some stuff here and there, an IRC daemon is taking it a step
further. This looks very nice but it really is minimal as the title claims,
personally I've been working on one to learn Rust which is more featureful at
this point but as it turns out the IRC protocol and server handling is much
more complex once you get into the details than it normally seems for such a
simple protocol.

~~~
omribahumi
That's what I've been doing since I was 12 years old :)

My first "programming" experience was with mIRC scripts. I even wrote an IRC
client using mIRC sockets at some point, and a dummy webserver / SMTP client.
When you do things the wrong way, you pick up a lot of new skills. I learned
to "reverse engineer" (my implementations were trivial, not fully fledged)
protocols with a proxy/sniffer pretty early :)

From there, the first use case I had for every new language I wanted to learn
was write an IRC bot. I had written one in VB6, VB.NET, Python and even C/C++
at some point.

It's funny to see this comment on HN, as this has been my mantra for a while
now. On top of string manipulation and networking, another important piece it
teaches you about a language is using data structures and manipulating data.
IRC client is super stateful. For example, it needs to maintain the list of
channels you're in, the list of users in those channels, their op/voice
status, etc.

Highly recommended as a project for picking up a new language.

~~~
gspr
Me too! I will never forget adding "runtime loadable moduels" to my PHP IRC
bot at age ca. 14. Oh my was that functionality a travesty: a user might say
something like `!load poll` to activate the poll module. What would my code
do? Oh it'd `include poll.php` (or whatever the syntax is, this was both my
first and my last PHP project) in the main loop. On every iteration. Because
hey, how else would the poll code be able to react to stuff?

I learned a lot of lessons and still have fond memories 20 years later :-)

Edit: Man, just thinking at this has Metallica playing as background music in
my head even though I haven't listened to them in this decade. It's so strange
how childhood memories can be so incredibly strong and cover so many sensory
modalities. These days I can hardly remember what I did last week.

~~~
sitkack
I suggest you check out [http://brainrules.net/](http://brainrules.net/) by
John Medina, he covers the fidelity of our memories as we age and much more.

[https://www.youtube.com/watch?v=NujSdn1bg5k](https://www.youtube.com/watch?v=NujSdn1bg5k)

------
secure
Shameless plug for [https://robustirc.net/](https://robustirc.net/), which is
also written in Go, and solves netsplits (between servers, and also between
client and servers when clients use the RobustIRC bridge or a compatible
client) :)

~~~
dijit
Had to check the authors file[0] to realise you're one of the authors. Wow!
I'd like to say a resounding thanks.

I've been looking at this system recently and I'm going to be including robust
IRC access to my network (shameless plug[1]).

The code is clean, I think I have a good understanding of how it works and
from my testing it does seem to work really well!

That said, have you looked at how much of your original problem space is
solved by IRCv3?

[0]:
[https://github.com/robustirc/bridge/blob/master/AUTHORS#L10](https://github.com/robustirc/bridge/blob/master/AUTHORS#L10)

[1]: ircs://irc.darkscience.net:6697/darkscience

~~~
secure
Thanks, I’m very glad to hear!

I had looked at IRCv3 briefly when starting the project, but it looked like
IRCv3 didn’t solve netsplits.

Have I overlooked anything (or has something changed), or did you just ask out
of curiosity?

Keep me posted regarding how RobustIRC is going for your network!

~~~
microcolonel
> _...but it looked like IRCv3 didn’t solve netsplits_

Darned CAP theorem.

------
detaro
Another IRC server written in Go, probably less minimalist though:
[https://github.com/oragono/oragono](https://github.com/oragono/oragono)

Been running it for quite a while now without troubles (but only few internal
users, so not particularly challenging)

~~~
slingamn
I'm one of the Oragono maintainers. Thanks for the kind words :-)

You're correct, we're not trying to be minimal at all, more "batteries-
included". The largest deployments so far are in the low hundreds of users,
with no performance or stability problems. Based on my stress testing I'd say
an instance can scale comfortably to 10k clients, with at most 2k clients per
channel.

~~~
detaro
Thanks for making Oragono! I've been meaning to upgrade my setup with some of
the newer features, but honestly the binary I installed years ago just runs so
it hasn't been a priority :)

------
MrGilbert
I get an invalid certificate, as the root ca is ca.cypherpunks.ru, which is
not trustworthy.

You might want to look into that, because I like the idea. :)

~~~
clarry
I also like the idea of being my own CA instead of pretending a bunch of
random companies are trustworthy.

~~~
rakoo
What's the point ? This effectively makes the whole encryption worthless,
might as well serve your site in plain HTTP

~~~
KCUOJJQJ
The visitor cannot be sure that he really is connected to git.cypherpunks.ru.
But doesn't encryption work anyway?

~~~
rakoo
Encryption is active with a host you don't know. It's TOFU, which is OK if you
can verify the identity through persistent uses (ie with SSH you'll have
connections with the same server over a long period of time, or with IM you'll
talk to those people over a long period of time). In the case of HTTP you'll
only get the content now and potentially not visit the site anymore for a long
time, especially if it's a personal site.

A few years ago self-signed certificates made some sense, today with Let's
Encrypt there is absolutely no good reason to continue doing this on the open
web

------
daneel_w
We have been running this for several years for the IRC service in our closed
community "cloud". It is unfortunately subject to many bugs, some of which
affect its stability. It crashes regularly.

~~~
dewey
Any specific reason why you keep up with that instead of just using another
one of the very minimal servers like
[https://ngircd.barton.de](https://ngircd.barton.de)?

~~~
daneel_w
The BOFH is a Go fanboy.

~~~
kuschku
Then why not oragono?

~~~
daneel_w
He may not be aware of it. I will forward the project name to him.

------
juliend2
Are there any startup or community out there who are still using IRC? If so,
what are the reasons?

I wonder what are the advantages of that over newer technologies like Slack,
Discord, or even XMPP.

~~~
dijit
community leader here, we have 500 or so people on the network, I can give my
reasons.

IRC vs Slack:

No brainer, Slack is a hosted application that can change its client on a
whim. Bot functions are nice but moderation tools are severely limited and the
client is very heavy.

IRC vs Discord:

Similar to Slack in nearly all regards, however it's better at being what
slack was supposed to be I think. It definitely is "eating my lunch" compared
to Slack. But the same rules apply, it's very heavy and you have no control of
the client.

IRC vs XMPP:

XMPP is great. The clients for it are relatively good, the protocol, while
XML-y is good, but the bot tools are not very good, and federating is hard
given the XEP fiasco.

Additionally, most existing clients treat XMPP as a IM platform and do not
focus on chatrooms.

Why IRC then:

Well, the truth of it is that if you're sitting on a wired, stable connection
then IRC as a text based instant messaging chatroom system is really good. It
has no "frills" like emoji responses or threading. No avatars, nor does it
force your client to render anything in a specific way. You're free to use
what you want.

If you want inline images, there's a client that does that.

If you want to have a persistent presence, searchable backlog then there's
bouncers, or a managed service that does that[0].

If you want a terminal experience that is lean and stripped, or a big fat
client that grabs gravatar emails from nickserv registered accounts to display
them as avatars, it's possible, anything is possible. And that possibility
also exudes the hacker culture.

IRC also does not require an account of any kind, this can lead to some
measures of abuse, but due to the very good (though, admittedly hard to use)
moderation tools you can have many different ways of managing the community,
from shadow banning people, to muting channels, to invitation only channels or
passwords- all the way to channel or network level blocks on usernames/IPs.

Also: nostalgia and I've configured the client how I like it[1]

[0]: irccloud.com

[1]: [https://xkcd.com/1782/](https://xkcd.com/1782/)

~~~
juliend2
> [1]: [https://xkcd.com/1782/](https://xkcd.com/1782/)

That made me LOL so loud. Thanks for your very thoughtful response.
Appreciated.

------
Pmop
Lots of things going on with Go. Do you people recommend using Go for back-
end, despise its controversial design decisions?

~~~
cellularmitosis
Reach for golang when performance is the priority. Reach for a dynamic lang
when speed of feature iteration is the priority.

------
juped
Imagine all the bandwidth that could have been saved over the years if Jarkko
had called PRIVMSG MSG instead.

~~~
txdv
an irc message usually fits in an mta, i doubt you can justt count 4 bytes for
every message

------
jchw
Cool!

I wrote an IRC server in Python Twisted some years ago, can’t seem to find the
code anymore but I love how simple IRC is. I hope the protocol fragmentation
has improved somewhat with efforts like IRCv3.

------
jphoward
Link appears broken, but hopefully this is it:
[https://github.com/ThomasHabets/goircd](https://github.com/ThomasHabets/goircd)

~~~
thinkmassive
Repo linked in OP (git.cypherpunks.ru) has commits from 2019. Last commit to
the GitHub repo was 6 years ago.

------
sys_64738
I wrote an IRC client with one line in a shell script back in the 90s.

