• Pl chevron_right

      Ignite Realtime Blog: Dan is voted in the XSF's Council!

      news.movim.eu / PlanetJabber • 21 December 2023

    Our very own @danc was voted into the XMPP Standards Foundation Council not to long ago!

    The XMPP Standards Foundation is an independent, nonprofit standards development organisation whose primary mission is to define open protocols for presence, instant messaging, and real-time communication and collaboration on top of the IETF’s Extensible Messaging and Presence Protocol (XMPP). Most of the projects that we’re maintaining in the Ignite Realtime community have a strong dependency on XMPP.

    The XMPP Council, that Dan now is a member of, is the technical steering group that approves XMPP Extension Protocols. With that, he’s now on the forefront of new developments within the XMPP community! Congrats to you, Dan!

    For other release announcements and news follow us on Mastodon or X

    4 posts - 4 participants

    Read full topic

    • Pl chevron_right

      Ignite Realtime Blog: Dan is voted in the XSF's Council!

      news.movim.eu / PlanetJabber • 21 December 2023

    Our very own @danc was voted into the XMPP Standards Foundation Council not to long ago!

    The XMPP Standards Foundation is an independent, nonprofit standards development organisation whose primary mission is to define open protocols for presence, instant messaging, and real-time communication and collaboration on top of the IETF’s Extensible Messaging and Presence Protocol (XMPP). Most of the projects that we’re maintaining in the Ignite Realtime community have a strong dependency on XMPP.

    The XMPP Council, that Dan now is a member of, is the technical steering group that approves XMPP Extension Protocols. With that, he’s now on the forefront of new developments within the XMPP community! Congrats to you, Dan!

    For other release announcements and news follow us on Mastodon or X

    4 posts - 4 participants

    Read full topic

    • Pl chevron_right

      Ignite Realtime Blog: Dan is voted in the XSF's Council!

      news.movim.eu / PlanetJabber • 21 December 2023

    Our very own @danc was voted into the XMPP Standards Foundation Council not to long ago!

    The XMPP Standards Foundation is an independent, nonprofit standards development organisation whose primary mission is to define open protocols for presence, instant messaging, and real-time communication and collaboration on top of the IETF’s Extensible Messaging and Presence Protocol (XMPP). Most of the projects that we’re maintaining in the Ignite Realtime community have a strong dependency on XMPP.

    The XMPP Council, that Dan now is a member of, is the technical steering group that approves XMPP Extension Protocols. With that, he’s now on the forefront of new developments within the XMPP community! Congrats to you, Dan!

    For other release announcements and news follow us on Mastodon or X

    4 posts - 4 participants

    Read full topic

    • Pl chevron_right

      ProcessOne: Instant Messaging: Protocols are “Commons”, Let’s Take Them Seriously

      news.movim.eu / PlanetJabber • 20 December 2023 • 8 minutes

    TLDR;

    Thirty years after the advent of the first instant messaging services, we still haven’t reached the stage where instant messaging platforms can freely communicate with each other, as is the case with email. In 1999, the Jabber/XMPP protocol was created and standardized for this purpose by the Internet Engineering Task Force (IETF). Since then, proprietary messaging services have continuously leveraged the power of internet giants to dominate the market. Why do neither XMPP nor the more recent Matrix, which aimed to improve upon it, break through this barrier, when it’s clear that protocols must be open to enable exchange? Without this fundamental principle, the Internet itself wouldn’t exist.

    In the following article, I revisit how the French government recently promoted the instant messaging service Olvid and what this reveals about our approach to digital technology. It’s frustrating to see France promote a secure, yet proprietary messaging service that offers no progress in terms of interoperability, especially at a time when the European Union is striving to open up the sector by requiring all messaging services to be capable of intercommunication, through the Digital Markets Act .

    I conclude with reflections on our inability in Europe to collaborate on “commons,” our difficulty in building a foundation, an ecosystem that allows for healthy co-opetition, a blend of competition and collaboration, which is the only way to regain significance in the digital economy. Short-term political thinking forces our companies into an every-man-for-himself approach, preferring to dominate a small market rather than share a larger one.

    Today, perhaps, it’s time for a change?

    Cables

    Thirty years and counting since the emergence of the first instant messaging services, we still lack a universally accepted exchange protocol, as is the case with email. The Jabber protocol, later renamed XMPP (eXtensible Messaging and Presence Protocol) and made a standard, was born with the hope of breaking the proliferation of isolated silos like MSN, ICQ, Yahoo!, which did not communicate with each other. Today, other silos have emerged, but the problem persists: it is still impossible to exchange messages between accounts from different major messaging providers. Why? Let me tell you the story of a clumsy communication operation around a French messaging service, Olvid, which illustrates well the familiar patterns we often find ourselves stuck in.

    The French Government’s Endorsement of a Proprietary Messaging Service: A Closer Look

    I discovered the messaging service Olvid in late November 2023, following a flood of articles in the French press. I wondered how a company of 15 employees, created in 2019, had managed to get such press coverage. It was promoted directly by Prime Minister Elisabeth Borne: “Popular messaging applications like WhatsApp, Telegram or Signal have ‘security flaws’,” justified the office of Elisabeth Borne, who urged her ministers to download the French application.” ( Les Échos, November 30, 2023 ). In November 2023, Matignon asked government members and ministerial offices to install this system on their phones and computers “to replace other instant messaging services to enhance the security of exchanges.” Then came the superlatives: “The most secure messaging service in the world” (Jean-Noël Barrot). “A step towards greater French sovereignty” (Elisabeth Borne). And it needs to be done quickly. Elisabeth Borne asked ministers to “take all necessary steps” to deploy Olvid in their ministry “by December 8, 2023, at the latest” ( Ouest France , November 29, 2023).

    Why Olvid? The articles I read on the subject remain relatively vague; I know mainly that it is certified by ANSII, the organization guaranteeing the state’s IT security. Yet, it’s far from the first secure messaging service I’ve come across, and it’s the first time I’ve heard of Olvid. What about other services and especially Signal, which is recognized worldwide for its security, backed by audits? Among secure messengers, the list is long: Signal, Threema, Wire, Berty, etc. So, what security flaws are we talking about?

    Signal Hits Back: A Strong Response to Security Claims

    Signal’s response was swift, with a direct and clear position from Meredith Whittaker, president of the Signal Foundation:

    The French PM is mandating ministers use a small French messaging app. OK. But I’m alarmed that she’s claiming “security flaws” in Signal (et al) to justify the move. This claim is not backed by any evidence, and is dangerously misleading esp. coming from gov.
    If you want to use a French product go for it! But don’t spread misinfo in the process. Signal is independently audited, open source, and our protocol has been tested for >10yrs. We are serious about responsible disclosure and we prioritize all reports to security@signal.org
    Numérama, December 1, 2023

    Double Ratchet

    Regarding Olvid’s security, the main argument seems to be as follows: The system does not rely on centralized directories, operates without identifiers, which means no user account is hosted in the cloud.

    First, it seems to me that this is the principle of key-based authentication. Message routing is done solely based on a key, in the cryptographic sense. If it is lost, it’s impossible to recover the account. Nothing revolutionary, then; it’s cryptography, dating back to the encryption software PGP (Pretty Good Privacy) of the 1990s and even before.

    Then, such a system generally requires the physical exchange of public keys. Where Olvid seems to stand out is in the alternative ways proposed to simplify and lighten the burden of key exchange by meeting physically. This can work, first because the product is not free, so the user base is limited, where Signal, for example, offers a global platform and says it needs an identifier, the phone number to limit spam. Then, these alternative methods rely on mobile device management (MDM) tools, interfacing with an enterprise version of the Olvid server. In one way or another, this goes through a central point of distribution and reintroduces a weakness. It’s far from a completely decentralized protocol like what the team building the Berty messaging service is trying to do, for instance.

    Browsing their site to find the protocol, I admit I choked a bit on some mentions thrown a little freely on their site, for example, Post Quantum Cryptography , cryptography that resists quantum computing. It’s nice, it’s pleasant, but in practice, what’s the reality? I didn’t find more detail under this mention, but personally, being hit with such buzzwords makes me rather flee, as it smells of a commercial who got a bit carried away. But let’s assume, the Olvid team is composed of encryption experts. I skimmed their specifications, but I admit I’m not a mathematician, so who am I to judge their math formulas?

    What I do understand, however, is that almost all secure messaging systems, including Olvid, rely on the Double Ratchet algorithm, which was first introduced by… Signal.

    At the Heart of Messaging: The Critical Role of Protocols

    In terms of protocol, however, I am an expert. I have been working on instant messaging protocols since 1999. And, it’s not beautiful… Olvid’s protocol is the antithesis of what I would like to see in an ambitious messaging protocol. It is a proprietary, ad hoc protocol, not based on any standard, minimalist for now, and condemns itself to reinventing the wheel, poorly. The burning question is, why not choose an open protocol that already works on a large scale, like XMPP, adding their value on top? The Internet protocol, TCP/IP, is open, all machines in the world can communicate, yet there are competing internet service providers. I am still looking for an answer. Because XMPP is too complex, some will say? I think any sufficiently advanced chat protocol tends to become a derivative of XMPP, less accomplished. Come on, why not even use Matrix, a competing protocol to my favorite? Apart from simple ignorance, I see no reason. Unless it’s to lock down the platform, perhaps? But, locking a communication protocol makes no sense. It’s replaying the battle of internet protocols, TCP/IP versus X.25. A communication protocol is meant to be open and interoperable. Personally, I would invite Olvid to adopt a messaging standard. Let them turn to the W3C or IETF, to XMPP or MLS. These organizations do good work. And it’s a guarantee of sustainability and above all, of interoperability.

    We come to a very sore point. The European Commission, and therefore France as well, is discussing the implementation of the Digital Market Act. Among the points the European Union wants to impose is… the interoperability of instant messaging services. How can the French government promote a messaging solution that is not interoperable? And preferably standardized and open.

    I talked about Olvid’s proprietary protocol, which is actually more of an API (Application Programming Interface), that is, a document that describes how to automate certain functions of their server. What about the implementation? The client is open source (on iOS and Android), but seeing in their exchange interface calls to URLs named /Freetrial. This implies payment. I am not sure that Olvid would welcome the idea of compiling and deploying one’s own version of the client. That’s the principle of Open Source, but such an initiative could try to circumvent payments to Olvid. As anyway, no open-source server is available and the only one running is operated by Olvid, the client code is of little use. Especially since the client code is published by Olvid, but to what extent can we know if it is 100% identical to the version distributed in the iOS and Android app stores? We don’t really have a way of knowing.

    I know that Olvid promises one day to release the server as Open Source. What I’ve seen of the protocol, their business model, and what they say about their implementation, very tied to the Amazon infrastructure (an infrastructure managed by an American company, so much for sovereignty), makes me think that this will not happen, at least not for a very long time. I hope, of course, to be wrong.

    Toward Openness and Collaboration in Digital Communication

    In the meantime? I would really like us to be serious about instant messaging, that finally all players in the sector row in the same direction, those who work on open protocols, offering free servers and clients, that we build real collaboration, worthy of the construction of internet protocols, to build the foundation of a universal, open, open-source and truly interoperable messaging service. It doesn’t take much, to develop the culture of “coopetition,” collaboration around a common good between competing companies.


    Found a mistake? I’m not perfect and would be happy to correct it. Contact us!

    — Photo by Steve Johnson on Unsplash

    The post Instant Messaging: Protocols are “Commons”, Let’s Take Them Seriously first appeared on ProcessOne .
    • Pl chevron_right

      ProcessOne: Instant Messaging: Protocols are “Commons”, Let’s Take Them Seriously

      news.movim.eu / PlanetJabber • 20 December 2023 • 8 minutes

    TLDR;

    Thirty years after the advent of the first instant messaging services, we still haven’t reached the stage where instant messaging platforms can freely communicate with each other, as is the case with email. In 1999, the Jabber/XMPP protocol was created and standardized for this purpose by the Internet Engineering Task Force (IETF). Since then, proprietary messaging services have continuously leveraged the power of internet giants to dominate the market. Why do neither XMPP nor the more recent Matrix, which aimed to improve upon it, break through this barrier, when it’s clear that protocols must be open to enable exchange? Without this fundamental principle, the Internet itself wouldn’t exist.

    In the following article, I revisit how the French government recently promoted the instant messaging service Olvid and what this reveals about our approach to digital technology. It’s frustrating to see France promote a secure, yet proprietary messaging service that offers no progress in terms of interoperability, especially at a time when the European Union is striving to open up the sector by requiring all messaging services to be capable of intercommunication, through the Digital Markets Act .

    I conclude with reflections on our inability in Europe to collaborate on “commons,” our difficulty in building a foundation, an ecosystem that allows for healthy co-opetition, a blend of competition and collaboration, which is the only way to regain significance in the digital economy. Short-term political thinking forces our companies into an every-man-for-himself approach, preferring to dominate a small market rather than share a larger one.

    Today, perhaps, it’s time for a change?

    Cables

    Thirty years and counting since the emergence of the first instant messaging services, we still lack a universally accepted exchange protocol, as is the case with email. The Jabber protocol, later renamed XMPP (eXtensible Messaging and Presence Protocol) and made a standard, was born with the hope of breaking the proliferation of isolated silos like MSN, ICQ, Yahoo!, which did not communicate with each other. Today, other silos have emerged, but the problem persists: it is still impossible to exchange messages between accounts from different major messaging providers. Why? Let me tell you the story of a clumsy communication operation around a French messaging service, Olvid, which illustrates well the familiar patterns we often find ourselves stuck in.

    The French Government’s Endorsement of a Proprietary Messaging Service: A Closer Look

    I discovered the messaging service Olvid in late November 2023, following a flood of articles in the French press. I wondered how a company of 15 employees, created in 2019, had managed to get such press coverage. It was promoted directly by Prime Minister Elisabeth Borne: “Popular messaging applications like WhatsApp, Telegram or Signal have ‘security flaws’,” justified the office of Elisabeth Borne, who urged her ministers to download the French application.” ( Les Échos, November 30, 2023 ). In November 2023, Matignon asked government members and ministerial offices to install this system on their phones and computers “to replace other instant messaging services to enhance the security of exchanges.” Then came the superlatives: “The most secure messaging service in the world” (Jean-Noël Barrot). “A step towards greater French sovereignty” (Elisabeth Borne). And it needs to be done quickly. Elisabeth Borne asked ministers to “take all necessary steps” to deploy Olvid in their ministry “by December 8, 2023, at the latest” ( Ouest France , November 29, 2023).

    Why Olvid? The articles I read on the subject remain relatively vague; I know mainly that it is certified by ANSII, the organization guaranteeing the state’s IT security. Yet, it’s far from the first secure messaging service I’ve come across, and it’s the first time I’ve heard of Olvid. What about other services and especially Signal, which is recognized worldwide for its security, backed by audits? Among secure messengers, the list is long: Signal, Threema, Wire, Berty, etc. So, what security flaws are we talking about?

    Signal Hits Back: A Strong Response to Security Claims

    Signal’s response was swift, with a direct and clear position from Meredith Whittaker, president of the Signal Foundation:

    The French PM is mandating ministers use a small French messaging app. OK. But I’m alarmed that she’s claiming “security flaws” in Signal (et al) to justify the move. This claim is not backed by any evidence, and is dangerously misleading esp. coming from gov.
    If you want to use a French product go for it! But don’t spread misinfo in the process. Signal is independently audited, open source, and our protocol has been tested for >10yrs. We are serious about responsible disclosure and we prioritize all reports to security@signal.org
    Numérama, December 1, 2023

    Double Ratchet

    Regarding Olvid’s security, the main argument seems to be as follows: The system does not rely on centralized directories, operates without identifiers, which means no user account is hosted in the cloud.

    First, it seems to me that this is the principle of key-based authentication. Message routing is done solely based on a key, in the cryptographic sense. If it is lost, it’s impossible to recover the account. Nothing revolutionary, then; it’s cryptography, dating back to the encryption software PGP (Pretty Good Privacy) of the 1990s and even before.

    Then, such a system generally requires the physical exchange of public keys. Where Olvid seems to stand out is in the alternative ways proposed to simplify and lighten the burden of key exchange by meeting physically. This can work, first because the product is not free, so the user base is limited, where Signal, for example, offers a global platform and says it needs an identifier, the phone number to limit spam. Then, these alternative methods rely on mobile device management (MDM) tools, interfacing with an enterprise version of the Olvid server. In one way or another, this goes through a central point of distribution and reintroduces a weakness. It’s far from a completely decentralized protocol like what the team building the Berty messaging service is trying to do, for instance.

    Browsing their site to find the protocol, I admit I choked a bit on some mentions thrown a little freely on their site, for example, Post Quantum Cryptography , cryptography that resists quantum computing. It’s nice, it’s pleasant, but in practice, what’s the reality? I didn’t find more detail under this mention, but personally, being hit with such buzzwords makes me rather flee, as it smells of a commercial who got a bit carried away. But let’s assume, the Olvid team is composed of encryption experts. I skimmed their specifications, but I admit I’m not a mathematician, so who am I to judge their math formulas?

    What I do understand, however, is that almost all secure messaging systems, including Olvid, rely on the Double Ratchet algorithm, which was first introduced by… Signal.

    At the Heart of Messaging: The Critical Role of Protocols

    In terms of protocol, however, I am an expert. I have been working on instant messaging protocols since 1999. And, it’s not beautiful… Olvid’s protocol is the antithesis of what I would like to see in an ambitious messaging protocol. It is a proprietary, ad hoc protocol, not based on any standard, minimalist for now, and condemns itself to reinventing the wheel, poorly. The burning question is, why not choose an open protocol that already works on a large scale, like XMPP, adding their value on top? The Internet protocol, TCP/IP, is open, all machines in the world can communicate, yet there are competing internet service providers. I am still looking for an answer. Because XMPP is too complex, some will say? I think any sufficiently advanced chat protocol tends to become a derivative of XMPP, less accomplished. Come on, why not even use Matrix, a competing protocol to my favorite? Apart from simple ignorance, I see no reason. Unless it’s to lock down the platform, perhaps? But, locking a communication protocol makes no sense. It’s replaying the battle of internet protocols, TCP/IP versus X.25. A communication protocol is meant to be open and interoperable. Personally, I would invite Olvid to adopt a messaging standard. Let them turn to the W3C or IETF, to XMPP or MLS. These organizations do good work. And it’s a guarantee of sustainability and above all, of interoperability.

    We come to a very sore point. The European Commission, and therefore France as well, is discussing the implementation of the Digital Market Act. Among the points the European Union wants to impose is… the interoperability of instant messaging services. How can the French government promote a messaging solution that is not interoperable? And preferably standardized and open.

    I talked about Olvid’s proprietary protocol, which is actually more of an API (Application Programming Interface), that is, a document that describes how to automate certain functions of their server. What about the implementation? The client is open source (on iOS and Android), but seeing in their exchange interface calls to URLs named /Freetrial. This implies payment. I am not sure that Olvid would welcome the idea of compiling and deploying one’s own version of the client. That’s the principle of Open Source, but such an initiative could try to circumvent payments to Olvid. As anyway, no open-source server is available and the only one running is operated by Olvid, the client code is of little use. Especially since the client code is published by Olvid, but to what extent can we know if it is 100% identical to the version distributed in the iOS and Android app stores? We don’t really have a way of knowing.

    I know that Olvid promises one day to release the server as Open Source. What I’ve seen of the protocol, their business model, and what they say about their implementation, very tied to the Amazon infrastructure (an infrastructure managed by an American company, so much for sovereignty), makes me think that this will not happen, at least not for a very long time. I hope, of course, to be wrong.

    Toward Openness and Collaboration in Digital Communication

    In the meantime? I would really like us to be serious about instant messaging, that finally all players in the sector row in the same direction, those who work on open protocols, offering free servers and clients, that we build real collaboration, worthy of the construction of internet protocols, to build the foundation of a universal, open, open-source and truly interoperable messaging service. It doesn’t take much, to develop the culture of “coopetition,” collaboration around a common good between competing companies.


    Found a mistake? I’m not perfect and would be happy to correct it. Contact us!

    — Photo by Steve Johnson on Unsplash

    The post Instant Messaging: Protocols are “Commons”, Let’s Take Them Seriously first appeared on ProcessOne .
    • Pl chevron_right

      ProcessOne: Instant Messaging: Protocols are “Commons”, Let’s Take Them Seriously

      news.movim.eu / PlanetJabber • 20 December 2023 • 8 minutes

    TLDR;

    Thirty years after the advent of the first instant messaging services, we still haven’t reached the stage where instant messaging platforms can freely communicate with each other, as is the case with email. In 1999, the Jabber/XMPP protocol was created and standardized for this purpose by the Internet Engineering Task Force (IETF). Since then, proprietary messaging services have continuously leveraged the power of internet giants to dominate the market. Why do neither XMPP nor the more recent Matrix, which aimed to improve upon it, break through this barrier, when it’s clear that protocols must be open to enable exchange? Without this fundamental principle, the Internet itself wouldn’t exist.

    In the following article, I revisit how the French government recently promoted the instant messaging service Olvid and what this reveals about our approach to digital technology. It’s frustrating to see France promote a secure, yet proprietary messaging service that offers no progress in terms of interoperability, especially at a time when the European Union is striving to open up the sector by requiring all messaging services to be capable of intercommunication, through the Digital Markets Act .

    I conclude with reflections on our inability in Europe to collaborate on “commons,” our difficulty in building a foundation, an ecosystem that allows for healthy co-opetition, a blend of competition and collaboration, which is the only way to regain significance in the digital economy. Short-term political thinking forces our companies into an every-man-for-himself approach, preferring to dominate a small market rather than share a larger one.

    Today, perhaps, it’s time for a change?

    Cables

    Thirty years and counting since the emergence of the first instant messaging services, we still lack a universally accepted exchange protocol, as is the case with email. The Jabber protocol, later renamed XMPP (eXtensible Messaging and Presence Protocol) and made a standard, was born with the hope of breaking the proliferation of isolated silos like MSN, ICQ, Yahoo!, which did not communicate with each other. Today, other silos have emerged, but the problem persists: it is still impossible to exchange messages between accounts from different major messaging providers. Why? Let me tell you the story of a clumsy communication operation around a French messaging service, Olvid, which illustrates well the familiar patterns we often find ourselves stuck in.

    The French Government’s Endorsement of a Proprietary Messaging Service: A Closer Look

    I discovered the messaging service Olvid in late November 2023, following a flood of articles in the French press. I wondered how a company of 15 employees, created in 2019, had managed to get such press coverage. It was promoted directly by Prime Minister Elisabeth Borne: “Popular messaging applications like WhatsApp, Telegram or Signal have ‘security flaws’,” justified the office of Elisabeth Borne, who urged her ministers to download the French application.” ( Les Échos, November 30, 2023 ). In November 2023, Matignon asked government members and ministerial offices to install this system on their phones and computers “to replace other instant messaging services to enhance the security of exchanges.” Then came the superlatives: “The most secure messaging service in the world” (Jean-Noël Barrot). “A step towards greater French sovereignty” (Elisabeth Borne). And it needs to be done quickly. Elisabeth Borne asked ministers to “take all necessary steps” to deploy Olvid in their ministry “by December 8, 2023, at the latest” ( Ouest France , November 29, 2023).

    Why Olvid? The articles I read on the subject remain relatively vague; I know mainly that it is certified by ANSII, the organization guaranteeing the state’s IT security. Yet, it’s far from the first secure messaging service I’ve come across, and it’s the first time I’ve heard of Olvid. What about other services and especially Signal, which is recognized worldwide for its security, backed by audits? Among secure messengers, the list is long: Signal, Threema, Wire, Berty, etc. So, what security flaws are we talking about?

    Signal Hits Back: A Strong Response to Security Claims

    Signal’s response was swift, with a direct and clear position from Meredith Whittaker, president of the Signal Foundation:

    The French PM is mandating ministers use a small French messaging app. OK. But I’m alarmed that she’s claiming “security flaws” in Signal (et al) to justify the move. This claim is not backed by any evidence, and is dangerously misleading esp. coming from gov.
    If you want to use a French product go for it! But don’t spread misinfo in the process. Signal is independently audited, open source, and our protocol has been tested for >10yrs. We are serious about responsible disclosure and we prioritize all reports to security@signal.org
    Numérama, December 1, 2023

    Double Ratchet

    Regarding Olvid’s security, the main argument seems to be as follows: The system does not rely on centralized directories, operates without identifiers, which means no user account is hosted in the cloud.

    First, it seems to me that this is the principle of key-based authentication. Message routing is done solely based on a key, in the cryptographic sense. If it is lost, it’s impossible to recover the account. Nothing revolutionary, then; it’s cryptography, dating back to the encryption software PGP (Pretty Good Privacy) of the 1990s and even before.

    Then, such a system generally requires the physical exchange of public keys. Where Olvid seems to stand out is in the alternative ways proposed to simplify and lighten the burden of key exchange by meeting physically. This can work, first because the product is not free, so the user base is limited, where Signal, for example, offers a global platform and says it needs an identifier, the phone number to limit spam. Then, these alternative methods rely on mobile device management (MDM) tools, interfacing with an enterprise version of the Olvid server. In one way or another, this goes through a central point of distribution and reintroduces a weakness. It’s far from a completely decentralized protocol like what the team building the Berty messaging service is trying to do, for instance.

    Browsing their site to find the protocol, I admit I choked a bit on some mentions thrown a little freely on their site, for example, Post Quantum Cryptography , cryptography that resists quantum computing. It’s nice, it’s pleasant, but in practice, what’s the reality? I didn’t find more detail under this mention, but personally, being hit with such buzzwords makes me rather flee, as it smells of a commercial who got a bit carried away. But let’s assume, the Olvid team is composed of encryption experts. I skimmed their specifications, but I admit I’m not a mathematician, so who am I to judge their math formulas?

    What I do understand, however, is that almost all secure messaging systems, including Olvid, rely on the Double Ratchet algorithm, which was first introduced by… Signal.

    At the Heart of Messaging: The Critical Role of Protocols

    In terms of protocol, however, I am an expert. I have been working on instant messaging protocols since 1999. And, it’s not beautiful… Olvid’s protocol is the antithesis of what I would like to see in an ambitious messaging protocol. It is a proprietary, ad hoc protocol, not based on any standard, minimalist for now, and condemns itself to reinventing the wheel, poorly. The burning question is, why not choose an open protocol that already works on a large scale, like XMPP, adding their value on top? The Internet protocol, TCP/IP, is open, all machines in the world can communicate, yet there are competing internet service providers. I am still looking for an answer. Because XMPP is too complex, some will say? I think any sufficiently advanced chat protocol tends to become a derivative of XMPP, less accomplished. Come on, why not even use Matrix, a competing protocol to my favorite? Apart from simple ignorance, I see no reason. Unless it’s to lock down the platform, perhaps? But, locking a communication protocol makes no sense. It’s replaying the battle of internet protocols, TCP/IP versus X.25. A communication protocol is meant to be open and interoperable. Personally, I would invite Olvid to adopt a messaging standard. Let them turn to the W3C or IETF, to XMPP or MLS. These organizations do good work. And it’s a guarantee of sustainability and above all, of interoperability.

    We come to a very sore point. The European Commission, and therefore France as well, is discussing the implementation of the Digital Market Act. Among the points the European Union wants to impose is… the interoperability of instant messaging services. How can the French government promote a messaging solution that is not interoperable? And preferably standardized and open.

    I talked about Olvid’s proprietary protocol, which is actually more of an API (Application Programming Interface), that is, a document that describes how to automate certain functions of their server. What about the implementation? The client is open source (on iOS and Android), but seeing in their exchange interface calls to URLs named /Freetrial. This implies payment. I am not sure that Olvid would welcome the idea of compiling and deploying one’s own version of the client. That’s the principle of Open Source, but such an initiative could try to circumvent payments to Olvid. As anyway, no open-source server is available and the only one running is operated by Olvid, the client code is of little use. Especially since the client code is published by Olvid, but to what extent can we know if it is 100% identical to the version distributed in the iOS and Android app stores? We don’t really have a way of knowing.

    I know that Olvid promises one day to release the server as Open Source. What I’ve seen of the protocol, their business model, and what they say about their implementation, very tied to the Amazon infrastructure (an infrastructure managed by an American company, so much for sovereignty), makes me think that this will not happen, at least not for a very long time. I hope, of course, to be wrong.

    Toward Openness and Collaboration in Digital Communication

    In the meantime? I would really like us to be serious about instant messaging, that finally all players in the sector row in the same direction, those who work on open protocols, offering free servers and clients, that we build real collaboration, worthy of the construction of internet protocols, to build the foundation of a universal, open, open-source and truly interoperable messaging service. It doesn’t take much, to develop the culture of “coopetition,” collaboration around a common good between competing companies.


    Found a mistake? I’m not perfect and would be happy to correct it. Contact us!

    — Photo by Steve Johnson on Unsplash

    The post Instant Messaging: Protocols are “Commons”, Let’s Take Them Seriously first appeared on ProcessOne .
    • Pl chevron_right

      Isode: Red/Black – 2.1 New Capabilities

      news.movim.eu / PlanetJabber • 13 December 2023 • 3 minutes

    Overview

    This release adds important new functionality and adds further device drivers to Red/Black, a management tool that allows you to monitor and control devices and servers across a network, with a particular focus on HF Radio Systems.  A general summary is given in the white paper Red/Black Overview .

    Rules

    Red/Black 2.1 adds a Rules capability that allows rules to be specified in the Lua programming language, which allows flexible control.    Standard rules are provided along with sample rules to help creation of rules useful for a deployment.  There are a number of rule capabilities:

    • A basic rule capability is control based on device parameter values.   Rules can generate alerts, for example to alert at operator at selected severity when a message queue exceeds a certain size.
    • For devices with parameters that clearly show faults or exception status,  standard device type rules are provided that will alert the operator to the fault condition.   This standard rule can be selected for devices of that type.
    • Rules can set parameters on devices, including control of device actions.   For example, this can be used to turn off  a device when a thermometer device records a high temperature.
    • Rules can reference devices connected in the communications chain.  For example a rule can be created to alert an operator if the frequency used on a radio does not match the supported frequency range of a connected antenna.
    • Rules can be used to reconfigure (soft) connectivity, for example to switch in a replacement device when a device fails.

    Snapshot

    Configuration snapshots can be taken, reflecting the current Red/Black configuration, and Red/Black configuration can be reset to a snapshot. The capability is intended to record standard operational status of a setup to allow convenient reversion after temporary changes.

    eLogic Radio Gateway driver

    The eLogic Radio Gateway provides conversion between synchronous serial and TCP, with multiple convertors in a single SNMP-managed box.  A key target for this is data connectivity to remote Tx/Rx sites.  The Red/Black driver enables configuration as TCP to Serial and Serial to TCP modes, enabling a Red/Black operator to change selected modem/radios.

    Web (http) Drivers

    Red/Black 2.1 has added an internal Isode framework for managing devices with an HTTP interface, which is being used in a number of new drivers.  This is Isode’s preferred approach for managing devices.   New drivers are:

    1. M-Link.   Allows monitoring of M-Link servers, showing:
      1. Number of connected users.
      2. Number of peer connections.
      3. Number of queued stanzas.
    2. Icon-5066.  Controlling  STANAG 5066 product:
      1. Enable/Disable node
      2. Show STANAG 5066 Address
      3. Show Number connected SIS clients
      4. Show If flow is on or off
    3. Icon-PEP.  Providing:
      1. Enable/Disable service
      2. Show number of TCP connections
      3. Show current transfer rate
    4. Sodium Sync.   Providing:
      1. Number of synchronizations
      2. Last synchronization that made changes
      3. List of synchronizations not working correctly
      4. Alerts for failed synchronizations
    5. Supported Modems.   This replaces drivers working directly with modems included in Icon-5066 3.0.   The new driver talks directly to Proxy Modem or to Icon-5066 where Proxy Modem is not used.  This displays a wide range of modem parameters.   Various modem types can be selected to display appropriate information from the connected device:
      1. Narrowband Modem.
      2. Narrowband Modem with ALE.
      3. Wideband Modem.
      4. Modem/Radio combined variants of the previous three types.

    Other

    • Parameter Encryption.   Red/Black can securely store parameters, such as passwords, to prevent exposure as command line arguments to device drivers.
    • Device Ordering.   Devices are now listed in alphabetical order.
    • Alert Source.  Alerts now clearly show where they are generated (Red/Black; Rule; Device Driver; Device).
    • Link to device management.   Where Red/Black monitored devices have Web management, the URL of the Web interface can be configured in Red/Black so that the management UI can be accessed with single click from Red/Black.
    • Pl chevron_right

      Isode: Red/Black – 2.1 New Capabilities

      news.movim.eu / PlanetJabber • 13 December 2023 • 3 minutes

    Overview

    This release adds important new functionality and adds further device drivers to Red/Black, a management tool that allows you to monitor and control devices and servers across a network, with a particular focus on HF Radio Systems.  A general summary is given in the white paper Red/Black Overview .

    Rules

    Red/Black 2.1 adds a Rules capability that allows rules to be specified in the Lua programming language, which allows flexible control.    Standard rules are provided along with sample rules to help creation of rules useful for a deployment.  There are a number of rule capabilities:

    • A basic rule capability is control based on device parameter values.   Rules can generate alerts, for example to alert at operator at selected severity when a message queue exceeds a certain size.
    • For devices with parameters that clearly show faults or exception status,  standard device type rules are provided that will alert the operator to the fault condition.   This standard rule can be selected for devices of that type.
    • Rules can set parameters on devices, including control of device actions.   For example, this can be used to turn off  a device when a thermometer device records a high temperature.
    • Rules can reference devices connected in the communications chain.  For example a rule can be created to alert an operator if the frequency used on a radio does not match the supported frequency range of a connected antenna.
    • Rules can be used to reconfigure (soft) connectivity, for example to switch in a replacement device when a device fails.

    Snapshot

    Configuration snapshots can be taken, reflecting the current Red/Black configuration, and Red/Black configuration can be reset to a snapshot. The capability is intended to record standard operational status of a setup to allow convenient reversion after temporary changes.

    eLogic Radio Gateway driver

    The eLogic Radio Gateway provides conversion between synchronous serial and TCP, with multiple convertors in a single SNMP-managed box.  A key target for this is data connectivity to remote Tx/Rx sites.  The Red/Black driver enables configuration as TCP to Serial and Serial to TCP modes, enabling a Red/Black operator to change selected modem/radios.

    Web (http) Drivers

    Red/Black 2.1 has added an internal Isode framework for managing devices with an HTTP interface, which is being used in a number of new drivers.  This is Isode’s preferred approach for managing devices.   New drivers are:

    1. M-Link.   Allows monitoring of M-Link servers, showing:
      1. Number of connected users.
      2. Number of peer connections.
      3. Number of queued stanzas.
    2. Icon-5066.  Controlling  STANAG 5066 product:
      1. Enable/Disable node
      2. Show STANAG 5066 Address
      3. Show Number connected SIS clients
      4. Show If flow is on or off
    3. Icon-PEP.  Providing:
      1. Enable/Disable service
      2. Show number of TCP connections
      3. Show current transfer rate
    4. Sodium Sync.   Providing:
      1. Number of synchronizations
      2. Last synchronization that made changes
      3. List of synchronizations not working correctly
      4. Alerts for failed synchronizations
    5. Supported Modems.   This replaces drivers working directly with modems included in Icon-5066 3.0.   The new driver talks directly to Proxy Modem or to Icon-5066 where Proxy Modem is not used.  This displays a wide range of modem parameters.   Various modem types can be selected to display appropriate information from the connected device:
      1. Narrowband Modem.
      2. Narrowband Modem with ALE.
      3. Wideband Modem.
      4. Modem/Radio combined variants of the previous three types.

    Other

    • Parameter Encryption.   Red/Black can securely store parameters, such as passwords, to prevent exposure as command line arguments to device drivers.
    • Device Ordering.   Devices are now listed in alphabetical order.
    • Alert Source.  Alerts now clearly show where they are generated (Red/Black; Rule; Device Driver; Device).
    • Link to device management.   Where Red/Black monitored devices have Web management, the URL of the Web interface can be configured in Red/Black so that the management UI can be accessed with single click from Red/Black.
    • Pl chevron_right

      Isode: Red/Black – 2.1 New Capabilities

      news.movim.eu / PlanetJabber • 13 December 2023 • 3 minutes

    Overview

    This release adds important new functionality and adds further device drivers to Red/Black, a management tool that allows you to monitor and control devices and servers across a network, with a particular focus on HF Radio Systems.  A general summary is given in the white paper Red/Black Overview .

    Rules

    Red/Black 2.1 adds a Rules capability that allows rules to be specified in the Lua programming language, which allows flexible control.    Standard rules are provided along with sample rules to help creation of rules useful for a deployment.  There are a number of rule capabilities:

    • A basic rule capability is control based on device parameter values.   Rules can generate alerts, for example to alert at operator at selected severity when a message queue exceeds a certain size.
    • For devices with parameters that clearly show faults or exception status,  standard device type rules are provided that will alert the operator to the fault condition.   This standard rule can be selected for devices of that type.
    • Rules can set parameters on devices, including control of device actions.   For example, this can be used to turn off  a device when a thermometer device records a high temperature.
    • Rules can reference devices connected in the communications chain.  For example a rule can be created to alert an operator if the frequency used on a radio does not match the supported frequency range of a connected antenna.
    • Rules can be used to reconfigure (soft) connectivity, for example to switch in a replacement device when a device fails.

    Snapshot

    Configuration snapshots can be taken, reflecting the current Red/Black configuration, and Red/Black configuration can be reset to a snapshot. The capability is intended to record standard operational status of a setup to allow convenient reversion after temporary changes.

    eLogic Radio Gateway driver

    The eLogic Radio Gateway provides conversion between synchronous serial and TCP, with multiple convertors in a single SNMP-managed box.  A key target for this is data connectivity to remote Tx/Rx sites.  The Red/Black driver enables configuration as TCP to Serial and Serial to TCP modes, enabling a Red/Black operator to change selected modem/radios.

    Web (http) Drivers

    Red/Black 2.1 has added an internal Isode framework for managing devices with an HTTP interface, which is being used in a number of new drivers.  This is Isode’s preferred approach for managing devices.   New drivers are:

    1. M-Link.   Allows monitoring of M-Link servers, showing:
      1. Number of connected users.
      2. Number of peer connections.
      3. Number of queued stanzas.
    2. Icon-5066.  Controlling  STANAG 5066 product:
      1. Enable/Disable node
      2. Show STANAG 5066 Address
      3. Show Number connected SIS clients
      4. Show If flow is on or off
    3. Icon-PEP.  Providing:
      1. Enable/Disable service
      2. Show number of TCP connections
      3. Show current transfer rate
    4. Sodium Sync.   Providing:
      1. Number of synchronizations
      2. Last synchronization that made changes
      3. List of synchronizations not working correctly
      4. Alerts for failed synchronizations
    5. Supported Modems.   This replaces drivers working directly with modems included in Icon-5066 3.0.   The new driver talks directly to Proxy Modem or to Icon-5066 where Proxy Modem is not used.  This displays a wide range of modem parameters.   Various modem types can be selected to display appropriate information from the connected device:
      1. Narrowband Modem.
      2. Narrowband Modem with ALE.
      3. Wideband Modem.
      4. Modem/Radio combined variants of the previous three types.

    Other

    • Parameter Encryption.   Red/Black can securely store parameters, such as passwords, to prevent exposure as command line arguments to device drivers.
    • Device Ordering.   Devices are now listed in alphabetical order.
    • Alert Source.  Alerts now clearly show where they are generated (Red/Black; Rule; Device Driver; Device).
    • Link to device management.   Where Red/Black monitored devices have Web management, the URL of the Web interface can be configured in Red/Black so that the management UI can be accessed with single click from Red/Black.