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.
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 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.
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.
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.
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.