This month, ejabberd is 18 years old. On this occasion we talked with Alexey Shchepin, who created ejabberd in November 2002. Today, ejabberd is one of the most popular XMPP servers in the world, used by millions of people, devices and many big companies like Facebook, WhatsApp, or CCP Games (famous for the EVE Online saga).
Marek: I guess when you created ejabberd, you didn’t expect such growth. When did you realise ejabberd is going to be big?
Alexey: I’m not sure, somewhere between 2003 and 2007. In 2003 ejabberd could handle jabber.ru load, and in 2007 it was widespread and used in places I didn’t expect. The original goal was to use it to build the global XMPP network, but it was also used as a base for many custom IM solutions.
M: Why did you choose to use Erlang for ejabberd?
A: I found it the most suitable language for implementing an XMPP server. Its support for concurrency and clustering is great. On the other hand, Erlang is pretty slow on many string operations, but they can be implemented in C, so this drawback can be avoided.
M: What do you think about how ejabberd has developed over these 18 years?
A: It has improved a lot in efficiency and flexibility. Although there are a few things which left almost unchanged since the very beginning, lots of internals are completely different now. For example, thanks to Evgeny Khramtov’s work, there is almost no need now to handle XML manually in modules. That was one of the most annoying and boring things. You can write a spec and get packets already parsed into a convenient representation.
M: And can you shed some light on how ProcessOne got involved in ejabberd development?
A: As far as I remember, I was first contacted by Mickaël Rémond in 2004. He had ideas about commercial applications of ejabberd, which eventually led to ProcessOne supporting ejabberd development.
M: What was the most challenging part in your ejabberd development throughout these 18 years?
A: Probably designing it in the very beginning, as it was my first real program in Erlang. I didn’t know about many things (like gen_server, supervisors, etc). And the most challenging coding part was implementing the Google Wave module. Its operational transformations were not well-documented, and it took a lot of time to figure everything out.
M: Do you feel any regrets coding that Wave part, seeing how Google shut it all down in the end? Or was some of that code reused in relation to ejabberd later on?
A: Yes, it’s a pity that it was shut, probably it wasn’t convenient or popular enough. Or found its destination as a collaboration feature of Google Docs. Our code wasn’t reused, though it can be revived if an application for it appears.
M: Maybe one day, for an XMPP-based collaboration tool :) Coming back to ejabberd, when you started this XMPP server, it focused on instant messaging, but today it grew much beyond that, especially because it supports other protocols like MQTT and SIP. What in your opinion is the most interesting way to use ejabberd today?
A: I wish I knew that :) For me IM was always the main goal, and it would be great to see major IM providers like Whatsapp or Telegram open a way to federate with 3rd-party servers, but it will probably never happen.
M: You are still an active ejabberd developer. Can you share some of your plans or wishes for the coming years?
A: It’s hard to plan for years ahead. For example, this month Facebook/WhatsApp are going to release a statically-typed variant of Erlang, and maybe it will be so great that we will consider rewriting ejabberd into it.
M: What is your currently favourite desktop and mobile XMPP client? In the early days of ejabberd development you also created the Tkabber client. Any plans on getting back to it?
A: I use Tkabber right now :) No plans on getting back to it – it does what I need from it. And I don’t use any mobile client.
M: I will have to test out Tkabber then. Can you share what are you working on now developing ejabberd? And has the way you use Erlang and develop ejabberd changed over the years?
My programming style has become more paranoid I think. Maybe it happens with every growing project – in the beginning you write new code very fast, but then you have to account for more and more things, remember more API calls. And the absence of static typing doesn’t help.
M: That’s true, as the code matures and is used by many, each change has to be careful as to not create problems for the users. The JSON encoding of packets is a really great future and should help web & node developers communicate with ejabberd. Does it have any impact on server performance and throughput?
A: I’ve implemented only proof-of-concept WebSocket module, no benchmarks have been done. But the way JSON packets are encoded and decoded is very similar to XML one, so I hope performance won’t be affected.
M: Excellent. Now for some more general questions: As I understand you have been working remotely for many years now, does that mean the pandemic had little impact on your work? Do you have any advice for developers moving into the fully-remote work?
A: Yes, no impact on my work, and I have no problem sitting at home. On the other hand I have friends who just can’t work from home: it’s either very inconvenient for them, or they can’t concentrate. So I guess there is no universal advice, it just works for some people and don’t for others. Maybe for night owls a solution can be to work at night.
M: What is your Erlang/ejabberd development stack (OS/editor/other tools)?
A: Using Linux since 1999. For many years my editor had been XEmacs, but now it’s almost not supported by modern Emacs packages, so I switched to Emacs. Other tools are standard like make/git/diff/etc.
M: And which Linux distro do you prefer?
M: Nice, me too. Are there any other projects you are working on?
A: There was another interesting project implementing ejabberd in OCaml called jamler, but it’s not open-sourced yet.
M: What would be the benefits of implementing ejabberd in OCaml over Erlang?
A: It was an experiment to see how ejabberd would look with static typing. It was written as close as possible to original sources except low-level parts, as they are completely different in OCaml.
M: Would ejabberd code maintenance be easier with OCaml’s static typing, or is it enough to rely on existing Erlang compilation tools to detect problems? Or was the point of this experiment entirely different?
A: Yes, it’s much easier to maintain and refactor when the compiler checks all the typing, or checks that you didn’t miss a branch in your pattern matching. In ejabberd, there are many extra calls to stringprep functions, because you can’t just say “accept here only binaries that were stringpreped”. In OCaml you can.
M: Nice, so this would also mean a leaner code. Thank you for the chat! Here’s to the many more years of ejabberd and its continuous development!
To go down the memory lane, you can also check out this interview with Alexey conducted in 2005 by Justin Kirby.
Photo by Steve Halama on Unsplash