How to write an IRC bot
sircmpwn.github.io
sircmpwn.github.io
Thank goodness the web and email are open protocols, let's hope in 10 years time we have added a standard chat protocol to that list, and no one is wasting time on proprietary chat platforms.
She doesn't know what XMPP is.
When she knows what XMPP is (or a competing federated protocol), chat is solved.
You're mixing the ubiquity and common parlance/popularity to suit your situation, but it doesn't work that way. FTP, IRC, HTTP, and SMTP are all ubiquitious, but not necessarily the most popular method for describing things, keeping in mind that we haven't fully shut the book on the internet == www.
XMPP is the protocol that you're talking about here but you shifted gears midway through to say that she should know what instant messaging is. (which again, I'm gunna guess she does).
Similarly, Email fetching itself has gone through one major protocol shift under her nose without changing the very nature of it, so to make claims that in the particular instance of messaging she should know the protocol is arbitrarily moving the rule-bar.
(Bet you still have to try and explain the difference between http and https to her too, and that always ends with *sigh... just look for the little green lock. :P)
Probably your mom does use neither POP3 mir IMAP, but either a Webmailer or Google's proprietary HTTP-based Gmail protocol used by the Gmail app (or Yahoo mail or ...)
And whatever is being used: Users don't know what HTTP is or how it works, they have some understanding of entering addresses and clicking on links.
(For German speakers I suggest this video from children TV program "Die Sendung mit der Maus" from ca. 1996 which goes quite in depth https://youtu.be/8PNRrOGJqUI )
This argument directly contradicts my first hand experience communicating with people online. They were perfectly capable of using those various applications to communicate with others.
Well we do have one now: XMPP. I was pleasantly surprised at the current state of it, when I revisited it last year.
That being said, it's still not in a "just-works" state, and while I might enjoy fidgeting around with it to get things like push messaging to work, I can see why many people don't want to do that.
At least you're fidgeting around with an open protocol and not something that's proprietary and won't work in a few months.
Sircompwn, if you're reading this, thanks for the neat content. I don't mind stumbling upon them during my lunch breaks :)
I also remembered truecraft right now when I saw this post and went to check on it. The git repo is now archived and read only, but didn't find a mention anywhere if/why development was given up.
Progress: https://drewdevault.com/donate
Most people who use Slack haven't ever used IRC professionally (or at all) - I've shown IRC to people who love Slack and I usually get "Ugh, it looks so old fashioned and difficult to use" as a reaction. Looks matters a lot if you want people to use it - most IRC clients are old or have designs based on old clients.
Plenty of Slack clones out there that look decent that have similar business models. What would be awesome if there's an IRC server that looked and acted like Slack; nice features like:
- a website to log into like Slack (with benefits like modern web design and Github, Twitter, Facebook login). - an irc client that looks decent on website, desktop and phone clients (and doesn't run on electron). - having multiple channels for one company like Slack channels in a group. IRC currently requires you to register several channels (which is annoying).
------------
As for the difficulty in writing bots for Slack vs IRC, sure it's easier to write stuff for Slack because:
- most Slack bots/services are written by companies who want their third party services to be easily integrated into whatever team communication their client use.
- most custom bots are variation of some bots that someone else has written (anecdotal evidence but pretty sure it's true). I'm pretty sure it's not that different for irc.
- most people don't bother writing bots unless they're willing to play around with bots; difficulty isn't an issue when it comes to writing one and I haven't seen bot development treated as an actual task (it's more of a hack that works and isn't really touched again.)
------------
Honestly, this seems to be a case where the author neglects how real-life people work in favor of code "niceness" (for lack of a better term). There's a reason why most people use Microsoft products (and it isn't because they make great software.)
He gives a nice reasoning in the last paragraph:
Slack is a walled garden. Their proprietary API is defined by them and only implemented by them. They can and will shut off parts you depend on (like the IRC+XMPP gateways that were just shut down).
Is this really true though? Doesn't Mattermost have a slack-ish-compatible interface?
I lately only ever use any chat client sporadically so I’m out of touch, but may be needing a platform soon.
Interesting note: I worked at AOL when AIM was introduced and was one of the first users :-P When I moved to tech support of a local cable internet company that was our official work chat :-)
I have no idea what the future holds, and I always welcome new tools and disruptions, and I'm using slack, discord, messenger etc for various communities. What keeps me from leaving irc is:
* friction in moving all users that have been using an IRC channel for 20 years
* stupid stuff in slack and messenger like lock in and slow search. I really like grep:ing logs for links and discussions and then reading the context up and down, which I have found difficult in web services.
Does TheLounge let users upload custom emoji? I ask, because my coworkers say, "You can take Slack from my cold dead hands". There was even a great emoji war.
I would like to stand up a web interface to IRC and let folks play around on it. I tried Convos, but it didn't seem to fit that piece of the puzzle.
For the backend, I have always used UnrealIRCD + Anope services. It has always been rock solid and scales beyond any need I could imagine. It would be great if there were a modern web interface I could put in front of it that people would want to use.
But there is always that irc channel easily to get into and will be there in 20 years.
I know that I can extend my irssi client with plugins needed to preserve history, flag stuff, save in database by triggers, then export that in whatever way I want and serve to the users.
I used to do this anyway so that I could reload the bot without reconnect spam
1) https://github.com/pR0Ps/znc-logsearch
2) https://github.com/robinsmidsrod/znc-log-viewer/blob/master/...
Quassel alone is a kinda nice client, with the entire ecosystem around it, it becomes amazingly powerful.
And the beauty of the Qt client is that, being Qt, you can fully style it with css - e.g. https://bugs.quassel-irc.org/projects/quassel-irc/wiki/Style...
Disclaimer: I contribute to some of the above mentioned projects)
The best apps tend to be platform dependent. I know many who like http://colloquy.info for mac, for example.
I've never tried Glowing Bear. Maybe that would be a nice way for friends to get comfortable with IRC?
Works well, and is a native app that fits well into the general ecosystem.
This is the exact reason why I don't like Slack - It takes up WAY too much screen estate. At least with IRC I can format it in a way that I prefer, AND be able to use the rest of my screen for other tasks.
Slack has its merits, but plain IRC also works fine.
The same people that prefer slack because they never really tried IRC, might say they prefer slack because it allows them to write BOTs.
BOTs in irc is easy, there are 3 kind of bots:
- bots that interact: User types something in a channel or via private message. The bot will receive that message and the user that typed it. then it will parse the message and take an action. Examples of interaction messages:
-- msg to bot: google this: "time now ?" (then the bot connects to google and makes a query and replies to this message): UTC 10h20 -- msg to bot: reboot
- bots that say stuff: You are on a chatroom and then all of a sudden a bot joins and says something ie. "Your new website has been updated". OR, "Someone made a pullrequest on github, please somebody go there and accept it"
- a mix of those 2: the bot will say stuff and also accept/interact commands
IRC is really simple. The bot simply reads text and takes action. Or, just take action and talk on the channel. Its completely diffrent from slack bots because it is simpler it will not need the programmer to set up a WEB SERVER in order to receive messages from slack. Seriously.. the bot should connect there just like the user does and read messages, parse and take action.
Long live IRC =)
BOTs that say stuff works this way: You are on a channel and then all of a sudden a BOT joins and says: "The new release of your website has been successfully updated"
However Slack does require HTTPS which complicates things, but is also quite a must in current day and age.
Usually I have met two kinds of people. Those who do not need any motivation to learn new things about computers. And those who will just flat out refuse to learn anything that remotely does not look like what they are already accustomed to.
The biggest "win" for Slack where I worked was getting the non-engineers on it (product, UX, etc), and I doubt they prefer Slack because of the bot writing :)
Right now my plan is to convert my good old (but still in heavy use, with MegaHAL!) bot [0] to Haskell, while reading the book and learning the language. The current bot was my last ever Ruby project and while I take using a new language as a challenge, the Cinch [1] framework is definitely worth a try if you want to create a bot quickly.
[0] https://github.com/pimeys/diskotappi [1] https://github.com/cinchrb/cinch
* Keeping an internal ban list? Check.
* Removing stale bans from the channel? Check.
* Keep the bot opped? Check.
* Has built-in user management? Check.
* Uses telnet or DCC to manage the bot? Check.
All that features have it's use, but most of the time they are not needed. Instead people new to eggdrop have to "fight" with that features.
* User keeps getting banned when he enters the channel, even after an op removed the ban. Channel op has to learn about the internal ban list.
* Eggdrop removes all bans after 180 minutes (default).
Eggdrop admin has to disable that feature or add the user to the internal ban list.
* For non-channel admin bots, the bot does not need to be op.
Eggdrop will complain about it.
* Built-in user management uses part of the hostmask.
You got a new ISP, good luck restoring your access to the bot.
And it doesn't play nice with the accounts from IRC services.
* DCC doesn't work behind if you are behind NAT. And using telnet means using a different program.
In the past, I tried to solve several of that problems with Tcl scripts, with variable success.
* Allow the bot to be managed through commands in IRC.
* Bind to raw events, hide them (return 1) from eggdrop and send a replacement command through an internal API.
I had to use that to make eggdrop aware of the popular +qa modes (channel owner and channel admin)
Or replace the user host so eggdrop sees a fake host with the account name in it. Solves the problem with the user management through hostmasks.
In the end, I gave up. I wrote an IRC Bot in Tcl and re-implemented the Tcl API, so I could use the old eggdrop scripts.
This was my original inspiration: https://aaronparecki.com/2015/08/29/8/why-i-live-in-irc
One of the things that certainly contributed for keeping my interest in programming was the quick feedback. No need for confusing setups, just open the editor and start doing something. I know a lot of people that started this way and are good programmers nowadays.
- Start wasting lots of time in MSN chatrooms
- Parents cancel MSN and switch to local ISP. Mourn loss of chatrooms.
- Discover IRC using the mIRC client
- Start playing around with mIRC scripting
- Get into Linux because that's what the crowd I hung out with on IRC was using
- Switch to epic and BitchX and start scripting on this clients
- Get into eggdrops and start scripting those and then start looking through the actual source code and making changes
- Start writing my own bots
Amazing how much my current career as a software dev is owed to things I learned because I liked "wasting" time chatting online.
Connect in one line of code:
`require('tennu').Client('../config/myNetwork.json').connect();`
IRC is turning 30 this year, actually.
Yeah
- 20% of the article: pretending to write a bot (and never actually writing a bot) that does about 1% of what a bot on Slack can do
Article title: "How to write an IRC bot"
I've personally written a (admittedly crappy) four-way integration between Slack, IRC, XMPP, and Telegram [1]. IRC and XMPP are consistently the worst protocols to write for if you want anything but plain text. And believe you me, people do want something besides plain text.
And don't get me started on clients for those :)
Funnily enough, irccloud is basically trying to do what Slack is doing, only with IRC: a web-based interface, with private channels, embedded media, etc. The only way to ,enjoy all that is to use the web-based clients, etc.
What did you expect? The secret sauce is on the client.
For example, user pastes in plain text, a youtube url:
userXXX: http://youtube.com/cool-video
Then lets say user2 client reads that message, then it will parse it and check if youtube.com has a plugin enabled. If it does, it will get the thumnail and title and display it in a nicer way than just the URL. But it was initially just a url.
I think you want a HTML chat with javascript. Try making that... and discover that it is not secure to accept and run javascript from unkown users.
So plain text means securer! -- without code that might be evalled.
Slack doesn't run a "youtube plugin javascript". It does link unfurling [1]. Precisely for this reason: "it is not secure to accept and run javascript from unkown users.". And, of course, it supports unfurling for a lot of things out of the box: links, images, youtube and vimeo videos, spotify playlists etc.
That is there in the protocol/API. Your client may then chose to display those unfurled links however it wants. Slack's client presents them more or less exactly the way users may want, consistently across multiple platforms.
Neither IRC no XMPP have that. That's why you mistakenly think that the only recourse is to "accept and run javascript from unkown users on the client".
And yes. Most users do want a chat with formatting, unfurled links, inline messages, inline video, emoji reactions, multifunctional bots etc. That's why they flock to Slack, not to IRC/XMPP.
---
[1] https://api.slack.com/docs/message-link-unfurling#slack_app_...