mickael

You need a stream parser like expat. No need to code your custom parser and once you settle at level n+1 in the XML it is just like parsing independent document. But again, the parsing is hidden by existing XMPP library, so you do not even need to go to that level of details.

You should compare it to other messaging protocol. You may change opinion, as it is actually elegant, modular and quite versatile. It managed to adapt over 25 years which I think it is quite a testimony. All messaging apps from that time disappeared.

I do not understand who could deploy a nationwide chat and support those costs.

I have written an article explaining the difference between Matrix and XMPP, and why it cannot be as scalable by design.

You can read it here: https://www.process-one.net/blog/matrix-and-xmpp-thoughts-on...

TL;DR: Matrix protocol is based on document replication and synchronisation, while XMPP is based on message passing. Matrix requires to constantly replicate and merge the data. It is an intended feature, but as it does more, you cannot expect to scale to the same level.

That said, we want ejabberd to be able to suit all types of messaging needs and we have already implemented 1-to-1 gateway with Matrix server inside the protocol. We are fine tuning our chatroom interop with Matrix. It means that we have already most of the code in place to support Matrix chat (as we need to implement the replication part). It means, the next step could be to implement full Matrix support for those who would rather use Matrix clients.

Disclosure: I am ProcessOne Founder, XMPP developer since 1999 and working on ejabberd since 2002.

Yes, I confirm you can build the same starting from ejabberd. A lot of changes are related to the ability to scale horizontally only some subcomponents, to fine tune the processing power, and also things that are related purely to Whatsapp infrastructure.

I have been using an event XML parser to process XML on iOS (such as expat). You can processed the XML as a stream and it is very efficient.

I have been funding Murena, because it’s probably the most ambitious and challenging project that aims to make the world better. We need to make the tech an opportunity again for people, to make it work for the people.

Exploring the 'Commons' in the digital economy. I discuss the French government's endorsement of a proprietary messaging platform, highlighting a deep misunderstanding of key digital dynamics.

I am using Obsidian as well and I am considering using an Android eInk tablet (Like a Boox), with a keyboard to be able to use Obsidian. I may give it a try it some day.

Thanks for this repo :) I also writes in French, but decided to switch to Qwerty layout a while back to get access to a wide-range of nice keyboard. Very happy with this move. I know this will not help you right now, but just saying you may not totally stuck to AZERTY forever.

I would start by both getting involved in the server part of the Swift forum (https://forums.swift.org/c/server), and by checking simple tickets you could help with on those projects Github.

I am writing this from the Server Side swift conference. Despite what is said in the comments, I do not see a community waiting for Apple to push the server-side ecosystem further. What I see is a group of passionate people building plans to move the ecosystem forward. Yes, it is still easier to develop on MacOS than on Linux (but it is doable). Yes, having the async/await feature in the language sooner than later would help. However, the community seems healthy and the projects are interesting and well designed.

You can use VS Code + remote & Docker: https://medium.com/@ianpartridge/swift-development-in-docker...

The notification are for signaling. The message notification can be distinct and encrypted using standard push notifications. If the problem is with metadata around the conversation (like typing indication, etc), they still can be encrypted on the server but with a cleartext flag associated with them to tell if the content should be pushed or not.

Apparently, Typescript type system is already Turing-complete: https://github.com/Microsoft/TypeScript/issues/14833

I’m the CEO of ProcessOne and lead on ejabberd, ask me anything :)

When you talk about MQTT and IoT, scalability and clustering is the deciding factor. When you deploy an IoT stack, it is common to have to manage hundreds of thousands or millions of devices. The stack is leveraging ejabberd clustering and scalability.

MQTT 5 is implemented in ejabberd. That new version improves a few stuff, including error response.

What I find interesting is to link exception handling in real or virtual process to the way we handle it in programming languages.

Exception handling is one of the main difference between a junior and senior programmer. Beginner programmers will often struggle getting their code working in real life due to their focus on the ideal code path.

It also reminds me of Erlang "Let it crash" philosophy: you cannot always handle all possible errors that can happen in real situation and it is often best to design your system to be able to cope and recover from transient unexpected errors. This is at the heart of Erlang worker and supervisor architecture design.

Well, in practice, it is more than a promise. You are not forced to use Mnesia. You can use other backends to simplify the ops. Yes, it is as simple and make managing the platform a breeze. You need to be as stateless as possible.

Well, the most difficult part is to understand how the Erlang VM / Environment works. Once you have set it up, ejabberd just works. You can have massive scale and large uptime. This, ultimately, saves bigger headaches.

On the increasing number of accounts, it could as well be due to a rise in spam that we have seen on XMPP.

Yes, exactly: https://medium.com/processone/ejabberd-massive-scalability-1...

And this is on a single node. ejabberd can scale to a huge number of concurrent users.

yes indeed :) https://www.epicgames.com/fortnite/en-US/news/postmortem-of-...

They mention 3.4 million concurrent users online.

From what they say on clustering, it looks that this is also ejabberd.

Yes, that makes sense. I guess they can focus on developing the core game that way.

XMPP strong selling point is federation. You can run your own private server and it does encryption. There is plenty of implementations from servers to clients, most being open source. It seems to me just one of the Zillion messaging alternative available.

This benchmark was done without TLS because we wanted to demonstrate the performance of ejabberd and not the performance of OpenSSL itself. TLS is still something you can offload to a load balancer however.

I updated the post to fix typo and mention that test was not over TLS.

You will know soon, as we are working on such a higher load benchmark. From existing production service thought we expect very good result, especially as the test server was not fully loaded.

We manage to load the server properly with Tsung (https://github.com/processone/tsung) but for a more heavy load we may need to add one more Tsung server.

Actually, Elixir support comes from API changes to be more Elixir friendly (for example order of parameter to be "pipe" friendly). This is also about submitting the component on hex.pm package manager to be easily integrated in Elixir mix tool. And finally, this is about writing some part in Elixir. For some projects we are even starting writing code directly in Elixir.