ngIRCD irc Daemon

[parabyte]

you may find this interesting.
https://github.com/mikechambers84/ngIRCd-DOS

[ghaerr]

Broken link - gives 404.

[parabyte]

fixed sorry, typo'ed

[parabyte]

I been playing around with openwatcom and made a script to build ngircd
its abit out of scope but i have managed to get this far and really could help with some pointers.
its based off stable 27 release of the daemon

this is my build script
build.txt

this is the error i do not understand.
error.txt

[ghaerr]

Are you building this for ELKS? Or are you just using OpenWatcom to build for DOS? I am pretty familiar with the OWC settings required for ELKS but not familiar with the options in general.

For ELKS, please take a look at the ewcc and ewlink scripts in elks/tools/bin. I have spent a lot of time on them and we use the owcc wrapper for ELKS building rather than calling WCL directly. The general idea was to be able to say ewcc file.c file2.c file3.c, then ewlink file.obj file2.obj file3.obj and have it all work. The many many different options for WCL and OWCC have been consolidate into the the ewcc and ewlink scripts. (Of course, what would be nice would be to write a script 'ewcc' that was a true 'cc-like' wrapper around files and invoked the compiler and linker appropriately for file type but I haven't had time to complete that yet).

When building for ELKS, it is fairly important that you do NOT include any WATCOM/h directory in the include search path. This happens to be where your current compilation is dying. It is picking up <strings.h> from OWC rather than from ELKS libc/include.

Your build script looks quite nice and fairly fancy. I don't have to debug that script or look at the many options for WCL, but will try to help you get the daemon compiled for ELKS.

In summary, it looks like your problem is that the compile is including a WATCOM .h file, which is not supported by ELKS. The mess of OWC .h files is not something I want to get into. Thus, the important WATCOM .h files that we DO work with have been copied to libc/include/watcom/*.h. If/when your program uses a non-approved .h file, we can deal with getting it copied over, but that is not (yet) what is happening here. So remove the -IWATCOM/h from your build and/or look at how it is handled in ewcc.

[EDIT: I just happened to notice that ewcc does not yet have the WATCOM/h removed, so you should have the following instead:]

ELKSLIBCINCLUDE=$TOPDIR/libc/include
ELKSINCLUDE1=$TOPDIR/include
ELKSINCLUDE2=$TOPDIR/elks/include
#WATCINCLUDE=$WATCOM/h <--- comment this line out

source $TOPDIR/libc/watcom.model

CCFLAGS="\
    -bnone                          \
    -mcmodel=$MODEL                 \
    -march=i86                      \
    -Os                             \
    -std=c99                        \
    -Wc,-fpi87                      \
    -Wc,-zev                        \
    -Wc,-zls                        \
    -Wc,-x                          \
    -fnostdlib                      \
    -Wall -Wextra                   \
    -Wc,-wcd=303                    \
    -I$ELKSLIBCINCLUDE              \
    -I$ELKSINCLUDE1                 \
    -I$ELKSINCLUDE2                 \
    -I$WATCINCLUDE                  \ <--- delete this line
    "

You should be able to use the above information in order to get your script to work and get better results. Please let me know how you are doing on it, thanks!

[parabyte]

ah yes things are making much more sense now, i removed watcom from my PATH.

I seem to be hitting this error
error.txt

[ghaerr]

Ok. Geez, my instructions as well as the current ewcc are still messed up (fix coming).

Now, you also need to add in a third include, which is where we have copied some watcom header files: libc/include/watcom.

Thus, the proper list should be:

ELKSLIBCINCLUDE=$TOPDIR/libc/include
ELKSINCLUDE1=$TOPDIR/libc/include/watcom
ELKSINCLUDE2=$TOPDIR/elks/include

That is, for your build, you need to include $TOPDIR/libc/include/watcom also.

[ghaerr]

Actually, the proper order should not matter, but could:

ELKSLIBCINCLUDE=$TOPDIR/libc/include
ELKSINCLUDE1=$TOPDIR/elks/include
ELKSINCLUDE2=$TOPDIR/libc/include/watcom

[parabyte]

error.txt

[ghaerr]

/usr/bin/watcom/h/strings.h(55): Error! E1009: Expecting ')' but found '('

Look at the error: you're including WATCOM's strings.h. Bad, change it. Reread my above comments, we're not talking about OWC PATH but include paths. I don't know how WCL works, as I mentioned, I only use owcc.

[parabyte]

sorry its very late here, so may call it a night, i posted a incorrect error file,

this is the correct error file
error.txt

[ghaerr]

Look through the error messages, they are somewhat explanatory, then get some sleep!

src/ngircd/client.c(28): Error! E1055: Unable to open 'strings.h'

Check if #include "strings.h" or <strings.h>, needs to be the latter.

src/ngircd/client.c(94): Error! E1031: Name 'h_name' not found in struct/union hostent

This one is more tricky - I have no idea: there is no struct hosting on ELKS, so you'll have to dig down more to see where or what it is.

This could be something to do with Watcom TCP. The big problem you are likely to have, from what I was reading when you first posted this, is that this program uses Watcom TCP. I don't think it is compatible with UNIX/BSD sockets, which is what ELKS uses. So the TCP access portions may need rewriting.

src/ngircd/client.c(79): Error! E1011: Symbol 'PACKAGE' has not been declared

I have no idea what this is, there is no PACKAGE in ELKS C library. You can grep the Watcom clib sources for it, but that usually gets complicated very fast.

[ghaerr]

how do i disable watcoms tcp?

You can't, although I'm not sure what the compiler errors are other than that. What I'm talking about is the source code to NGIRCD is written for Watcom TCP. It may have to be recoded for UNIX/ELKS sockets. I haven't looked at the source code so I can't tell. You're welcome to chase down some of the source lines that the errors show and post them, or post a link so I can click it, as I am short on time myself.

[parabyte]

im actually stuck, wondered if maybe you could give me some pointers or insight,
`/home/arduino/source/elks/libc/include/errno.h(7): Error! E1009: Expecting ';' but found 'extern'

code that is throwing the error.
conf.txt

[ghaerr]

No problem, but this undoubtedly has to do with your Makefile etc having been setup improperly with regards to the required include file order, and lots of other little things. This is why I wrote the ewcc script. It is too complicated to explain all that is required, but it is all in the ewcc script. Try running ewcc ngircd.c or whatever the filename you're trying to compile is.

That should work better. After that, you can study what ewcc does versus what you are doing in your Makefile, which hopefully is the issue. You can use ewcc for each of your source files, then ewlink *.obj to link, and its all done for you. I can't debug the many options OWC has, which is why I prepared a script to use for ELKS.

code that is throwing the error.

I can't compile that without removing all the local .h file includes, because I don't have them. I did comment them all out and ran ewcc and didn't get the error your getting though, which is good.

I hope that helps?

[parabyte]

is this what you had in mind?
build(2).txt

[ghaerr]

Yes, nice. But does it work? I don't think the ewcc script is smart enough to accept "-o file" or -c, etc. It was written quickly with the intent to compile a single .c file quickly, using the OWC toolchain and having the includes/defines/settings set compatibly for ELKS.

What I had in mind was for you to try manually compiling one or each of the .c files, rather than through a complex script, so that you/we could more easily understand the errors that might be produced from compatible compilation of the program you're porting using the OWC compiler. Then at least we know we have the compiler switches and include file ordering correct, and we can see what other errors there are. After that, if you want to make a more complex build, then moving to a complex make script will be easier.

I say all this because we haven't been able to determine whether it is your setup or the .c files themselves that are most contributing to making this port hard. Also, I doubt that ewcc will work other than manually, unless it is extended to be more like a cc replacement.

In summary, what happens when you just run "ewcc ngircd.c"? That is the file you had the problems with shown above, right?

[parabyte]

progress is coming along slowly, I have not abandoned this project, just running into some watcom specific obscurities

[ghaerr]

No problem, take your time! I plan on updating ewcc and ewlink to be more useful also, when I have a bit more time.

[parabyte]

any idea whats going on with this

/home/arduino/source/elks/libc/include/sys/time.h(8): Error! E1009: Expecting ';' but found 'struct'

many thanks in advance.

[ghaerr]

It sounds like possibly another issue of the include files not being setup properly - I would have to see the source file it came from and how it is being compiled. Looking at sys/time.h, it looks pretty normal. Are you compiling using ecc or a different method?
I never heard back from you regarding whether trying ecc rather than your Makefile helped or not. Thanks!

[parabyte]

ecc was the answer to my problems, I have been exclusively using that as my tool of choice, Turns out my issue was that watcom was parsing some code intended for a gnu compiler in one of its header files, specifically porttab.h, im slowly getting into the mindset with working with watcom. less hand holding unlike other friendlier modern compilers.

[parabyte]

i have been working on this on and off for months, 10 mins here, 5 mins there,

i have a compiling binary now not actually ran it, will try it later today/tomorrow and upload to github

[ghaerr]

Wow, very cool! Will it work with our tinyirc IRC client?

At 232K, I can see why you've had to use OWC's large model!

Once you get it working and approve, we'll definitely want to include it in our application distribution on larger images. I'm working on figuring out an automated way to do that starting with our next v0.9.0 release.

[parabyte]

ghaerr defiantly want to run it past you before i release anything! sorry i was abit premature about this working. As you know compiling and working 2 totally different things! it does load, but as soon as i connect to it, seg faults, i really wish to figure this out on my own, been a big uphill battle! in the meantime On the ssh thread i have gifted ssl lib i managed to get building, again as we know building and working 2 different things!

[ghaerr]

No problem @parabyte, there's no rush over here! The program can't easily be debugged with blink16, since networking isn't supported, but elksemu might allow you to skip having to create images every make cycle. I've gotten used to using printf or __dprintf sprinkled heavily through startup code in main() to more quickly find where it's stopping. Another idea is to compile with CONFIG_TRACE=y then set strace in /bootopts. This will produce output showing every system call, which will only work well if you're running from an emulated serial terminal in QEMU so that you can scroll backwards. That output is quite voluminous, but can help a lot for certain problems.

[parabyte]

[parabyte]

I am away at the moment and my computing experience is sparse!

if anyone wants to try this, and see if you can host a irc server post the ip here!

[parabyte]

https://github.com/parabyte/ngircd-elks.git

[parabyte]

ironed out the stack bugs, i think maybe this is ready for testing, just wrestling with qemu on my debian stock box

[parabyte]

Here i present ngircd for elks. Tested with multiple local irc clients, not tested more then 4 connections.
Happy holidays!
ngircd

[parabyte]

[ghaerr]

This is very nice @parabyte, I plan on checking this out!!! Did it have to be built in large model?

I don't know much about connecting with IRC. Which client are you using, can you give an example of the command line used to access this new server?

I recently updated ELKS' tinyirc but have never used it.

[parabyte]

[parabyte]

to run the daemon you need to pass -n flag to it essential otherwise it seg faults out, -f flag for its conf file,

as for irc client i am just using hexchat, but any client including tinyirc will be fine,

Large model yes,

as for an address for you to access this on, unfortunately i have a very good deal with my isp, and with that deal i do not have a public ip!
i was kind of hoping one of the kind users of elks could perhaps host this on real hardware?

[parabyte]

in the ngircd.conf i have ngircd configured to listen on port 6667 standard irc port

and yes ./ngircd.os2 -n -f ngircd.conf

the conf file is rather crude and thrown together may need tweeking, also i just noticed that a doc folder needs to be present in the ngircd folder that i have recitified on my local build. will push

[ghaerr]

I just tried running /ngircd.os2 -n -f ngircd.conf
Then tinyirc 10.0.2.15, it gives error:

# tinyirc 10.0.2.15
TinyIRC 1.1 Copyright (C) 1991-1996 Nathan Laredo
This is free software with ABSOLUTELY NO WARRANTY.
For details please see the file COPYING.
*** User is Admin
*** trying port 8000 of 10.0.2.15

Obviously its using the wrong port... what command line do you use, I'm trying to figure this out without trial and error.

[ghaerr]

Trying tinyirc 10.0.2.15 6667 gives:

# tinyirc 10.0.2.15 6667
TinyIRC 1.1 Copyright (C) 1991-1996 Nathan Laredo
This is free software with ABSOLUTELY NO WARRANTY.
For details please see the file COPYING.
*** User is Admin
*** trying port 6667 of 10.0.2.15

Bind failed: Try again 

It doesn't seem to work with tinyirc. I don't run Linux and have no idea what to run on macOS to access this for testing.

[parabyte]

looking into this now, sorry i did not try with tinyirc only hexchat and mirc

[ghaerr]

Ok, it seems to work 2nd time around:

 tinyirc 10.0.2.15 6667
TinyIRC 1.1 Copyright (C) 1991-1996 Nathan Laredo
This is free software with ABSOLUTELY NO WARRANTY.
For details please see the file COPYING.
*** User is Admin
*** trying port 6667 of 10.0.2.15

tinyirc: sorry, no termcap cm,cs,ce: dumb mode set
001 Welcome to the Internet Relay Network [email protected]
002 Your host is elks.irc.local, running version ngircd-elks
   (i86/unknown/elks)
003 This server has been started Sat Dec 20 2025 at 03:25:19 (
004 elks.irc.local ngircd-elks abBcCFiIoqrRswx abehiIklmMnoOPqQrRstvVz
005 NETWORK=ELKS-Net is my network name
005 RFC2812 IRCD=ngIRCd CHARSET=UTF-8 CASEMAPPING=ascii PREFIX=(qaohv)~&@%+
   CHANTYPES=#&+ CHANMODES=beI,k,l,imMnOPQRstVz CHANLIMIT=#&+:5 are
   supported on this server
005 CHANNELLEN=50 NICKLEN=9 TOPICLEN=490 AWAYLEN=127 KICKLEN=400 MODES=5
   MAXLIST=beI:50 EXCEPTS=e INVEX=I PENALTY FNC are supported on this server
251 There are 1 users and 0 services on 1 servers
254 2 channels formed
255 I have 1 users, 0 services and 0 servers
265 1 1 Current local users: 1, Max: 1
266 1 1 Current global users: 1, Max: 1
250 Highest connection count: 1 (1 connections received)
375 - elks.irc.local message of the day
372 - "Welcome to ngIRCd on ELKS!"
376 End of MOTD command

What do I type after that to do anything?

[parabyte]

tinyirc need to be ran like this to satisfy ngircd daemon

tinyirc -d testuser 10.0.2.16 6667

[ghaerr]

Whatever I typed, it returned "***Nowhere to send". I then tried ^D to exit and it got into an infinite loop and I had to kil QEMU. Sorry, I don't even know what IRC does, really.

I guess multiple clients have to connect to do anything, right? I will try to figure out a way to do that. The daemon isn't running in the background, so I'm using the serial line to run tinyirc.

[parabyte]

is tinyirc in elks same as what they include with debian?

i was assuming its been unchanged for decades

[ghaerr]

is tinyirc in elks same as what they include with debian?

I have no idea, I'm on macOS.

I did manage to get three logins going using init 6, then switching consoles via Alt-0, Alt1. I started the daemon, then logged in on another console (Alt-1) and started tinyirc, it connected. I then logged in on the serial port over QEMU and tried to start another tinyirc, but ELKS ran out of processes ("Cannot fork"). So it seems ELKS isn't (yet) big enough to actually test on itself, at least for the moment.

We will probably want an option for running the server in the background, and only display its copious mesages when run -d, like ftpd. With that, we should be able to test on QEMU using just the console and the ttyS0 serial login and not run out of processes.

You can look at elkscmd/inet/telnetd.c or inet/httpd.c (simpler) for how to fork and become a daemon, if you're interested.

[parabyte]

will study elks process forking and the example you mentioned above to get ngircd working as a real daemon over the holiday period. so far still entertained enough by ngircd working in elks as is! also plan on stripping out redundant code for other platforms,to make this easier for myself and others to look at.

Thanks for testing my silly project :)

[ghaerr]

If I start the daemon on the console using:

$ init 3
$ net start
$ exec ./ngircd.os2 -n -f ngircd.conf > /dev/null &

I can then run the ELKS tiny IRC client on two terminals (the console /dev/tty1 and the serial line /dev/ttyS0), I run on each:

exec tinyirc -d testuser 10.0.2.15 6667

The first execution of tinyirc comes back with:

TinyIRC 1.1 Copyright (C) 1991-1996 Nathan Laredo
This is free software with ABSOLUTELY NO WARRANTY.
For details please see the file COPYING.
*** User is Admin
*** trying port 6667 of 10.0.2.15

001 Welcome to the Internet Relay Network [email protected]
002 Your host is elks.irc.local, running version ngircd-elks
   (i86/unknown/elks)
003 This server has been started Sat Dec 20 2025 at 05:07:36 (
004 elks.irc.local ngircd-elks abBcCFiIoqrRswx abehiIklmMnoOPqQrRstvVz
005 NETWORK=ELKS-Net is my network name
005 RFC2812 IRCD=ngIRCd CHARSET=UTF-8 CASEMAPPING=ascii PREFIX=(qaohv)~&@%+
   CHANTYPES=#&+ CHANMODES=beI,k,l,imMnOPQRstVz CHANLIMIT=#&+:5 are
   supported on this server
005 CHANNELLEN=50 NICKLEN=9 TOPICLEN=490 AWAYLEN=127 KICKLEN=400 MODES=5
   MAXLIST=beI:50 EXCEPTS=e INVEX=I PENALTY FNC are supported on this server
251 There are 1 users and 0 services on 1 servers
254 2 channels formed
255 I have 1 users, 0 services and 0 servers
265 1 1 Current local users: 1, Max: 1
266 1 1 Current global users: 1, Max: 1
250 Highest connection count: 1 (1 connections received)
375 - elks.irc.local message of the day
372 - "Welcome to ngIRCd on ELKS!"
376 End of MOTD command

The second one asks for another Nick, I respond 'test'.

Then typing on either IRC client just says "***Nowhere to send". Is this expected behaviour? I can't actually get the clients and server to do anything. Sorry for the dumb questions, just trying to test, and tinyirc has no instructions.

How is it that the two clients are supposed to talk with each other? Does the client or server support /join commands? Is there a list of commands supported? I have tried the following, but nothing appears anywhere:

/msg testuser hello
/msg test hello2

Trying to exit either of the clients with ^D (is there another way?) results in an infinite loop. Trying to run tinyirc again says "Bind failed: Try again". I suspect this is because the server socket is not marked to be reused. To fix this, look at telnetd.c or httpd.c and use something like the following code:

    /* set local port reuse, allows server to be restarted in less than 10 secs */
    int ret = 1;
    if (setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, &ret, sizeof(int)) < 0)
        perror("SO_REUSEADDR");

[parabyte]

"***Nowhere to send". Is this expected behaviour, yes that is expected behaviour for tinyirc, you need to issue /join #channel name to join a channel and /list to list the channels. At some point i may have a play with tiniyirc and look at modern clients and see what mechanism they use to drop the client into a server default room. at this point i do not know and not looked into it. on this specific project i have the default room set as #elks as specific in the ngircd.conf, that should live in /etc

[ghaerr]

@parabyte
As described in #2495 (reply in thread), it would be extremely helpful to put together a README.md file on your repo that describes exactly how to run ngIRCd on ELKS including which options to use, along with which configuration files have to be copied where, and then followed up with examples of using ELKS own tinyirc to connect to it, and any host-based IRC clients you've tested, and exacly what command lines they should be started with.

After that, the README.md could list commands that a newbie might use to verify that the system is in fact working. Case in point for myself, it appears that the ngircd.conf file may not have been read, so no idea what channels are available. In addition, the server spits out so many error/info messages that one can't tell important messages like "no config file in use" from two pages of other messages.

[parabyte]

I have not figured out process forking yet, but have fixed the ngircd networking code. seems to release clients correctly now, and correctly parse there port now.

[parabyte]

seems to do 5 concurrent connections before everything is exhausted. "have to figure out how to interface with one of those xms boards!"
does release clients correctly just takes a moment or 2

[parabyte]

oh also I find this script for setting up a tap interface on my debian machine to interface with elks exceptionally useful i am sharing here for others.
started off as standard qemu.sh from elks and evolved into this over time
testqemu.sh

[parabyte]

I will not be making the build system for ngircd any more complex as i find it easier to just copy required files into rootfs template manually and less error prone, especially as i want to push users of this project to craft together there own config. unless you think i should make a build script that uninstalls, cleans etc gnu style?

[ghaerr]

find it easier to just copy required files into rootfs template manually and less error prone

That would definitely be easier, but make sure that your repo actually states what files are requird to be copied to where!

especially as i want to push users of this project to craft together there own config.

My advice is to publish a working configuration that does not need to be hand-crafted. Without that, many newbie users won't even bother creating their own config, since they can't get the program(s) to actually run in the first place without studying source code.

unless you think i should make a build script that uninstalls, cleans etc gnu style?

Definitely not! Anything close to GNU-style scripts should be completely deleted, IMO. There's absolutely no place for that bloat on ELKS, but if the program is supposed to be compilable on Linux or macOS without change, then these days generally all that old GNU garbabe can still be deleted, and a simple Makefile posted instead that works on Linux and/or macOS. If the source code uses ifdef __ELKS__ then no additional compiler options need be specified, since __ELKS__ is automaticaly always defined when compiling with ia16-elf-gcc. If OpenWatcom is used, then ifdef __WATCOMC__ can be used instead.

[ghaerr]

@parabyte

Something like this should work to fork to become a daemon:

    int pid, fd;

    /* become daemon, debug output on 1 and 2 */
    if ((pid = fork()) == -1) {
        printf("ngIRCd: No more processes\n");
        exit(1);
    }
    if (pid)
        exit(0); 
    /* reroute stdout and stderr to console */
    fd = open("/dev/console", O_RDWR);
    close(STDIN_FILENO);
    dup2(fd, STDOUT_FILENO);
    dup2(fd, STDERR_FILENO);
    if (fd > STDERR_FILENO)
        close(fd);

The daemon can then write to stdout or stderr, they both go to the same place, /dev/console. These outputs may want to be further restricted to if (debug) printff(...) so that the console doens't have debug messages displayed unless the daemon is run with a -d option, which is the current convention.

[ghaerr]

seems to do 5 concurrent connections before everything is exhausted. "have to figure out how to interface with one of those xms boards!"

No, that won't do much, as it appears that ngIRCd is using 129K of RAM, with only 14K of unused heap available. The program is simply extremely huge for ELKS.

I would guess that ngIRCd might be using fork() to service each new client, in which case the system would run out of memory in 4-5 connections. If that's the case, a complete redesign might be necessary or desirable.

OTOH, if fork() is not used for clients, then the heap can be increased to max available (up to 64K minus existing data segment including all the strings, etc) using the -Wl,option -Wl,heapsize=0xFFFF option in ewlink. Even then, I would guess free heap will be small (use ps to tell) because of the seemingly massive number of info/error strings built into the server.

I would suggest deleting most of the info strings, or hiding most of them behind a macro so that they're not taking up valuable heap space.

As I come to understand IRC a bit more, I think that a simple, small IRC server could be written from scratch using just 10-20% of the memory requirements of ngIRCd. I tried getting elkscmd/tinyirc/tinyircd.c to compile, but it looks to have not been modified in 30 years, and likely hasn't been compiled in that long either. Even theDebian which distributes tinyirc doesn't include or compile tinyircd.

OTOH, you may be looking for a large, very capable server. But a limit of 5 users doesn't seem to work well for that. Keep in mind though that ELKS doesn't even allow more than 20 file descriptors, so 15-17 would be the max number of connections ever, and more than 5 connections will require recompiling the kernel with MAX_POLLFD set to higher than 5 in limits.h if select() is used.

I mention all this not to discourage development on ngIRCd, but to understand the extreme limitations of ELKS and other real mode operating systems. One must be keep an eye out for memory usage at al times.

[parabyte]

you know in all the excitement of me getting this to work, i never really kept my eye on memmory usage!
you have a very fair point, to be a elks compatible project really this needs to be more lean,
Will take into considering what you have said about truncating or eliminating most of the info info strings.

It honestly never occured to me to just do FFFF for the heapsize with watcom!
Always specified it as a numerical value.

15 or so concurrent users should be my target.

I have come this far,

i will see about making it a little bit more lean, but i do not really want to take too much away or rewrite too much as its not really ngircd anymore.
I think after i done my work perhaps someone else should perhaps fork this project and see where it can go?

at least elks has ngircd now, albeit slightly broken.

[ghaerr]

I have come this far,

Yes, a long ways! I have been reading the source and happened into "compat.c", things ELKS is missing. I will look in to implementing some of that, and continue to help you get ngIRCd running hopefully with no bugs or crashes.

[toncho11]

README or wiki page on ELKS' wiki so that people can get the general picture of what is available, how to configure and use it.
It is an interesting question if tinyirc could be used for other chat services as well?

https://en.wikipedia.org/wiki/Matrix_(protocol)

For example Mastodon, Slack and Discord are quite popular now. See bwlow:

Service	Direct IRC Bridge	Via Matrix	Stability	Notes
IRC (native)	Yes	Not needed	Very high	Native protocol
Matrix	Limited	Yes	High	matrix-irc is mature
Mastodon	Bot-based	Yes	High	Uses Mastodon API
Telegram	No	Yes	High	Common Matrix bridge
Discord	No	Yes	High	Popular Matrix bridge
Slack	No	Yes	High	Requires Slack app
XMPP	Partial	Yes	Medium	Feature mismatch
Signal	No	Experimental	Low	Unofficial bridges
WhatsApp	No	Experimental	Low	Unofficial, fragile
Viber	No	Experimental	Low	Rare, bot-only
SMS	No	Experimental	Low	GSM/modem based
Email	Bot-based	Bot-based	Medium	Mailing list style

[parabyte]

just a quick note to anyone following this thread, i added brief better instructions to the ngircd daemon,
if you get really really stuck and really really need ngircd its fine to message me as this is such a niche thing. long as i can connect to your server running this! not tried this on real hardware