I watch a lot of YouTube videos. So much, that it starts to annoy me, how much of my free time I’m wasting by watching (admittedly very interesting) clips of a broad range of content creators.

Logging out of my Google account helped a little bit to keep my addiction at bay, as it appears to prevent the YouTube algorithm, which normally greets me with a broad set of perfectly selected videos from recognizing me. But then again I use Google to log in to one service or another, so it became annoying to log in and back out again all the time. At one point I decided to delete my YouTube history, which resulted in a very bad prediction of what videos I might like. This helped for a short amount of time, but the algorithm quickly returned to its merciless precision after a few days.

Today I decided, that its time to leave Google behind completely. My Google Mail account was used only for online shopping anyways, so I figured why not use a more privacy respecting service instead. Self-hosting was not an option for me, as I only have a residential IP address on my Raspberry Pi and also I heard that hosting a mail server is a huge pain.

A New Mail Account

So I created an account at the Berlin based service mailbox.org. They offer emails plus some cloud stuff like an office suite, storage etc., although I don’t think I’ll use any of the additional services (oh, they offer an XMPP account as well :P). The service is not free as in free beer as it costs 1€ per month, but that’s a fair price in my opinion. All in all it appears to be a good replacement for all the Google stuff.

As a next step, I went through the long list of all the websites and shops that I have accounts on, scouting for those services that are registered on my Google Mail address. All those mail settings had to be changed to the new account.

Mail Extensions

Bonus Tipp: Mailbox.org has support for so called Mail Extensions (or Plus Extensions, I’m not really sure how they are called). This means that you can create a folder in your inbox, lets say “fsfe”. Now you can change your mail address of your FSFE account to “username+fsfe@mailbox.org”. Mails from the FSFE will still go to your “username@mailbox.org” mail account, but they are automatically sorted into the fsfe inbox. This is useful not only to sort mails by sender, but also to find out, which of the many services you use messed up and leaked your mail address to those nasty spammers, so you can avoid that service in the future.

This trick also works for Google Mail by the way.

Deleting (most) the Google Services

The last step logically would be to finally delete my Google account. However, I’m not entirely sure if I really changed all the important services over to the new account, so I’ll keep it for a short period of time (a month or so) to see if any more important mails arrive.

However, I discovered that under the section “Delete Services or Account” you can see a list of all the services which are connected with your Google account. It is possible to partially delete those services, so I went ahead and deleted most of it, except Google Mail.

Additional Bonus Tipp: I use NewPipe on my phone, which is a free libre replacement for the YouTube app. It has a neat feature which lets you import your subscriptions from your YouTube account. That way I can still follow some of the creators, but in a more manual way (as I have to open the app on my phone, which I don’t often do). In my eyes, this is a good compromise

I’m looking forward to go fully Google-free soon. I de-googled my phone ages ago, but for some reason I still held on to my Google account. This will be sorted out soon though!

De-Googling your Phone?

By the way, if you are looking to de-google your phone, Mike Kuketz has a great series of blog posts about that topic (in German though):

• Android ohne Google: Take back control! Teil 1
• LineageOS: Take back control! Teil 2

Happy Hacking!

I have closed a few ui and Muc related issues. You should start to see regular iOS and Mac public betas rolling out again this week. I hope to have the next Monal release next week. OMEMO was a big update and but I am planning on getting back into the bi-weekly release schedule. Most of the changes are small tweaks and bug fixes related to the UI and UX. This will be my focus for a while rather than new technical features.

@gdt wrote:

The Ignite Realtime community is happy to announce the immediate release of version 1.3.9 of the REST API plugin for Openfire!

The REST API plugin provides the ability to manage Openfire by sending an REST/HTTP request to the server.

This update fixes an issue with incompatibility when installed on Openfire 4.2.

Your instance of Openfire should automatically display the availability of the update in the next few hours. Alternatively, you can download the new release of the plugin at the REST API plugin archive page.

For other release announcements and news follow us on Twitter .

Posts: 1

Participants: 1

Read full topic

@gdt wrote:

The Ignite Realtime community is happy to announce the immediate release of version 1.2.1 of the CallbackOnOffline plugin for Openfire!

The CallbackOnOffline plugin will detect when messages are sent to offline users, and instead sends an HTTP POST request to a pre-defined address with the details of the message as a JSON body.

This update fixes an issue with incompatibility when installed on Openfire 4.3.

Your instance of Openfire should automatically display the availability of the update in the next few hours. Alternatively, you can download the new release of the plugin at the CallbackOnOffline plugin archive page.

For other release announcements and news follow us on Twitter.

Posts: 1

Participants: 1

Read full topic

We recently announced our intention to become a Facebook-free business. We are happy to report that all our Facebook Pages have now been permanently deleted, and all Facebook widgets and buttons have been removed from our websites.

But it wasn’t our first step towards minimising corporate surveillance for our users. In fact, for several years now on all our websites we have a rule to avoid external resources (like public CDNs), avoid externally linked scripts and not use excessive tracking technologies.

Our ProcessOne homepage uses a single session cookie. Our WordPress blog doesn’t create any cookies or use local storage at all. Currently, the only external script and tracking technology we use comes from, you guessed it, google-analytics.com. However, even upon implementing Google Analytics (GA), we made a choice to minimise its impact on our users.

We modified the script to disable IP detection, disable cookies and local storage, and distinguish our visitors just by a custom fingerprint that is useless to GA scripts on other sites and domains. This way, our users can’t be tracked from site to site. The customisations are based on this cookieless-google-analytics repo I cooked up back in 2014.

However, as you may imagine, Google goes to some lengths to make this anonymisation process difficult. On our new XMPP, MQTT & SIP realtime platform called Fluux we wanted to implement the latest version of the GA script. However, the so called gatag.js has removed some of the useful customisation options I mentioned earlier.

For example, you can’t fully disable cookies or local storage. This decision was probably made by the same person who decided that YouTube embeds from youtube-nocookie.com domain store all of the old-school cookies inside the local storage. Technically, it’s indeed nocookie, but in fact it’s still tracking users, with values named like yt-remote-device-id…

In the end, we decided to keep the previous, cookie-less version of the GA script. Additionally, we removed the YT embed in favour of an inline base64-encoded JPG. We are also testing Vimeo embeds in our blog posts. They do use cookies, but they increase overall decentralisation.

When browsing ProcessOne sites and services, you can be sure we spent a significant amount of time to minimise what we collect, or do not track you at all. Because we care about your privacy as we care about our own.

It’s very hard to stay untracked while browsing the web. Google, Facebook and many others have their business models based on extensive tracking. But a lot of fault lies on us, the Webmasters, for using seemingly helpful and time-saving technologies that are brilliant and free – but are they? In the end, if we are not careful, we pay with our data, and the data of our users. And all the nasty consequences that come with it.

We can change that state, one site at a time, with just a little bit of effort and cooperation. We can minimise the exposure of our users. We can switch to locally stored code and customised scripts. We can do more. We can do better.

Marek Foss
Webmaster at ProcessOne

@Flow wrote:

The Ignite Realtime developer community is happy to announce the availability of Smack 4.3.3.

Please have a look at the Changelog for a list of fixes and improvements. As with all patchlevel releases of Smack, it can act as drop in replacement for previous Smack 4.3 release because there are no API changes.

We like to thank everyone who contributed by reporting bugs or giving suggestions. Special thanks goes to people who contributed code:

$ git shortlog -sn 4.3.1..4.3.2
    19  Florian Schmaus
     1  Georg Lukas

More information about how to use the 4.3 release series can be found one the Smack 4.3 README.

Posts: 1

Participants: 1

Read full topic

Have you ever tried to use Mnesia with datasets larger than your transient memory? Are you confused with Erlang data types stored within Mnesia? We know some of you were. That is why we answered these problems by introducing something that is familiar to mainstream developers and also efficient with larger datasets at the same time - i.e. RDBMS backends for our PubSub plugin. Now, lets bundle that up with full support for XEP-0178, as well as, a RabbitMQ backend for our Event Pusher for a more complete package. Ladies and gentlemen welcome MongooseIM version 3.3.0.

Relations meet PubSub

The Publish-Subscribe plugin was one of our main focal points for recent weeks thanks to our friends from Safaricom Alpha, who have sponsored this work. The rationale behind implementing it is simple, and yet not obvious, so let’s dig in.

The XMPP protocol features an extension called Personal Eventing Protocol which is a special case of PubSub, where any entity (e.g. a user) may become a PubSub node. In turn, this can be used for many purposes. For instance, a client may publish information to its contacts about the music currently being played. Alternatively, it may announce microblog entries (e.g. personal Twitter). Nevertheless, end to end encryption is the thing of importance to us and many of MongooseIM users in regard to PEP.

End to end encryption is often a selling point for many pieces of modern IM software. For example, the popular TLS encryption ensures that nobody will be able to eavesdrop on your communication with a bank website. Of course, there are many more properties but the crucial fact remains: it secures the data you exchange with the server. Therefore, when you connect to MongooseIM with TLS enabled your transmission is safe. You have to bear in mind that everything you write is still readable on the server side and if you would like to improve your privacy even further - you need to encrypt your message content as well.

There are several protocols you can use to achieve it, but in most cases, you will need a way to announce public data (e.g. public key) that others may use to establish a secure session with your device. This is where PEP comes in. It provides a facility for storage and distribution that can hold, for instance, OMEMO keys and metadata to your contacts.

Since this data is retrieved and updated fairly often, we have realised that a classic Mnesia backend is no longer sufficient for this purpose and we have put a lot of work into developing an efficient RDBMS backend for PubSub. Besides performance in high volume scenarios, it allows developers to use databases other than Mnesia, ones they are more familiar with.

During the development, we have been also able to pinpoint bottlenecks in the core PubSub code. That is why we have the parallelised distribution of PubSub messages.The pre-3.3 extension used only a single Erlang process to handle all requests, as well as, the broadcasts triggered by them. Currently, the notification distribution is done by a new, short-lived process for every request. Requests themselves are still processed in a single queue - since parallel execution led to transaction deadlocks in Mnesia - but the extension may be configured to process them in several queues. That fixes the issue we have observed on several occasions, where the PubSub process was simply overwhelmed with messages with no reasonable overflow control and back pressure what greatly impaired user experience.

Standardised PKI

Password-based authentication is still a basic method in many places. Why? Try remembering your RSA 4096-bit public key, not to mention the whole public+private key pair. (yes, we know about Keepass; but you most probably have it configured to use a master password, right?)

The PKI authentication is the current industry standard though. It is more secure than a private-public key pair and, if implemented properly, much more convenient for the average user to use. Support for this method debuted in MongooseIM 2.2.x and received a batch of improvements in every subsequent release. This one adds one of the last important pieces i.e. compliance with XEP-0178, which is an official PKI authentication method specification for XMPP. It describes how the SASL EXTERNAL mechanism should behave. In other words, it describes which certificate fields should be used in the process and how.

Pre-3.3 implementation verified only the Common Name field, while now it verifies xmppAddr fields (there may be more than one such field) with CN optionally used as a fallback. What is more, a full JID is verified instead of just the username.

Integration with RabbitMQ

The Event Pusher extension emerged in MongooseIM 2.1.x as a unification of several channels that our server used to deliver data to external endpoints - e.g. delivering user messages to a push notifications service. It has been extended over time and in MIM 3.3 it receives yet another backend: RabbitMQ.

It is especially beneficial for developers who need to digest IM events in an asynchronous manner. Since AMQP is a popular, powerful and pretty easy to learn protocol, it may be used to build a spam detection component. Events published via RabbitMQ may also be consumed for big data analysis (finding patterns in user preferences, behaviour etc.). These are only 2 examples. We imagine that every application may find innovative uses for a stream of events coming in from MongooseIM. What is more, using another Erlang-based piece of software ensures the reliability and performance of this tandem.

Consider the demo of the spam detection mechanism below to be an inspiration for you.

Changelog

Please feel free to read the detailed changelog. Here, you can find a full list of source code changes and useful links. Contributors Special thanks to our contributors: Test our work on MongooseIM 3.3.0 and share your feedback

1. Help us improve the MongooseIM platform:
2. Star our repo: esl/MongooseIM
3. Report issues: esl/MongooseIM/issues
4. Share your thoughts via Twitter
5. Download Docker image with new release
6. Sign up to our dedicated mailing list to stay up to date about MongooseIM, messaging innovations and industry news.
7. Check out our MongooseIM product page for more information on the MongooseIM platform.

The Web was born 30 years ago. We all know that it has changed the world, even more deeply than smartphones.

However, while it is time to celebrate it is also a good time to think about its future and how we can protect its core values. The Web was designed is universal, interoperable, open, decentralized, accessible, royalty-free and privacy-friendly.

Here is a short video I recorded to celebrate the 30th anniversary of the Web, but also understand the threats to its values and share some tips about what you can do to help protect it.

Last year, ProcessOne as a company and myself as an individual, both signed the Contract for the Web. This is a great starting point to learn more about the Web core values.

Here are other interesting links I mentioned in the video:

• Tim Berners Lee’s original proposal: Information Management: A Proposal
• The first website: info.cern.ch
• The Birth of the Web
• IndieWeb
• Solid
• Donate to Mozilla

Since the last release of our enterprise-ready, highly scalable IM platform: MongooseIM 3.1, the team has been working at full speed on the expanded set of features and improvements aimed to bring MongooseIM to the next level. What comes as a result is MongooseIM 3.2. With its highlights such as full-featured Inbox, worker pool unification, PKI for BOSH and Websockets and multi-aspect TLS integration, this release becomes a big step in the evolution of our server!

What we love about MongooseIM 3.2 ?!

The latest iteration of MongooseIM not only introduces exclusive and uncommon solutions, such as the advanced inbox or multi-aspect TLS integration, it also becomes more and more open to new angles in providing a full-fledged messaging solution, that responds to global market demands.

Among the highlights of the 3.2 release, there is another bundle of Inbox improvements. The most significant one is the possibility to attach unread messages count to push notifications so application badge may be updated appropriately. Our full-featured Inbox now gets more and more mature, becoming a complete extension for virtually every chat application!

We also added PKI for BOSH and Websockets, allowing web XMPP clients to authenticate with TLS certificate.

This version certainly makes devops’ life easier. Unified worker pools, provided in 3.2, enable much more convenient and consistent configuration of outgoing connections (e.g. to databases). They also grant better stability, predictability, and inspection of their behavior.

Meet our Inbox

Inbox in MongooseIM 3.2 received a couple of nice improvements but one of them is particularly important: integration with the Event Pusher. Among other things, this component is responsible for delivering push notifications data to MongoosePush and other services, and using it with inbox opens up some new possibilities. One example would be simplifying incrementing the unread count (the “badge”) which up until now was hardcoded to “1” and required extra effort from the frontend team when trying to display the real number of notifications. Push notifications implementation was unable to access this information at the moment of event delivery and the client application had to work around this and risk being inaccurate.

With the new update, a valid number is always attached to push notifications so the applications may display it in a simple, natural and precise manner. MongooseIM 3.2 introduces a number of updates that should make your client development team much happier. All inbox query results include total unread messages count and the number of “active” (with at least one unread message) conversations. A client may also filter explicitly for active conversations only.

We would like to present our new Inbox demo, showcasing three of the newly added features:

1. Unread messages counter implemented for push notifications
2. New filtering option - a user may choose to query for conversations with unread messages only
3. Extended error description - error messages readability is improved.

Examples in the demo are prepared with the Forward application.

Worker pools - unite!

When you take a look at MongooseIM 3.1 - Inbox got better, testing got easier you may notice an inconspicuous paragraph “Worker pool unification”. This small internal improvement expanded into one of the most satisfying cleanups in MongooseIM in recent history. It affects not only the server’s inner workings but also changes the way pools are configured.

Until 3.1.x (included) the config schema varied between multiple connection types:

1. For RDBMS there was an odbc_server key (misleading, right?) with several unlabeled elements (you had to remember their order or use docs). Pool size was defined under separate key. Oh, right, there was yet another key to define the pool names alone. And you couldn’t define common pool for all XMPP domains.
2. For HTTP, we had an http_connections key. Pool size was provided as one of key-value pairs.
3. For Cassandra you could specify the pool size as well. As one of cassandra_servers tuple elements. And so on…

You can clearly see that various aspects of configuration (how pool size was provided, was the pool global or per-host) were inconsistent and could lead to confusion.

In 3.2 these connections are governed by a dedicated server logic, which in future will allow us to expose generic metrics or implement extra debugging tools. Configuration-wise, all of these tuples have been replaced with outgoing_pools list, where every element follow simple convention: {Type, Host, Tag, PoolOpts, ConnectionOpts}. Type resolves to one of implemented pool specifications, such as rdbms, riak or http. Host indicates if there should be only one pool for all XMPP domains, separate pools for every XMPP domain or just one pool for one of the domains. Tag is a name that can be referenced in specific extensions. It allows to e.g. have separate RDBMS pools for write and read operations. PoolOpts are pool-centric options, such as worker count or worker selection strategy. ConnectionOpts are items specific to the chosen connection driver.

Our work here is still not finished. We would like to leverage the common logic even further. It is possible to create more interesting metrics. We also plan to make existing extensions more flexible, as currently many of them use hardcoded pool tags or even hosts. It is a temporary state so you may expect it to improve in future releases!

Certificates everywhere

Security is paramount whether we are talking enterprise or not. SASL EXTERNAL authentication mechanism was introduced in MongooseIM 2.2. As a reminder: it allows XMPP clients to authenticate with TLS certificates (without extra password). It was originally implemented only for raw TCP connections so web clients could not benefit from this feature. MongooseIM 3.2 extends this method’s capabilities and now it may be used with Websocket (wss://) and BOSH (https://) connections.

PKI authentication is the current industry standard in terms of secure authentication, so MongooseIM 3.2 brings this feature to a whole new audience.

Other improvements

MongooseIM 3.2, just like previous releases, includes many (non-)technical improvements. A large part of them is purely internal or developer-focused. See the changelog to read about all of them. Here are some highlights!

Migration guide

We all know that it’s a good idea to always keep your software up to date. One exception is a certain OS which may suddenly remove all of your data after the automatic upgrade. In our effort to steadily improve MongooseIM’s quality, intuitiveness and feature set, sometimes bold changes have to be made. We are aware that sometimes adjusting config file or custom code base may not be that straightforward.

For all of these users, who always stick to the most recent release of MongooseIM, we’ve created a Migration Guide section in our documentation. Each page will describe what needs to be changed to migrate between subsequent versions. The current chapter is “3.1.1 to 3.2” and it may be found here: https://mongooseim.readthedocs.io/en/latest/migrations/3.1.1_3.1.1++/

mongooseim.cfg

As a part of our effort to improve consistency in our source code and the repository, we have changed the name of MongooseIM’s main config file from ejabberd.cfg to mongooseim.cfg. It is definitely more intuitive. However, existing projects, which deploy MongooseIM releases with custom scripts, may need to have their pipelines updated.

Changelog

Please feel free to read the detailed changelog. Here, you can find a full list of source code changes and useful links.

Contributors

Special thanks to our contributors: @getong @igors @justinba1010

Test our work on MongooseIM 3.2 and share your feedback

Help us improve the MongooseIM platform:

1. Star our repo: esl/MongooseIM
2. Report issues: esl/MongooseIM/issues
3. Share your thoughts via Twitter: @MongooseIM
4. Download Docker image with new release
5. Sign up to our dedicated mailing list to stay up to date about MongooseIM, messaging innovations and industry news.
6. Check out our MongooseIM product page for more information on the MongooseIM platform.

Everyone who knows and uses XMPP is probably aware of a new player in the game. Matrix.org is often recommended as a young, arising alternative to the aging protocol behind the Jabber ecosystem. However the founders do not see their product as a direct competitor to XMPP as their approach to the problem of message exchanging is quite different.

An open network for secure, decentralized communication.

matrix.org

During his talk at the FOSDEM in Brussels, matrix.org founder Matthew Hodgson roughly compared the concept of matrix to how git works. Instead of passing single messages between devices and servers, matrix is all about synchronization of a shared state. A chat room can be seen as a repository, which is shared between all servers of the participants. As a consequence communication in a chat room can go on, even when the server on which the room was created goes down, as the room simultaneously exists on all the other servers. Once the failed server comes back online, it synchronizes its state with the others and retrieves missed messages.

Matrix in the French State

Olm, Megolm – What’s the deal?

Matrix introduced two different crypto protocols for end-to-end encryption. One is named Olm, which is used in one-to-one chats between two chat partners (this is not quite correct, see Updates for clarifying remarks). It can very well be compared to OMEMO, as it too is an adoption of the Signal Protocol by OpenWhisperSystems. However, due to some differences in the implementation Olm is not compatible with OMEMO although it shares the same cryptographic properties.

The other protocol goes by the name of Megolm and is used in group chats. Conceptually it deviates quite a bit from Olm and OMEMO, as it contains some modifications that make it more suitable for the multi-device use-case. However, those modifications alter its cryptographic properties.

Comparing Cryptographic Building Blocks

Protocol	Olm	OMEMO (Signal)
IdentityKey	Curve25519	X25519
FingerprintKey⁽¹⁾	Ed25519	none
PreKeys	Curve25519	X25519
SignedPreKeys⁽²⁾	none	X25519
Key Exchange Algorithm⁽³⁾	Triple Diffie-Hellman (3DH)	Extended Triple Diffie-Hellman (X3DH)
Ratcheting Algoritm	Double Ratchet	Double Ratchet

1. Signal uses a Curve X25519 IdentityKey, which is capable of both encrypting, as well as creating signatures using the XEdDSA signature scheme. Therefore no separate FingerprintKey is needed. Instead the fingerprint is derived from the IdentityKey. This is mostly a cosmetic difference, as one less key pair is required.
2. Olm does not distinguish between the concepts of signed and unsigned PreKeys like the Signal protocol does. Instead it only uses one type of PreKey. However, those may be signed with the FingerprintKey upon upload to the server.
3. OMEMO includes the SignedPreKey, as well as an unsigned PreKey in the handshake, while Olm only uses one PreKey. As a consequence, if the senders Olm IdentityKey gets compromised at some point, the very first few messages that are sent could possibly be decrypted.

In the end Olm and OMEMO are pretty comparable, apart from some simplifications made in the Olm protocol. Those do only marginally affect its security though (as far as I can tell as a layman).

Megolm

The similarities between OMEMO and Matrix’ encryption solution end when it comes to group chat encryption.

OMEMO does not treat chats with more than two parties any other than one-to-one chats. The sender simply has to manage a lot more keys and the amount of required trust decisions grows by a factor roughly equal to the number of chat participants.

Yep, this is a mess but luckily XMPP isn’t a very popular chat protocol so there are no large encrypted group chats ;P

So how does Matrix solve the issue?

When a user joins a group chat, they generate a session for that chat. This session consists of an Ed25519 SigningKey and a single ratchet which gets initialized randomly.

The public part of the signing key and the state of the ratchet are then shared with each participant of the group chat. This is done via an encrypted channel (using Olm encryption). Note, that this session is also shared between the devices of the user. Contrary to Olm, where every device has its own Olm session, there is only one Megolm session per user per group chat.

Whenever the user sends a message, the encryption key is generated by forwarding the ratchet and deriving a symmetric encryption key for the message from the ratchets output. Signing is done using the SigningKey.

Recipients of the message can decrypt it by forwarding their copy of the senders ratchet the same way the sender did, in order to retrieve the same encryption key. The signature is verified using the public SigningKey of the sender.

There are some pros and cons to this approach, which I briefly want to address.

First of all, you may find that this protocol is way less elegant compared to Olm/Omemo/Signal. It poses some obvious limitations and security issues. Most importantly, if an attacker gets access to the ratchet state of a user, they could decrypt any message that is sent from that point in time on. As there is no new randomness introduced, as is the case in the other protocols, the attacker can gain access by simply forwarding the ratchet thereby generating any decryption keys they need. The protocol defends against this by requiring the user to generate a new random session whenever a new user joins/leaves the room and/or a certain number of messages has been sent, whereby the window of possibly compromised messages gets limited to a smaller number. Still, this is equivalent to having a single key that decrypts multiple messages at once.

The Megolm specification lists a number of other caveats.

On the pro side of things, trust management has been simplified as the user basically just has to decide whether or not to trust each group member instead of each participating device – reducing the complexity from a multiple of n down to just n. Also, since there is no new randomness being introduced during ratchet forwarding, messages can be decrypted multiple times. As an effect devices do not need to store the decrypted messages. Knowledge of the session state(s) is sufficient to retrieve the message contents over and over again.

By sharing older session states with own devices it is also possible to read older messages on new devices. This is a feature that many users are missing badly from OMEMO.

On the other hand, if you really need true future secrecy on a message-by-message base and you cannot risk that an attacker may get access to more than one message at a time, you are probably better off taking the bitter pill going through the fingerprint mess and stick to normal Olm/OMEMO (see Updates for remarks on this statement).

Note: End-to-end encryption does not really make sense in big, especially public chat rooms, since an attacker could just simply join the room in order to get access to ongoing communication. Thanks to Florian Schmaus for pointing that out.

I hope I could give a good overview of the different encryption mechanisms in XMPP and Matrix. Hopefully I did not make any errors, but if you find mistakes, please let me know, so I can correct them asap

Happy Hacking!

Sources

• Olm – A Cryptographic Ratchet
• Megolm Group Ratchet
• Implementing End-to-End Encryption in Matrix clients
• OMEMO Encryption
• The Double Ratchet Algorithm
• Extended Triple Diffie-Hellman Key Exchange

Updates:

Thanks for Matthew Hodgson for pointing out, that Olm/OMEMO is also effectively using a symmetric ratchet when multiple consecutive messages are sent without the receiving device sending an answer. This can lead to loss of future secrecy as discussed in the OMEMO protocol audit.

Also thanks to Hubert Chathi for noting, that Megolm is also used in one-to-one chats, as matrix doesn’t have the same distinction between group and single chats. He also pointed out, that the security level of Megolm (the criteria for regenerating the session) can be configured on a per-chat basis.

In this new series of videos on programming languages, I explain how to record and write HTTP tests in Go, thanks to HTTPMock library.

The HTTPMock library is available on Github. The example code from this video is also available on Github.

If you have any questions regarding HTTPMock or suggestions of topics for the next CodeCraft videos, please let us know in the comments below.

MQTT is one of the main protocol designed to power the Internet of Things. In this talk, I introduce the concepts being MQTT protocol design.

If you have any questions regarding MQTT or suggestions of topics for the next IoT Studio videos, please let us know in the comments below.

You can also check out IoT Studio #1: Internet of Things Explained.

ProcessOne curates two monthly newsletters – tech-focused Real-time Stack and business-focused Real-time Enterprise. Here are the articles concerning business aspects of real-time development we found interesting in Issue #20. To receive this newsletter straight in your inbox on the day it’s published, subscribe here.

Introducing Fluux: XMPP & MQTT as a Service

Today, we are rebranding and expanding our well-received ejabberd SaaS platform! The new name is Fluux, supporting both XMPP & MQTT, in the cloud, as a single service with a unique and simple business model.

Beginners Guide to MQTT

What is MQTT? MQTT is a lightweight publish/subscribe messaging protocol designed for M2M (machine to machine) telemetry in low bandwidth environments. It was designed by Andy Stanford-Clark (IBM) and Arlen Nipper in 1999 for connecting Oil Pipeline telemetry systems over satellite.

Internet of Things Trends and Challenges in 2019

A recent McKinsey study, “What separates leaders from laggards in the Internet of Things” found that only around one sixth of the world’s largest companies adopting IoT are seeing any kind of significant return on investment. New trends and business models are emerging, and the way we plan, envision, and discuss the IoT will likely change in 2019.

Artificial Intelligence Arms Race in 2019

Killer robots have arrived. Admittedly, these ‘lethal autonomous weapons’ are still a long way from superintelligence — AI in 2019 is closer to WALL-E than The Terminator. All the same, the…

Nokia Expands its WING Offering with IoT Applications for Operators to Address New Vertical Markets

Off-the-shelf, as-a-Service IoT solutions eliminate business and technology complexity for fast time-to-market for operators. Four new packages enable operators to rapidly address the agriculture, livestock management, logistics and asset management markets to drive new revenues.

What Does Open Source Mean in the Era of Cloud APIs?

One of the most interesting and unsurprising characteristics of conversations with organizations that have adopted one of the emerging hybrid or “non-compete” style of licenses is that they are universally insistent on being differentiated from one another.

Why Privacy is Important, and Having "Nothing to Hide" is Irrelevant

The governments of Australia, Germany, the UK and the US are destroying your privacy. Some people don’t see the problem… It doesn’t matter if you have “nothing to hide”.

Last weekend I went to an exhibit related to Leonardo da Vinci at the Demver Museum of Nature and Science. Amidst the reconstructions of his inventions and at the entrance to a whole room about the Mona Lisa I came across this quote: "Art is never finished, only abandoned." Although it's not clear to me if Leonardo actually said that (Vasari mentions something similar in his Life of Leonardo), I like the sentiment....

Part of my goal in writing an epitome of Aristotle's writings on personal excellence is to get closer to their original meaning, which I do by reflecting deeply on how to render crucial Greek words into English. Consider this cluster: τέλος, τελεία, τελειώτατον. In his book Aristotle on the Human Good, Richard Kraut translates them with variations on the English word "perfection". In present-day English, "perfect" has connotations of being absolutely without blemish; thus something perfect seems static and cold and unchanging, not dynamic and warm and living. I get a distinctly unworldly (dare I say Platonic?) feeling from Kraut's translation. Yet in Greek τέλος is something much simpler: the end-marker or finish-line of a racecourse. A τέλος is a goal; you can achieve a goal or complete a race, but you don't perfect a goal or perfect a race. Similarly with τελεία: Aristotle speaks of τελεία ἀρετή, which I would render as complete excellence (not "perfect virtue"). So also with τελειώτατον: in his analysis of εὐδαιμονία or living well Aristotle mentions that the highest goal of human action needs to be the most complete (not "most perfect") because if you could add anything more to it then there would be a more valuable goal. In all of these instances, I am tempted to find the idea of "completing" or "most completing" behind the scenes; in Aristotle's philosophy, the concept of ἐντελέχεια (becoming complete, achieving a goal, completing a task) is always central. And note that the task (ἔργον) you're working at (ἐνέργεια) is not imposed from outside but grows organically from within; Aristotle's teleology (that's that τέλος again) is not universal but particular, individual, personal. Thus my working title: Complete Yourself....

A new version 0.8.1 of the Java XMPP library has been released! It contains primarily bug fixes only, but also contains an important improvement of the thread usage, especially when using NIO connections.

Basically the library now shares thread pools with multiple sessions. Contrary to 0.8.0, this new feature combined with NIO now really sllows to run many simultaneous sessions. Thanks to David Bidorff for the ExecutorService implementation! But even without using NIO, the thread count should drastically decrease when using multiple sessions.

Everything else are bug fixes only and can be read here.

Welcome to the XMPP newsletter.

If you have an article, tutorial or blog post you'd like us to include in the newsletter, please submit it on the XMPP wiki.

News

FOSDEM

In the beginning of February was the annual FOSDEM19 conference in Brussels which was well attended by XMPP enthusiasts and where 5 different talks related to XMPP were held.

The videos for the FOSDEM presentations have been released:

• XMPP Beyond Instant Messaging

In this talk Jérôme Poisson (Goffi) shows how XMPP can be used to build non-IM applications, such as a blog engine, file sharing, a code forge, a universal remote controller and even a decentralized web framework on top of XMPP.

• Salut à Toi: A Python Based Social Network And More

Jérôme Poisson talks about Salut à Toi, a Python-based decentralized communication ecosystem which uses XMPP and offers a lot of features like chat, e2e encryption, file sharing, photo albums, events, (micro)blogging, forums, remote control, tickets, merge-requests and even a decentralized web framework.

• Make XMPP Sprint Again

Maxime Buquet (pep.) talks about how he organized the August 18-19th XMPP community sprint in Cambridge and gives useful advice to anyone interesting in organising community events such as development sprints.

• Unified Communications with Pàdé

Dele Olajide talks about Pàdé, a new unified communications solution from the ignite Real-time community that integrates protocols such as SIP, HTTP and XMPP into one desktop solution for text, voice and video communication.

• Converse: Open, federated teamchat with XMPP

JC Brand talks about Converse.js, a JavaScript XMPP chat client that runs in the browser and which saw lots of improvements in 2018, including a new fullscreen teamchat mode.

Subscribe to receive the next edition in your inbox

Other news

Process One have rebranded and expanded their ejabberd software-as-a-service platform and renamed it to Fluux.

The iOS and OS X client Monal, has been removed from the French app store because the developer can't distribute Monal with OMEMO in France without government approval.

The Monal push service has received an update intended to fix an interoperability bug with Ejabberd services.

Software releases

Clients

• Converse.js 4.1.1 and 4.1.2
• OpenFire Meetings 0.9.5
• OpenFire inVerse plugin 4.1.2
• Slixmpp-omemo first release

Servers

• Ejabberd 19.02 (nice writeup of what they call the MQTT edition).
• Tigase 8.0.0 RC1

Libraries

• Smack 4.3.2

This new ejabberd 19.02 release includes new major features, but also several improvements and bug fixes. The biggest news is the introduction of MQTT support.

Contributions

Several changes in this release were authored by our community contributors, and we would like to extend a big thank you for the contributions to: Holger Weiss, Christoph Scholz, Frank Diebolt, Paul Menzel, Nathan Bruning, Colm, and AquarHEAD Lou.

New features

MQTT support

We are pleased to announce that ejabberd Community Server now supports MQTT along XMPP and SIP protocols. It’s been a long process we started back in September with introduction of MQTT support in ejabberd Business Edition. Next, we published the RTB benchmarking tool that could massively stress test MQTT servers. Finally, we announced Fluux, a Software-as-a-Service cloud solution that offers scalable MQTT and XMPP without the need for your own infrastructure.

We believe you should be able to choose your preferred protocol specifically for the task at hand, and without the need of a complex, multi-software architecture. With ejabberd and its combined support of MQTT, XMPP and SIP, we hope to make realtime software development simpler, faster and even more scalable.

If you would like to enable MQTT support (mod_mqtt) on ejabberd, you can follow this documentation: ejabberd MQTT support

MQTT support in ejabberd benefits from all the code infrastructure in place in ejabberd for clustering, plugins, etc. For example, the authentication mechanism is the same. Leveraging 16 years of work on our clustering engine and optimization of our stack, our MQTT server is able to reach millions of concurrent online users and is already among the top most scalable MQTT servers available.

With XMPP, MQTT and SIP support, ejabberd is now able to handle all your realtime traffic in a single package. ejabberd is already the most widely used XMPP server in the world. Our ambition is to reach the same trust with MQTT.

You can expect more bridges between protocols, and more cross-protocol integrations in the coming releases.

MIX updates

The updates to mod_mix fixed submission-id and channel resource. Furthermore, the MIX implementation is now updated to reflect the new specification.

New MIX version should help you build simplified group messaging services, as an alternative to MucSub

Allow specifying tag for listener for api_permission purposes

It is possible to add tags to http listeners:

listener:
  - port: 4000
  - module: ejabberd_http
  - tag: "magic_listener"

That later can be used to have special api_permission just for it:

api_permissions:
  "magic_access":
    from:
      - tag: "magic_listener"
    who: all
    what: "*"

Download and install ejabberd 19.02

The source package and binary installers are available at ProcessOne. If you installed a previous version, please read ejabberd upgrade notes.

As usual, the release is tagged in the Git source code repository on Github. If you suspect that you’ve found a bug, please search or fill a bug report in Issues.

---

Push for Monal has worked flawlessly for me for about a year now. However I also heard it didn’t work reliably for everyone. This was not something that I was able to replicate. After a lot of help from others we were able to identify the issue as something specifically odd about the interaction between ejabberd servers and the prosody server that powers push for Monal. This issue with the prosody module appears to have been fixed and I have upgraded my push server.

In theory this server side change should fix push for everyone and there is no app upgrade necessary. Please let me know if you are still experiencing push issues.

@guus wrote:

The Ignite Realtime community is happy to announce the immediate release of version “4.1.2 release 1” of the inVerse plugin for Openfire!

The inVerse plugin adds a Converse-based web client to Openfire (Converse is a third party implementation).

This update includes an update of the converse.js library (to version 4.1.2), which brings an important stability fix, as well as various other improvements.

Your instance of Openfire should automatically display the availability of the update in the next few hours. Alternatively, you can download the new release of the plugin at the inVerse plugin archive page.

For other release announcements and news follow us on Twitter

Posts: 17

Participants: 4

Read full topic

@Flow wrote:

The Ignite Realtime developer community is happy to announce the availability of Smack 4.3.2.

This is a patchlevel release which contains mostly bugfixes. Please have a look at the Changelog. As with all patchlevel releases of Smack, it can act as drop in replacement for previous Smack 4.3 release because there are no API changes.

We like to thank everyone who contributed by reporting bugs or giving suggestions. Special thanks goes to people who contributed code:

$ git shortlog -sn 4.3.1..4.3.2
    25  Florian Schmaus
     3  Georg Lukas
     1  Tairs Rzajevs
     1  asokolov

More information about the 4.3 release can be found one the release’s Readme.

Posts: 1

Participants: 1

Read full topic

ProcessOne curates two monthly newsletters – tech-focused Real-time Stack and business-focused Real-time Enterprise. Here are the articles concerning tech aspects of real-time development we found interesting in Issue #20. To receive this newsletter straight in your inbox on the day it’s published, subscribe here.

Introducing Fluux: XMPP & MQTT as a Service

Today, we are rebranding and expanding our well-received ejabberd SaaS platform! The new name is Fluux, supporting both XMPP & MQTT, in the cloud, as a single service with a unique and simple business model.

Distributing prebuilt Go binaries on Github with Gox

Building command-line tools with Go is quite handy as it allows building standalone static binary. This is quite easy to build ready-to-use binaries for distribution. The author wanted to be able to produce ready-made binaries to make the tools more accessible.

The perfect ejabberd setup with ansible

In April last year the author set up the kaidan.im XMPP server with ejabberd. He did that completely manually, so first running apt get, then editing the config file and so on. But that just wasn’t good enough.

How to install MQTT broker on AWS for free

MQTT is a connectivity protocol specially designed for machine-to-machine or Internet of Things. If you have read our previous post where we create an MQTT broker with a Raspberry Pi, then you might understand the concept a bit more. However, there are some drawbacks with the Pi.

Extracting web page metadata with mget

When exploring archives coming from online services for my Data Portability Kit project, one of the most common and basic tasks the author was confronted with was to analyse and fix URLs-related content. URLs form the basic building bricks of the Web.

ActivityPub: final thoughts, one year later

Almost exactly one year ago, the author published a blog post with lots of detail why he deemed ActivityPub not suitable for implementation as the base federation layer in diaspora* at that time. Over the course of last year, he have received multiple requests for a follow-up. Here it is.

Tuya-Convert: escaping the IoT cloud, no solder need

Entrepreneurs seeking a manufacturing partner to produce their smart home devices will quickly come across a Chinese company called Tuya. After paying a fee of 1500 USD, clients can put together their new smart home portfolio on Tuya’s website with just a few clicks.

Why we need to slow time and scale down

Om Malik writes: “I wore my Grand Seiko for almost 300 days last year – whether I was going to work, staying at home, out for coffee, or on a photo adventure. In other words, it went through some serious abuse and the leather strap paid the price. It became grimy and frayed.”

In Book V of the Eudemian Ethics [1], Aristotle discusses the excellences of thinking things through (ἀρεταί διανοετικαί, usually translated as "the intellectual virtues"), in contrast to the excellences of character or ἀρεταί ἠθικαί. Recently I wrote about the more practical of the two primary excellences of thought: φρόνησις (which I translate as "wisdom"). Here I take a first glance at the more theoretical of the two: σοφία....

After many months of reading Aristotle's philosophy and commentary thereon, recently I decided to re-read Ayn Rand's essay "The Objectivist Ethics", wherein Rand criticizes Aristotle for not considering ethics to be an exact science. I have no idea what that would mean. Consider, for instance, the relevant Wikipedia page (not necessarily reliable, but often a good start), which states:...