Planet Jabber

May 24, 2019

Monal IM

Password Change

Coming in iOS 3.8 is in app password change and registration. Password changing works but needs some better UI feedback.

by Anu at May 24, 2019 19:40

Jérôme Poisson

SàT progress note 2019-W21

Hi,

this week has seen a bit of work on the website (mostly porting pages from the older one), and again the time to work on the project was short.

When your work on your free time, any moment you take for yourself (a week-end outside, reading a book/newspaper, watching a movie, having a drink, doing sport, etc.), or for the "things which must be done" (cleaning house, administrative things, fixing stuffs, etc.), or simply when you are sick, is time lost for the project, and it goes quickly. I'm living in such spirit for more than 10 years, feeling remorse for everything taking time, and it's not healthy or even sane, not for your nor your loved ones. And even in your project itself, there are a lot of stuff you have do to around it (server administration, website, documentation, communication – like progress notes –, keeping up to date with technologies, etc.) which are not directly improving the software.

I'm explaining this for you, the reader, to understand why it takes so long to develop a project, and why it can get on nerves. You can see now with the progress notes, that the release is nearly ready but still I've had little time to fix issues, and I wont be able to have everything perfectly oiled for this release.

Last week I've mentioned Pubsub, so let's move to this topic.

I won't elaborate on Pubsub itself, just for short Publish/Subscribe is a way to store/get data and to be notified when there are changes. You can see my talk at last FOSDEM (mp4 version) for some use cases. It is notably used in XMPP for blogging, i.e. for the "social network" part of it, and in SàT for events, tickets, merge requests, forums, etc.

During implementation of blogging features in SàT, years ago, the Pubsub implementations in XMPP servers were uneven, and mostly incomplete (because it was not needed for chat which most of the clients were focusing on). There was two options to work around that: choose a server with a working implementation, focus on it and recommend it, that's what have done Jappix and Movim with Metronome, or create a server agnostic component. We have chosen the latter with SàT, and have created "SàT Pubsub", a server independent implementation of PEP/Pubsub, which aims to be the most complete possible.

I've had to write and propose 2 XEPs (XEP-0355 and XEP-0356) to make this possible, but I'll pass the details to avoid making this post too long. Also, this would have hardly be possible without the work of Ralph Meijer which made the base Pubsub implementation in its library Wokkel that we use in top of Twisted, and Idavoll that SàT Pubsub derivate from.

So we now have an independent Pubsub implementation where we can implement everything we need without having to wait for every server to follow some new XEP. And even today when XMPP servers implementations have improved a lot, SàT Pubsub has some unique features, can follow novelties quickly, and is a good place for experimentation. I don't think all server implementations can be on a par with that, at least in the close future.

With that background explained, I'll now explain what I've worked on this week. In standard Pubsub (XEP-0060) when you have the suitable right, you can publish an item (a blog post for instance) with an existing id, this will create a new item and delete the one which was existing previously. But if we have a node where many people can publish, like a blog comment node, that means that anybody can replace the comment of anybody. So if Louise has written something, Pierre can replace the comment, not great.

In some pubsub implementations, which is the case for SàT Pubsub, you can't overwrite an item if you are not the publisher of this item, except if you are admin or owner of the node. That's better regarding blog comments, but there is still an issue: if Louise is owner of a node, and overwrite an item of Pierre, to modify something, she become the new publisher of the item, and Pierre can't modify it anymore. This is notably a problem with tickets: if Pierre report a bug, and Louise changes its status (e.g. because she starts working on the ticket), she becomes the new publisher, and Pierre can't edit it anymore).

To work around that, I've added a new node option which can be activated in configuration, "consistent publisher", which will keep the original publisher even if the item is overwritten (updated) if the entity overwriting the item is owner or admin. I've also prepared an option in database to restrict the maximum number of items in a node, but it's not implemented yet. I can now safely change status of reported issues for SàT without loosing initial publishers.

This week the post was longer than usual, I'll try to keep it shorter next time. As usual, feedbacks are welcome.

by goffi at May 24, 2019 07:45

May 22, 2019

Monal IM

iOS 3.7 Change list

The near final 3.7 beta should be going out to testers right now. This is what will change in the next release.

  1. Fixed OMEMO session creation errors on some servers
  2. Fixed performance with attachment downloading
  3. Fixed wrong/older image being shown in chat cells
  4. Added ability to set nick names on contacts
  5. Added a photo browser for conversation images
  6. Show full name and not JID on notifications
  7. Fixed bug that might cause duplication of sent messages
  8. Notifications now have image previews
  9. Fixed a bug that wrongly showed messages as failed to send
  10. Fixed a bug that didn’t update messages when retrying
  11. Reduced network and battery use
  12. Fixed a bug that caused a disconnect loop in certain network conditions

by Anu at May 22, 2019 15:23

Image Browser

New for 3.7 is the image browser. Similar to other apps, you can now go into contact details and view all of the images in your conversation. I’ll add the ability to clear these out and manage space in the future.

by Anu at May 22, 2019 03:21

May 20, 2019

Monal IM

Why do I have so many accounts?

If you have talked to me on XMPP you will notice that I often switch accounts. I keep four active accounts, two accounts on two different server platforms each that I test with the most (Prosody and ejabberd). I am a big fan of dogfooding, as in using my own product to see where the pain points are for users. This is often what spurs me to go in and fix something seemingly random. It annoys me.

I originally stated the end goal of this app was to be a replacement for expensive SMS plans. That was a decade ago, I now want to have a respectable open source alternative to WhatsApp and Facebook Messenger. This current iteration of Monal will be “done” when someone can just tell their family and friends to contact them on Monal. You shouldn’t have to explain much else. If you do then there is something to fix. This often requires me to find a balance on default settings that preserve privacy but cause the least amount of friction for users. I know from experience (and a decade of metrics I’ve collected) that every additional screen in setup causes a a large drop off in users. Every additional exposure to the of the inner workings of XMPP (e.g. the roster, online/offline e.g.) causes people say this isn’t user friendly and drop off. If you are wondering what the product direction for Monal on iOS is, it is a balance between secure and private and simple. This may be infuriating at times to other people who are techies but bear with me, if we can get more people to use XMPP, it is better for everyone.

There are about 25,000 devices using the Monal push sever at the moment. The good news is there have been very few errors on the server and my AWS instances have been able to handle this traffic without problems. This also provides me with a lot of data points for the effectiveness of push. For most people it near 100% reliable. I am trying to nail down some issues with notifications. I think I have found issues on both prosody and ejabberd’s push modules and will file bugs to work with the developers. They are two different issues, prosody servers seem to send hundreds of extra pushes and will drain your battery (this is especially true if you have group chats, which is how I found this). The battery drain at times is pretty terrible. On an iPhone X it was using 20% of my battery at least and was running for 14 hrs in the background. Ejabberd in comparison uses maybe 1% battery in a day with a few min in the background. Interestingly the bug I have found in ejabberd is the opposite, occasionally, for example at night, when there is a prolonged period of inactivity, some pushes do not arrive and there isn’t a notification for the message.

If you want to help me test things out, feel free to send messages to any of these addresses:

My Prosody test accounts:

anurodhp@jabb3r.org

anu@yax.im

My Ejabberd test accounts:

anurodhp@blabber.im

anu.pokharel@conversations.im

by Anu at May 20, 2019 14:33

ProcessOne

Real-time Enterprise Issue #21

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 #21. To receive this newsletter straight in your inbox on the day it’s published, subscribe here.

30th Anniversary of the Web: Understanding its Core Values

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.

Getting Ready for Real-Time Decisioning

There is no end in sight to the growing amounts of data in today’s digital world. By 2020, analysts project there will be 6 billion smartphones and 50 billion telematics devices as an ever-increasing number of people access the internet and devices go online to communicate in a connected world.

Scotiabank Implements Real-Time Wire Tracking for Business Customers

Through this development, Scotiabank becomes the first Canadian bank to offer this self-service tracking tool. The functionality leverages SWIFT’s Global Payments Initiative. This enables Scotiabank business customers to track their wire payments in real-time.

StellaService Raises $11M For Real-Time Customer Feedback

The company helps customer support teams analyze and improve performance in real time. With the new API-powered platform, customer service representatives receive immediate feedback from customers through a digestible, social media-like user interface.

IoT Study Reveals Increasing Maturity

That’s the findings of Vodafone’s latest IoT Barometer study. As the global leader of Internet of Things infrastructure with nearly 81 million connections, Vodafone surveyed 1,758 businesses across the globe.

Five Ways to Incorporate IoT in Small Business

Now that consumers are more excited about IoT, the focus is switching gears toward business applications for IoT. And, while there are applications for industrial and commercial use, small business owners may be wondering if this is the time to invest in IoT.

Tech firms ramp up efforts to woo the energy industry

Amazon, Google and Microsoft see old industrial giants as a new source of income. Energy companies are keen to produce oil and gas more efficiently, as they grapple with volatile prices and uncertain long-term demand. Digital investments promise to cut costs and boost output.

by Marek Foss at May 20, 2019 14:26

Monal IM

Notification Names and Image Previews

As I’ve mentioned in the past, a focus of Monal development going forward is going to be improving the UI/UX. I have been thoroughly modernizing many components of the app that have been largely untouched for years. Notifications and image handling is one of them. This is how I added the aesgcm: encrypted link support as well as grouped notifications. Building on that, I have updated notifications to show a preview of the image (which is transparently decrypted in the background) as well as showing the senders name instead of the JID.

by Anu at May 20, 2019 02:53

May 18, 2019

Monal IM

Low Flying Fruit: Nicknames

Something people have requested for a while, the ability to set a nick name on your contacts so that the JID isn’t what everyone sees.

by Anu at May 18, 2019 02:01

May 17, 2019

Debian XMPP Team

Debian XMPP Team Starts a Blog

The Debian XMPP Team, the people who package Dino, Gajim, Mcabber, Movim, Profanity, Prosody, Psi+, Salut à Toi, Taningia, and a couple of other packages related to XMPP a.k.a. Jabber for Debian, have this blog now. We will try to post interesting stuff here — when it's ready!

by Martin at May 17, 2019 23:30

Jérôme Poisson

SàT progress note 2019-W20

Little progress during this week, I've had a busy week-end far from computer (and it's a relief from time to time to be freed from screen).

I'm working mainly on the new website, so I'll explain a bit why doing a new website.

When you have a project, the website is the place people go to know what it is, and SàT is a quite difficult project to explain because it's doing a lot of things, and people get lost easily with it. We are now using the term "communication ecosystem" to explain it, as it seems to fit well: a generic tool for most of your communication needs (chat, file sharing, blog, events, etc.).

We have done current website a while ago using Django, which is one of the most popular web framework on Python (and even outside Python). Django is a great piece of software and has a huge community, but working on the official website with it means that we have to learn, maintain and follow extra technologies. Note that I'm using "we" because we are several people at the association, but I'm currently the only active developer and any extra amount of work is hard to take.

On the other hand, 0.7 version of SàT brings a web framework, based on the ecosystem and so on XMPP. That has many advantage: notably there is nothing new to learn and follow, and it's a concrete use case which allow to test and improve the ecosystem.
Furthermore, the XMPP integration allows to integrate effortlessly things like the official blog, while in the former version we had to include a page of Libervia in a <iframe>.

To summarize, moving the official website on Libervia web framework make the task more easy and is an occasion to test and improve the whole ecosystem.

One of the things that has been improved in the last few months is the integration of a task system, i.e. a way to launch piece of code on certain conditions (in particular if some files are changed), something similar to what you would have with Grunt, for instance, in Javascript world.
This is used to generate SàT documentation, using Sphinx to create HTML page from reStructuredText: when Libervia is launched with --dev-mode, each time the doc is modified, the HTML pages are rebuilt, really handy to check quickly that the syntax gives what you're expecting.

The new official website will be simple, with only a small page of presentation of the software, the documentation, social contract, and few extra pages. Most of it is done, and now I'm porting some pages from Django (the template system is similar to Jinja2 that we use, but it still needs adaptations, and the CSS classes are not the same).

During this, I'm also fixing bugs when I see them or somebody reports them. For instance, I've fixed this week a bug with registration on https://www.libervia.org. If you test any part of the ecosystem (being it desktop or mobile with Cagou, web with Libervia, TUI with Primitivus or CLI with jp), please give feedback either on our chat room (web), or via the SàT/XMPP based ticket system at https://bugs.goffi.org.

I was going to explain some changes I need to do on SàT Pubsub but this post is already long enough, I guess I'll keep it for next week (wow, teasing!).

by goffi at May 17, 2019 10:13

May 16, 2019

Monal IM

Progress on OMEMO and Push

There are several bug fixes coming in the next release. I have been working in improving OMEMO and i think I have identified the issue preventing some people from starting new sessions. I am also fixing performance issues in the image handling introduced by the aesgcm links. After those are resolved I will add support for sending aesgcm links for attachments. In the process of looking at performance I have noticed higher then expected battery use when connected to some prosody servers. I hope to work with the server side developers to figure out whats going on there. Generally speaking it appears to me to be due to push notifications sent for more than just new messages. I am also testing with ejabberd to see if there is a problem there as well. Genreally speaking though I believe that XEP-0357 that defines how this is supposed to work is flawed and needs to be updated. It is very trusting and does not give the actual app developer the ability to regulate pushes based on the capabilities of his app. A few minor changes to the specification would let us make something that can compete with the experience of proprietary chat clients.

by Anu at May 16, 2019 13:57

May 15, 2019

Peter Saint-Andre

Aristotle Research Report #10: σχολή

In Nicomachean Ethics X.7, Aristotle mentions almost in passing that "we engage in unleisured pursuits so that we may be at leisure" (1177b5). In Politics Book VIII, where he discusses the role of music in human life, he expands on this idea:...

May 15, 2019 00:00

May 11, 2019

Arnaud Joset

The rise of the machine

Hurrah !

After months of work on the Agayon, I can present some significant improvements ! This article is a little bit longer than the previous ones but it worth the read!

Software updates !

During the past few weeks, the code base of the Agayon has been updated. I forked my own project, r1d2 to update it. The new repository is named r1d3. I hesitated a long time before forking it. As the hardware base of the Agayon completely changed, I preferred to change the code name to maintain coherence between hardware and software.

The update aims to provide

  • Python 3 support only
  • OpenCV 4 support for
    • Face recognition
    • Sign tracking
    • Face/hand detection and tracking
  • Better XMPP ad hoc support
  • I2C support
  • Hardware switches support.

XMPP Ad hoc commands

As I made tests with SLeekXMPP to control the bot, I observed some problems with Gajim. The Ad-Hoc extension allows one to send commands to an XMPP bot. R1D3 displays the following menus and submenus (in french):

menu1 menu2 menu3

When I try to use the "execute" button, SleekXMPP start a new session and Gajim complains that the session identifier has changed. I reported the problem to SleekXMPP and its fork SliXMPP. The XMPP community is great and Maxime Buquet responded quickly. To quote him, there are two problems (see the bug report for the whole explanations):

  • Slixmpp shouldn't assume execute is the start of a command
  • I don't see a place in the XEP that says that next or execute can be equivalent to complete. What to do?

He sent an email on the "Standards" mailing list and some responses followed. It seems difficult to fix the protocol at the moment without breaking compatibility. Maxime proposed a patch to fix Slixmpp and it should work on SleekXMPP. For now, I just don't use the "Execute" button as "Forward" does the job. The depreciation of the "Execute action" is actually discussed.

New hardware !

The Agayon has now 8 LEDs and 6 switches. They are placed on a control panel.

The LEDs aim to provide status information

  • 5V power (orange)
  • Pi powered up (green)
  • I2C on the Arduino (green)
  • I2C + serial on the Pi (green)
  • Serial communication (green, Arduino)
  • Video capture (red)
  • Internet connection (blue)
  • LIDAR mapping (red)

The switches aim to provide

  • Power on (12V) (Ebay)
  • Start R1D3 (MCHobby)
  • On/Off Demo mode (Arduino) (Ebay)
  • On/Off Power down (Pi) (Ebay
  • Emergency stop (cut Arduino power) (Ebay)
  • Movie recording (Pi)

In addition, the following hardware are also mounted to provide information and input/output. I2C addresses are displayed (0Xxx)

The documentation of the SHT71 explains why the sensor has no I2C adress.

The serial interface of the SHT7x is optimized for sensor readout and effective power consumption. The sensor cannot be addressed by I2C protocol, however, the sensor can be connected to an I2C bus without interference with other devices connected to the bus. Microcontroller must switch between protocols.

One ground to rule them all

I have been advised to use an epoxy base coated with a copper layer. The aim is to connect it to the negative pole of the battery. It is really useful because it decrease the wiring. The perfboards are fixed on metallics spacer bars to avoid shortcuts.

plate1

I2C Scans

I²C is a bus communication that allows multiple device to communicate with each other.

I2C devices are recognized by the Arduino (5V) and the Raspberry PI (3.3V) with the help of a level shifter.

I've used the I2C scanner provided by the Arduino documentation.

Arduino

Scanning...
I2C device found at address 0x1D  !
I2C device found at address 0x20  !
I2C device found at address 0x6B  !
I2C device found at address 0x70  !
done

Raspberry PI

user$ i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- 1d -- --
20: 20 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- 6b -- -- -- --
70: 70 -- -- -- -- -- -- --

Gallery

"Scaffolding" with hot glue

During the past few months, my best friend has been my hot glue gun. I was skeptical at first but really much effective and fun. I used it to insulate some connectors. In Liège, we would say "mettre une noquette de colle" which translates to "put a knob of glue".

glue1 glue3

capot2 capot3

Evolution of the frame

full_base connection_base_capot

complete_1

complete_3 complete_4

  • A : Battery
  • B : Level shifter between Arduino (5V) and Raspberry Pi (3.3V)
  • C : Arduino Mega
  • D : Power lines and I2C (12V, 5 V, 3.3V, SDA 5V, SCL 5V, SDA 3.3V, SCL 3.3V)
  • E : Raspberry Pi (in his case)
  • F : Buttons and their pull down (3.3V or 5V depending on the GPIO)
  • G : LEDs

New (old) Oscilloscope

One of my colleague has been cleaning his lab, and he asked me if I was interested to have an old 20 MHz oscilloscope. I gladly accepted. It is a 34 years old Circuitmate 9020 (bought in 1985). I will use it for I2C debugging and visualization. oscillo

Conclusion

The hardware is almost done. I am happy to have a nice reliable base. I hope to be able to drive it with my smartphone soon. I will continue the programming to add the mapping functionality and a nice demo mode.

Stay tuned !

smile

by Arnaud at May 11, 2019 18:00

Ignite Realtime Blog

Spark - Developers needed

@wroot wrote:

You might have noticed that last official release of Spark client was more than two years ago (January 29, 2017). Many have questions about the future of Spark, so i decided to explain a few things and also draw some attention to this project.

TL;DR: there are no active developers working on Spark for some time and there is a number of big issues in the current code blocking new releases.

A bit of history:

Spark has been abandoned a few times in the past. When JiveSoftware released its source one user (student at that time) took the lead developer role - Andrew Seymour (winsrev). Daniel Henniger (jadestorm) also helped to fix a few things. Andrew left the project after he has finished his studies and didn’t have time for side projects. Then there was a team of Walter Ebeling and his two programmers Holger and Wolf. They were using Spark in their company, so there was an incentive for them to make it work better. I think they pushed Spark to 2.6.0 branch and a few releases past that, getting rid of proprietary parts like Synthetica skin and introducing free JTattoo skin framework. Wolf has contributed Roar plugin for popups and actually made a few fixes many years later. Tim Jentz also came along (i think he was an intern and this was his test project). He added a few features and started working on a multi window chat support, but unfortunately never finished it. Probably they switched from using Spark (or XMPP altogether), so they stopped contributing to this project. Not to diminish they work though. Without them there would be no Spark at all. Then cstux took the reign for a short time and also helped push Spark forward (i think there was at least a few betas and maybe 2.6.3 release). There were (and still are) a lot more contributors. As you can see on GitHub activity page (and this only shows history after switching to GitHub from local SVN repo). I can mention Konstantin, Alexander, Mircea. Also Michael Klein did a lot recently for Client Control features (and just a pleasant person to work with). But then there was a long pause. cstux wasn’t active on Spark project anymore, there were a few fixes being added to the source and a few more posted on the forums or in the tracker, but no releases. Actually i have started using nightly build versions in my company, as they were stable enough and had fixes for some annoying bugs in 2.6.3. It was like that for quite a few years (2.6.3 was released in 2011).

Then came April of 2015 and release of Openfire 3.10.0 version (major version after a year old 3.9.3 with some important changes). And it broke compatibility with 2.6.3. Spark was just too old to work with new TLS standards. Although there were workarounds to use Old SSL 5223 port (or keep using old Openfire). But nightly builds were working fine. So, i decided to step in, take the Project Lead role and release the 2.7.0. Now, i wasn’t a developer (and still am not). But i knew internal kitchen for 10 years, i knew current issues, i have posted hundreds of tickets in the tracker, thousands of posts in the forums helping users or working with past developers. And it worked. It was also fun to try new things. Then i started looking for all not yet submitted patches, testing them, even fixing or adding some minor stuff myself (still very proud of an option to use Spark’s version as a resource). Every few months i would release a new minor version with a few more fixes or new features. A few users started to contribute also.

Next year we have released 2.8.0. Spark is built upon Smack API library. But it was using ancient version of Smack at the time. So 2.8.0 introduced newer Smack version and also switch to Java 8 (both in building and bundling). Huge work has been done by @guus (who is also one of the main developers of Openfire). This release was a bit controversial. As new Smack introduced more strict way of dealing with bad certificates. So forums were flooded with users using IP address or wrong server name to login and getting errors. But Spark became more secure this way. Also, it became apparent that Spark needs a better mechanism to deal with certificates. In 2.8.1-2.8.3 a few new options were added to ignore certificate errors for those users who couldn’t fix their setup.

In 2017 we decided to add Spark to Google’s Summer of Code program with a task to create a certificate store management and GUI (and a few more related things). A few students competed and we have picked @Alameyo. Throughout summer he has created a base for this functionality. Although it took longer to finish this work, but now it is in a usable form (with a few quirks still needed to be fixed). As it was an ongoing work, we couldn’t make a release with an unfinished feature.

Earlier this year Ignite Realtime team decided to move from Ant build system to Maven and Spark was selected as a first project (as being fairly less complex than Openfire) to test this path. @guus again did a lot to make it happen. This of course also broke lots of things and made release even less possible.

During the last few years @Flow (and probably Guus also) made an attempt to update Spark to the latest Smack version. Which in turn introduced a few more issues, which are yet to be fixed.

Granted, with bigger team and better management this probably could be avoided. By having separate branches and porting new fixes to development branch, releasing new 2.8.x bugfix releases. But there are no human resources and time for this. Also we kind of hoped for these issues to get resolved faster, so decided to put everything in the current branch (2.9.0).

You can see what major issues are still present and blocking the release (in my opinion) in this list that i have also pinned to Spark Dev forum - https://discourse.igniterealtime.org/t/issues-blocking-2-9-0-release Some issues were already fixed and removed from that list. But sometimes it feels like you can find an issue anywhere you poke…

So, my main point of this post - Developers needed
Although we still get small patches here and there, but they kind of go in vain as we can’t do a release. Spark is an old application with a lot of inefficient, deprecated and just confusing code. It also uses old Java Swing technology for its GUI. There were talks at various points to maybe move Spark to AIR, then JavaFx, but that would be an enormous task and it never went past talking. All this is probably making Spark not that attractive to Java developers who want to contribute to open source.

But Spark is still used by many users around the world. It’s UI is clean and nice (and in my opinion better than in some other clients). So, if you are a developer who looks for a project to participate, feel free to do this, contact us in the forums or in the group chat. No matter the size of your contribution (small patch or reworking of a bigger part), you are welcome. Maybe you want to learn Smack. Then fixing Spark’s issues with that library could be a good start. Of course, we would be especially pleased with someone able to devote more time to this project and help fixing all current outstanding issues (we are not offering pay though). Maybe even becoming new Project Lead.

For other release announcements and news follow us on Twitter

Posts: 3

Participants: 2

Read full topic

by @wroot wroot at May 11, 2019 10:40

May 10, 2019

Jérôme Poisson

SàT progress note 2019-W19

Hi everybody,

this week has been quite busy with the release of SàT 0.7.0b1. Entering the beta phase means that no more big features will be implemented (small modifications may still be done if necessary), and I'll concentrate on debugging and stability.
The UI of Cagou and Libervia are usable now, even if not perfect, but it was necessary to release to get feedback. Also Python 3 port is the first thing which will be done for next version (0.8), and some features/improvements are waiting for it.

I'm currently focusing on the new website based on Libervia web framework, and on reworking the documentation. The documentation is important to work on, as many people don't know the capabilities of SàT. Furthermore, it can be later used to generate man pages, notably for jp (CLI frontend), and will be available on the new website.

So the plan now is to have the website online a soon as possible, then finish the work started months ago to have SàT (and mostly Cagou) available on flatpak. It would be good to have Cagou available at least on F-Droid, that's another thing to check.

Last but not least I'm planning to work on SàT Pubsub, the server independent PubSub implementation, I'm missing some features before releasing it, but I'll talk about that in a future progress note.

by goffi at May 10, 2019 06:04

May 08, 2019

Jérôme Poisson

SàT 0.7.0 just entered beta phase

Salut à Toi version 0.7.0 beta 1 has been released. In other words, we are starting the beta phase, the feature are frozen (beside small adjustments) and now we will concentrate on stability, debugging and usability.

As a reminder, "Salut à Toi" is a libre, decentralised, and ethical communication ecosystem. It offers numerous functionalities (instant messaging, end-to-end encryption, blogging, file sharing, events, forums, etc.) and works natively on desktop, mobile devices (Android), on the web, and as well without graphic interface (text interface and command line).

It has been a relief to move over this stage after enourmous amount of work since the last version (0.6.1), released more than 2 and half years ago!

Now, it's your turn: testing, feeding back (on https://bugs.goffi.org or on the project room, also available on the web), and doing your suggestions, it's the time!

If you know Python, I am looking for people who could help me to make the project installable on Windows, Mac OS and *BSD. I am also working on a flatpak package. It would be good to have he web frontend on Yunohost, there again help would be much appreciated (cf. work already started).

Please note that SàT is already available on Debian and probably its derivated (however, beta is not there yet), as well as on Arch Linux (you'll have to use the sat-*-hg packages to test the beta).

The installation instructions are available in the documentation, and I'm working on a new website, which would be more reading friendly, and should be on-line this week.

Here are the links for installation files, and you'll find most of them on Pypy (please note that you'll have to go through "release history" to get beta version)):

I'm concluding with a screenshot of the Android version of Cagou, and note that this blog is also made with this project:

Cagou v0.7.0b1 on Android screenshot

by goffi at May 08, 2019 07:56

May 07, 2019

Alexander Gnauck

Palaver XMPP client

It’s more than 20 years since I got involved with chat technologies. In the late 90’s I got hired by company for developing a chat client. We did this by reverse engineering the ICQ and AIM protocols and created a compatible client. Then Jabber was announced, we switched to it immediately, using the gateway feature to talk to the proprietary systems.

Later I worked for SLTS Communications on the myJabber client, which was very popular on the Windows platform. Also one of the first clients which bridged Jabber and SIP for VOIP integration.

Then I became self employed and focused mostly on libraries which helped many companies to bring their Jabber/XMPP products faster to market. I also did lots of consulting and custom development on clients, servers and other Jabber/XMPP related products.
Also many products which were not IM related, but using the realtime capabilities and other modern XMPP features.

Working on chat clients was always one of the tasks I enjoyed most. I missed the client work over the last 10+ years. So I thought its time to get back to it ;-)

Over the last 12+ month I did lots research on clients and their UIs. This includes XMPP, other open IM protocols and proprietary chat systems.
I worked on several prototypes with different toolsets and technologies. The aim was to evaluate languages and their frameworks. As well as available XMPP libraries for creating a modern cross platform client using the latest compliance suites.

The focus was on desktop clients only. While we have pretty good mobile clients, we are lacking on good desktop clients these days. Especially on Windows. Many people still spend most of their time on the desktop.

I created prototypes with:

  • various Javascript SPA frameworks, as PWA and Electron application
  • Different cross platform native UI-kits and programming languages
  • WASM
  • Java
  • .NET

I got the best results with technologies that have good implementations of the MVVM pattern. This narrowed it down to some web frameworks and the .NET platform for me.

With netCore the .NET platform became finally open source and cross platform. What’s still missing is an official cross platform GUI from Microsoft. But there is the open source XAML framework Avalonia, supporting all major platforms. And my own MatriX library is available for netCore for a while now, also open source, licensed under the GPL.

Because of the great Avalonia UI framework I decided on the netCore stack using for the new Palaver XMPP client.

Its still in very early stages. Once I can stabilize the prototype into a working client for daily usage all code will be published under the GPL license on GitHub. If anyone is already interested to contribute to this project then feel free to contact me.

Here you can see some early screenshots



by gnauck at May 07, 2019 17:57

May 03, 2019

Jérôme Poisson

SàT progress note 2019-W18

Hello,

this week I've had to fix the way jid are used for file transfer.

To explain you the problem, I need to explain you how communication is done in XMPP (*). To be brief, when an entity (with jid louise@example.net) want to access a component (with jid files.example.net), it sends a "stanza" which is an XML element. There are 3 kinds of stanza (presence, message, and iq).
In our case we use iq stanza, so Louise sends something like:

<iq from="louise@example.net" to="files.example.net" type="set">
  […]
</iq>

and the component answers with something like this:

<iq from="files.example.net"  to="louise@example.net" type="result">
  […]
</iq>

Last week I've explained how I've used the local part in components to access files from somebody else. So far, when creating a stanza, I was using the jid we are connecting with in the from attribute (i.e. where we set the sender of the message).

This is working well with clients, or components if you don't use local part, but when somebody was accessing files from pierre@files.example.net, the jid used by the component is files.example.net, a different one, so this was not working anymore.

To fix that, I've simply had to change the code to use the jid used to contact the components (i.e. the one in the to attribute of the original request) instead.

I've also fixed a MAM (Message Archive Management, XEP-0313) bug where the same messages were requested again on next start up under certain conditions.

Finally, I've completed a generic invitation mechanism to notify somebody when an event or photo album is available. When the invitation is received, the data needed to retrieve the thing is saved in a private "list of interest", which is a pubsub node. With that I can now diplay in Libervia the available photo albums as you can see in the screen capture below.

Libervia Photo Album Vignette

We are nearly there, I still have to complete the guest page (page for people without XMPP account), so they can see events or photo albums, and I can launch the beta. It's a matter of days now.

Thanks for reading, as always feedbacks are welcome.

(*) to learn more about XMPP, you can check my series of articles "Let's talk XMPP". It's originally written in French, and only 4 articles on 10 are translated, help would be welcomed to translate the other ones.

by goffi at May 03, 2019 08:04

The XMPP Standards Foundation

The XMPP Newsletter, 3 May 2019

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

Rafał Leśniak published an interesting write-up about the challenges faced by a Forward Health, a UK based messaging platform for healthcare, which migrated from a third party chat solution to a custom XMPP-based one. It's an interesting read with insights into how XMPP is perceived by newcomers to the protocol.

An academic paper (in PDF format) appeared about using XMPP to control robotic telescopes.

Jérôme Poisson is writing regular progress notes about his work on various parts of the Salut à Toi project, which includes frontends for the desktop, Android and the web. He's been working on the XMPP-based file sharing service. Starting with the incoming version 0.7 SàT can be used as a component, and file sharing is the first one although he's still making further fixes to file sharing in the context of photo albums.

Paul Schaub has been writing a series of blogs posts about the cryptographic building blocks of OMEMO, an end-to-end encryption protocol for XMPP based on the Signal Protocol. In the first one he explains how with the Signal Protocol you can start an encrypted chat with another user even if they are offline. In his second post, he takes a closer look at the double ratchet which protects the secrecy of past and future chat sessions if a particular session was compromised.

Isode has published a whitepaper on interoperability between IRC and XMPP. One key takeaway is that with their approach, when all users have migrated to XMPP the IRC channel is no longer needed and can be removed, which is not the case with other gateway approaches.

In the beginning of April an XMPP sprint was held in Berlin, sponsored by the German Federal Youth Council (Deutsche Bundesjugendring). On their website is a retrospective on the sprint in German. Here's the Google translated version. They've now also announced their own public XMPP server at yochat.eu. Here again the Google translated version.

The 2019 XMPP Compliance Suites XEP has been advanced to Draft status and Jonas Schäfer has updated the CSS stylesheets of the XEPs so that they now have a handy fixed table of contents.

Software releases

The upcoming release of Monal will support AESGCM:// links, include an unread message indicator and include some OMEMO fixes.

Clients

Plugins

  • Hazelcast for Openfire 2.4.2
  • Search for Openfire 1.7.2
  • Bookmarks for Openfire 1.0.3

by jcbrand at May 03, 2019 07:00

May 02, 2019

Isode

M-Link XMPP/IRC Gateway

A new whitepaper on the Isode website (Interconnecting XMPP and IRC) shows how Isode’s M-Link XMPP Server can be connected to and used in conjunction with chat services using IRC (Internet Relay Chat) in a range of deployment scenarios.

In order to help our customers and evaluators establish connections between XMPP Multi-User Chat (MUC) rooms and IRC channels, without downgrading security for XMPP users with XMPP traffic we’ve published a new evaluation guide.

by admin at May 02, 2019 09:14

Adding a Security Policy to M-Link

We have two small changes to our evaluation guide series to announce (with many more coming soon).

Our core XMPP Messaging Evaluation Guide, using our M-Link XMPP server and M-Vault LDAP directory, now includes a section on adding a Security Policy to your XMPP service. In this new section we show you how to add a the policy to your service and clearances to your users. You can additionally apply label based controls to multi-user chat, domains and peer services (all of which and more is covered in the M-Link Admin Guide).

The Security Policy we use in the evaluation guide is one of the demonstration policies we ship with M-Link but, if you want to create your own, contact us about evaluating our SPIF Editor. SPIF (Security Policy Information File) is a file representation of a Security Policy, in other words the definition of which labels are valid and how to check them against clearances.

by Hannah George at May 02, 2019 09:05

May 01, 2019

Isode

Isode at the HFIA #1: Proposed Extensions to STANAG 5066

The High Frequency Industry Association (HFIA) provides an “industry driven forum for the interactive exchange of technical and information in the area of High Frequency Communications.” Physical meetings of the group usually take place twice a year and in September 2014 Portsmouth was the location for the latest of these meetings. This is the first of two blog posts covering our attendance at this meeting.

As Isode has an interest in applications for constrained bandwidth communications, we often attend and occasionally present at these meetings. This year we had two presentations to share with the attendees.

Steve Kille at the HFIASteve Kille at the HFIA

Isode CEO, Steve Kille, gave a talk focusing on Isode’s proposed extensions to STANAG 5066 to improve performance of applications running over wideband HF links. The first was an update to a talk Isode gave at the February HFIA meeting, this time including hard measurements showing that Isode’s extensions (known as LFSN, Long Frame Sequence Number) result in significant performance gains.

This was followed by a live demonstration of the extensions in action, enabling co-existence of bulk and time critical applications over narrow-band and wide-band HF. The applications used were Multi-User Chat and Real-Time Military Forms (both using the XMPP protocol) and military email messaging.

by Will Sheward at May 01, 2019 11:06

R16.3: Multi-Master Directory, XMPP Archive/Search & ACP127 support

We’re pleased to announce the availability of Isode’s latest release, R16.3, which can be downloaded now from our website. R16.3 is a major Isode release which adds new capabilities across the entire Isode product range, including:

M-Vault

We’ve introduced a multi-master capability to M-Vault, complementing the single-master approach to replication defined in the X.500 protocols around which M-Vault was developed. M-Vault is the first directory to offer both multi-master and X.500.

M-Link

M-Link gains a new Archive Server for archive of all messages (including 1:1 chat, MUC and PubSub). XMPP clients can access archives using Message Archive Management (MAM) as defined in XEP-0313. M-Link also gains three new web applications:

  1. Message Archive Management, allowing browser-based access to information in the archive.
  2. Statistics, a lightweight monitoring alternative to the M-Link Console GUI.
  3. Forms Discovery and Publishing, for end-user publishing and display of FDP forms.
M-Link Statistics Web AppM-Link Statistics Web App

M-Switch

We’ve added gateway support for text based organisational message protocols, which we’re collectively describing as ACP127. The first release of this capability supports ACP127 and DOI 103S, a popular US variant, and enables conversion with STANAG 4406 (compliant to STANAG 4406 Annex D) and SMTP (following the MMHS over SMTP extensions).

In addition we’ve made extensive improvements to MConsole and M-Link Console to support the new M-Switch and M-Link family capabilities. For a full run-down of new capabilities in R16.3, please see the Product Release page. We’ll be publishing further blog posts over the coming weeks focusing on some of the new R16.3 capabilities.

by Will Sheward at May 01, 2019 10:59

April 30, 2019

Monal IM

Unread Message Indicator

I have added an unread message indicator in the chat screen to indicate where unread messages begin. You can see this towards the bottom in the screenshot below. This should be useful when combined with the new date separators and shorter date display.

At this point. I think 3.6 is done with new features. The final change log is:

  1. New streamlined chat ui
  2. Support for aesgcm encrypted attachments inline
  3. Support for new line in chat and enter to send messages only when a hardware keyboard is attached.

by Anu at April 30, 2019 02:43

April 28, 2019

Peter Saint-Andre

Tales of Slow Time

I've been thinking about writing a set of linked short stories entitled Tales of Slow Time, set in the early 22nd century. As I see it, this will be a time of extremely rapid change and constant flux. Because humans won't be able to absorb change at that rate, they will be even further dumbed down and domesticated compared to today, living as they will in a culture of convenience, pleasure, entertainment, and post-literacy. The influence of raw intelligence will be even more keenly felt (cf. the seven tribes), resulting in extreme inequality. Governments everywhere will have implemented a universal basic income to placate the great mass of people who would otherwise have no livelihood. However, most people will therefore have too much free time: some will use that time to cause trouble, meddle, protest; others will play immersive video games or plug into virtual worlds; others will engage in simulacra of productivity (incubators of nothing). The human population will be both smaller and older. Information technology will be pervasive: robots will perform many routine and non-routine tasks; algorithms will rule the day; people will be subject to ubiquitous tracking, profiling, surveillance, and manipulation through advertising, marketing, nudging, and helpthink; we will experience the gamification of all activities and human/machine interactions; news, information, audio, video, AR/VR, holography - anything presented or represented through networks or computers - will be essentially made up (fiat everything); people will have little certainty about what is real. Everything and everyone will be mapped, tracked, annotated, recorded via the hypermap and the ledger. Robots will be our friends and teachers; machines will perceive our moods; all of our choices will be "suggested" by algorithms. Corporations and governments will engage in lifelong observation and manipulation of each and every individual. There will be no privacy, no autonomy, no serenity, no humanity. We will live in a materially abundant spiritual wasteland ruled by impersonal forces of government, science, technology, corporations, insurers, medicine, politics, even the arts....

April 28, 2019 00:00