Agregador de noticias

Peter Saint-Andre: Poets' Paradox

Planet Jabber - 31 January, 2017 - 00:00
Here's another draft poem for my far-future book Songs of Zarathustra:...

Tigase Blog: Tigase Server 7.1.0 Release

Planet Jabber - 30 January, 2017 - 21:38
Tigase XMPP Server 7.1.0 has been released! Please review the change notes below to see what has changed since our last release.

Introducing Tigase XMPP Server 7.1.0! We have been working hard to improve and implement new features to the Tigase Seve to give you a more secure, leaner, and better working XMPP server. We have a few new features, components, and lots of fixes to share. Please note that not all issues are accessible as submitted notes may contain sensitive information. Binaries are available from the project's files section. Sources are available in our repository. Maven artifacts have been deployed to our maven repository. Test results are located on our test page.

Ignite Realtime Blog: Spark 2.8.3 Released

Planet Jabber - 29 January, 2017 - 19:21

The Ignite Realtime community has just released Spark 2.8.3 and it can be downloaded from the Ignite Realtime: Downloads


This is a regular update. A few issues have been fixed. Bundled Java updated to the latest version. There is a new menu to view history of sent broadcasts and an option to login anonymously.


For a complete list of changes please check the Spark Changelog


We encourage developers to get involved with Spark project by providing feedback and patches in the forums or submitting pull requests to GitHub - igniterealtime/Spark: Cross-platform real-time collaboration client optimized for business and organizations.


Here is the list of contributors to this release (besides myself):

Michael  - fixed Advanced settings not being saved without opening that menu, always on top issue and changed behavior when Auto Login is hidden

Alexander198961 (Aleksander Kovtunenko) · GitHub  - added a feature to save broadcasts history and access it via a new menu option

Jerry  - added support for anonymous login

Guus der Kinderen  - fixed issue when joining a room with a duplicate nickname and improved build time by removing unneeded code style checks

Daryl Herzmann  - helped to clean up the code further (removing legacy CVS keywords)

speedy  - fixed issues with password not being deleted when it should and added log file rotating by size

Atalanttore (Ettore Atalan) · GitHub  - updated German translation


Here are sha1 checksums for the downloads:

b07a990109ec934e673e2bcb41a6be81a44e6131  spark_2_8_3.dmg

839226d42cea7778961d525a63c4a27c0f269250  spark_2_8_3.exe

526c46faafe3baf8c78bc69a024cfd752da57123  spark_2_8_3_online.exe

06542cac2db2611e3fcfcf7741fcfe242aa98d9f  spark_2_8_3.tar.gz

ea4bb09c4b55d102f69f974418a06a5c820b37c3  spark-2.8.3.rpm

9917c48e393e215c9aa1d14606b70dcb8531baf9  spark-2.8.3.src.rpm

6b6adbed00935cd01155355b796d4c504d49c18f  spark_2.8.3.deb

Peter Saint-Andre: Ism Book Updates

Planet Jabber - 29 January, 2017 - 00:00
One of the great things about publishing to the Internet, and nowadays print on demand as well, is that you can continually improve what you have written. Among my writings, there is no better example than The Ism Book: A Field Guide to Philosophy. I first wrote this highly interlinked book using HyperCard on my first Macintosh computer, then ported it to the Internet in 1996. Since then it has undergone numerous revisions as I've broadened and deepened my understanding of philosophical history and concepts. Last week while in flight to and from California I marked up a copy of the book with copious amounts of red ink, and today I keyed in a large number of edits (in fact I've been making numerous fixes for the last two months). Now I just need to port all these changes over to the physical book and republish it....

The XMPP Standards Foundation: XMPP Summit 21

Planet Jabber - 27 January, 2017 - 17:50

This year, the XMPP Standards Foundation again gathered in force to attend the summit, that traditionally precedes the FOSDEM event in Brussels, Belgium. Barely fitting in the (rather sizable) room that was made available to us by Cisco, the XSF members had a fruitful two-day meeting.

Day two @xmpp Summit21. #xmpp2017 #IoT

— Rikard Strid (@rikardstrid) February 3, 2017

The attending members, skillfully herded by Kev, addressed an impressive number of topics, including:

  • BIND2, improving the data exchange that occurs when an XMPP entity initially connects to a server.
  • MIX, the XEP that intends to be a replacement for the existing MUC protocol, bringing an up-to-date feature set and better extensibility.
  • Addressing the annoyance of instant-messaging-based spam.
  • The application of existing, or to be developed XMPP standards, to facilitate the growing world of Internet-of-Things.
  • The XSF intention to take part in this years Google Summer of Code.
  • Improvements to the existing end-to-end encryption, as defined in the OMEMO XEP.

The full minutes are made available in the XSF wiki. If any of these topics (or others for that matter) interest you, we'd love to hear from you. Please find us at, use the mailinglists to contact us, or find us in one of the dedicated MUCs.

#XMPP2017 Summit Dinner!

— Marcelo Terres (@mhterres) February 2, 2017

Many thanks to everyone involved in making the summit happen, including Cisco Belgium, Surevine, AG Software, Isode, Prosody, Erlang Solutions and Clayster for providing much appreciated sponsoring for the event, as well as the traditional XSF Member dinner!

Apart from the discussions, the summit proved to be an excellent opportunity for some of the newer members amongst us, myself included, to make acquaintance with the others. I, for one, am grateful to have been there, and am looking forward to the next meetup!

Erlang Solutions: Build a complete iOS messaging app using XMPPFramework - Tutorial Part 1

Planet Jabber - 24 January, 2017 - 11:06
YAXT??! Yet another XMPP tutorial?


Well, this is going to be another tutorial, but I'm going to try to make it a little bit different. This is an XMPP tutorial from an iOS developer's perspective. I'll try to answer all the questions I had when I started working in this area. This journey is going to go from no XMPP knowldege at all to having a fully functional instant messaging iOS app using this cool protocol. We are going to be using the super awesome (yet overwhelming at the beginning...) XMPPFramework library, and the idea is also to also mix in some iOS concepts that you are going to need for your app.

What's XMPP?


From Wikipedia: Extensible Messaging and Presence Protocol (XMPP) is a communications protocol for message-oriented middleware based on XML.

This basically means XMPP is a protocol for exchanging stuff. What kind of stuff? Messages and presences. We all know what messages are, but what about presences? A presence is just a way of sharing a "status", that's it. You can be 'online', 'offline', 'having lunch', or whatever you want. Also there's another important word: Extensible meaning it can grow. It started as an instant messaging protocol and it has grown into multiple fields for example IoT (Internet of Things). And last, but not least: every piece of information we are going to exchange under this protocol is going to be XML. I can heard you complaining but... Come on, it's not that bad!

Why do we need XMPP? Why not just REST?


Well what other options do we have? On the one hand, a custom solution means building everything from scratch, that takes time. On the other hand, we have XMPP, a super tested technology broadly used by millions of people every day, so we can say that's an advantage over a custom approach.

Everytime I talk about XMPP, someone asks me 'Why not just REST?'. Well, there is a misconception here. REST is not a protocol, it's just a way of architecting a networked application; it's just a standarized way of doing something (that I love btw). So let's change the question to something that makes more sense: "Why not just build a custom REST chat application?". The first thing that comes to my mind is what I already explained in the previous paragraph, but there is something else. How do I know when someone has sent me a message? For XMPP this is trivial: we have an open connection all the time so, as soon as a message arrives to the server, it will send us the message. We have a full-duplex. On the other hand, the only solution with REST is polling. We will need to ask the server for new messages from time to time to see if there is something new for us. That sucks. So, we will have to add a mechanism that allows us to receive the messages as soon as they are created, like SSE or WebSockets.

There is one more XMPP advantage over a custom REST chat application. REST uses HTTP, an application level protocol that is built on top of a transport level protocol: TCP. So everytime you want to use your REST solution, you will need HTTP, a protocol that is not always available everywhere (maybe you need to embed this in a cheap piece of hardware?). Besides, we have XMPP built on top of TCP that's going to be always available.

What's the basic stuff I need to know to get started?


Well, you know a lot already but let's make a list. Lists are always good:

  • XMPP is built on top of TCP. It keeps an open connection all the time.
  • Client/Server architecture. Messages always go through a server.
  • Everything we send and receive is going to be XML and it's called Stanza.
  • We have three different types of stanzas: iq, message and presence.
  • Every individual on the XMPP network is univocally identified by a JID (Jabber ID).
  • All the stanzas are cointained in a Stream. Let's imagine the Stream as a white canvas where you and the server write the stanzas.
  • Stream, iq, message and presence are the core of XMPP. You can find everything perfectly detailed in RFC6120
  • XMPP can be extended to accomplish different stuff. Each extension is called XEP (XMPP Extension Protocol).
  What's a JID?

Jabber ID (JID) is how we univocally identify each individual in XMPP. It is the address to where we are going to send our stanzas.

This is how a JID looks like:

  • localpart: This is your username.
  • domainpart: Server name where the localpart resides.
  • resourcepart: This is optional, and it identifies a particular client for the user. For example: I can be logged in with on my iPhone, on my Android and on my mac at the same time... So all these will be the same localpart + domainpart but different resourcepart

I'm sure you have already noticed how similar the JID looks to a standard email address. This is because you can connect multiple servers together and the messages are rooted to the right user in the right server, just as email works. Pretty cool, right?

Sometimes you will see we have a JID with just the domain part. Why?! Because it's also possible to send stanzas to a service instead of a user. A service? What's a service?! Services are different pieces of an XMPP server that offer you some special functionality, but don't worry about this right now, just remember: you can have JIDs without a localpart.

What's a Stanza?

Stanza is the name of the XML pieces that we are going to be sending and receiving. The defined stanzas are: <message/>, <presence/> and <iq/>.


This is a basic <message/> stanza. Everytime you want to send a message to someone (a JID), you will have to send this stanza:

<message from='' to='' type='chat'> <body>Hey there!</body> </message>   <iq/>

It stands for Info/Query. It's a query-action mechanism, you send an iq and you will get a response to that query. You can pair the iq-query with the iq-response using the stanza id.

For example, we send an iq to the server to do something (don't pay attention to what we want to do... you just need to know there is an iq stanza and how the mechanism works):

<iq to='' type='get' id='1'> <query xmlns=''/> </iq>

And we get back another iq with the same id with the result of the previous query:

<iq from='' to='' id='1' type='result'> <query xmlns=''> <item jid=''/> <item jid=''/> <item jid=''/> </query> </iq>   <presence/>

Used to exchange presence information, as you could have imagined. Usually presences are sent from the client to the server and broadcasted by it. The most basic, yet valid presence, to indicate to the server that a user is avaiable is:


After a sucessfull connection, you are not going to receive any <message/> until you make yourself available sending the previous presence.

If you want to make yourself unavailable, you just have to send:

<presence type="unavailable"></presence>

If we want to make the presences more useful, we can send something like this:

<presence> <status>On vacation</status> </presence>   What's a Stream?

Before answering this, let's refresh our mind. What's a Unix socket? From Wikipedia: A socket is a special file used for inter-process communication. These allows communication between two processes. So a socket is a file that can be written by two processes (in the same computer or in different computers in the same network). So the client is going to write to this file and server too.

Ok, but how is a socket related to a Stream? Well, we are going to be connected to a server using a socket, therefore we are going to have a 'shared file' between the client and the server. This shared file is a white canvas where we are going to start writting our XML stanzas. The first thing we are going to write to this file is an opening <stream> tag! And there you go... that's our stream.

Perfect, I understand what a stream is, but I still don't understand how to send a message to the server. Well, the only thing we need to do to send a message is writting a <message/> stanza in our shared file. But what happens when the server wants to send me a message? Simple: it will write the message in the 'shared file'.

Are we ok so far?


I'm sure at this point you have questions like:

  • "What?! An active TCP connection open all the time? I'm used to REST! How am I going to do that?!" 

​           Easy, you don't have to care about that any more! That's why we are going to use the library, and it will take care of that.

  • "You said nothing about how to connect to the server!"

           Believe me, you don't have to care about this either. If we start adding all this info, we are going to get crazy. Trust me, I've been there.

  • "What about encrypted messages? We need security! How are we going to handle this?"

          Again, you don't have to care about this at this point. Baby steps!


You just need to be able to answer: "What's XMPP?", "How do you send a message?", "How do you change your status in XMPP?", "How do you ask something to the server?", "What's a Stream?". If you can answer all that, you are WAY better than me when I started.

All the concepts we described so far are the core of XMPP.  To find out how to get started with XMPPFramework, how to connect to the server and authenticate a user, go to PART 2!

Alexander Gnauck: Introducing MatriX vNext

Planet Jabber - 22 January, 2017 - 15:47

We are thrilled to announce the next generation of the MatriX XMPP libraries.
15 years elapsed already since we started our first .NET/c# XMPP library agsXMPP with .NET 1.0. Our XMPP libraries and the .NET technologies had many major evolutions over the years.

With the switch to .Net Core we also took the opportunity for a major rewrite and redesign of the codebase. The API for clients, servers and components is not backwards compatible, but all XMPP protocol classes remain the same. Updating existing code bases to MatriX vNext should be pretty straightforward.

Some highlights
  • new software design and more modern API
  • target .Net Core
  • high performance sockets using Azure DotNetty
  • Completly Task based using the TAP pattern (async/await)
  • more Linq extensions
  • Rx (Reactive Extensions)
  • will be open source and available under a dual license (Open Source and commercial)

Here is some demo client code using MatriX vNext:

var xmppClient = new XmppClient { Username = "alex", Password = "secret", XmppDomain = "", }; xmppClient .XmppXElementStream .Where(el => el.OfType<Presence>()) .Subscribe(el => { // Handle incoming presence Debug.WriteLine(el.Cast<Presence>().From); }); xmppClient .XmppXElementStream .Where(el => el.OfType<Message>()) .Subscribe(el => { // Handle incoming messages Debug.WriteLine(el.Cast<Message>().Body); }); xmppClient .XmppXElementStream .Where(el => el.OfType<Iq> && el.Cast<T>().Type == IqType.Get && el.Cast<T>().Query.OfType<Ping>() .Subscribe(el => { // handle and reply to incoming pings var iq = xmppXElement.Cast<T>(); var resIq = Factory.GetElement<T>(); resIq.Id = iq.Id; resIq.To = iq.From; resIq.Type = IqType.Result; await xmppClient.SendAsync(resIq); }); // connect, secure, authenticate and bind await xmppClient.ConnectAsync(); // request roster (contact list) var roster = await xmppClient.RequestRosterAsync(); // send own presence to the server xmppClient.SendPresenceAsync(Show.Chat, "free for Chat");

A prerelease is available as a Nuget package here:

Fanout Blog: Pushpin reliable streaming

Planet Jabber - 22 January, 2017 - 06:38

Earlier this month we discussed the challenges of pushing data reliably. Fanout products such as Pushpin (and Fanout Cloud, which runs Pushpin) do not entirely insulate developers from these challenges, as it is not possible to do so within our scope. However, we recently devised a way to reduce the pain involved.

Realtime APIs usually require receivers to juggle two data sources if they want to receive data reliably. For example, a client might listen for updates using a best-effort streaming API, and recover data using a REST API. So we thought, what if Pushpin could manage these two data sources, such that the client only needs to worry about one?


Peter Saint-Andre: The Irrelevance of Government

Planet Jabber - 21 January, 2017 - 00:00
Imagine life a thousand years ago in, say, France or Italy. The society and culture in which you are immersed is deeply focused on religion. The words of your local priest have great significance, a bishop or archbishop is a personage of divine importance, and the Pope is like a spiritual emperor. Those wishing to effect social change, or tell other people what to do, or pursue their own personal advantage, necessarily use the tool that is ready to hand, and that is the apparatus of the church....

ProcessOne: ejabberd 17.01

Planet Jabber - 20 January, 2017 - 16:14

We’re pleased to announce the first version of ejabberd for 2017.
This new ejabberd 17.01 follows closely the previous release. It includes mostly bug fixes over all the previous refactors.

Ejabberd 17.01 is a rock-solid stable base for upcoming improvements. It will give you the best experience you ever had with ejabberd.
If you ever wanted to upgrade your old ejabberd 2.1.13 or need a stable base for your server running the next couple of months, 17.01 is your best opportunity to get this done now!


Here are the most relevant changes

  • Add example api_permissions: definition to config template
  • Allow old-stype mod_vcard_ldap in the config
  • Fix migration of old pubsub database (migrating from 2.1.x)
  • Get nodes from ejabberd_cluster instead of mnesia
  • mod_configure: Fix configuration commands
  • Fix case clauses when using compression
  • Set from/to in every routed packet
  • Correctly process errors from new cyrsasl API
  • Improve return values in cyrsasl API
  • mod_http_bind: remove and migration code to mod_bosh
  • mod_muc: Allow a subscriber to create room, then set allow_subscription=true
  • mod_muc: Support legacy muc#roomconfig values
  • mod_offline: Decode message before checking for expiration
  • Let ejabberd_mnesia handles copy_type
  • Fix index processing
  • Speedup table setup, no i/o if EJABBERD_SCHEMA_PATH not set
  • Add SSL support for SQL connections with PostgreSQL 1.1.2+
  • Cope with malformed values in ‘rosterusers’ SQL table
  • Improve tag insertion, avoid duplication

As usual, the release is tagged in the Git source code repository on Github.

The source package and binary installers are available at ProcessOne.

If you suspect that you’ve found a bug, please search or fill a bug report on Github.

Peter Saint-Andre: There's Never Just One Cause

Planet Jabber - 20 January, 2017 - 00:00
Some years ago I did some intensive research into the origins of the industrial revolution. At the time I was working my way out of the Rand meme, so the starting point of my investigation was her assertion that the cause of the industrial revolution was the philosophy of Aristotle. My conclusion was that Rand was wrong, and that there were multiple causes involved. I presented the fruits of my research in a paper published by the UK Libertarian Alliance, entitled Ayn Rand and the Ascent of Man....

Jack Moffitt: Servo Talk at LCA 2017

Planet Jabber - 18 January, 2017 - 00:00

My talk from was just posted, and you can go watch it. In it I cover some of the features of Servo that make it unique and fast, including the constellation and WebRender.

Servo Architecture: Safety & Performance by Jack Moffitt, LCA 2017, Hobart, Australia.

Monal IM: Monal and the iOS 10 SDK

Planet Jabber - 17 January, 2017 - 20:17

I updated Monal after the 2.9.2 release to work again in the background. It appears that Apple has not just deprecated but removed the VOIP socket that Monal has used since iOS4 to run in the background. For the time being I am going to build with the iOS 9 SDK and things will continue to work. However the point where that is not a valid option will arrive at some time. When that does happen Monal for iOS will move to using an APNS notification and the XMPP push mechanism.  Google talk will likely no longer work.

Peter Saint-Andre: Monadnock Valley Press Annual Report 2016

Planet Jabber - 14 January, 2017 - 00:00
In 2016 I again spent very little time on posting public-domain texts at the Monadnock Valley Press - only a few works by Henry David Thoreau, Virginia Woolf, and Blaise Pascal. Once I finish my forthcoming book on Thoreau, I plan to clear out a backlog of books, essays, and plays by Ibsen, Confucius, Emerson, Montaigne, Spinoza, Petrarch, Lucretius, Epictetus, Seneca, and Cicero. With revenue of $248.62 and expenses of $181.58, we earned only $67.04 in 2016, too. It's a good thing I don't write philosophy books for the money!...

Arnaud Joset: Chatty Server

Planet Jabber - 13 January, 2017 - 17:00

Chatty server is a XMPP bot programmed to run on a server. It can be used

  • as a dynamic toto list.
  • to provide the travel time by car, foot and public transport between two adresses.
  • to give useful information about the load of the server.
  • to give the status of the server. The status of the account change depending on the load and memory usage.

The following sections describes the usage of chatty_server.

When it start

At start, the program set a status base on the load and the memory usage.

‎18:40:29 ‎server‎: en ligne ‎18:40:30 ‎server‎: How you doin' ? Load: 0.12 0.05 0.05 Memory (Go): 1.08GiB/1.96GiB (35.2%) ‎18:40:30 ‎server is now Available (How you doin' ? Load: 0.12 0.05 0.05 Memory (Go): 1.08GiB/1.96GiB (35.2%)) Get the list of available commands

The list of command is send whenever the user send a message to the bot.

‎18:40:58 ‎jnanar‎: help ‎18:40:58 ‎server‎: Available Commands : status, reminder, travel Calculate a travel time

Calculate a travel time is easy and fast. You need to define a Google Maps API key to use this function. You can also, define

  • your address,
  • the summary key: it is the summary of this travel( a highway, a long road, etc),
  • the shortest distance between work and home,
  • as well as the duration of this particular travel.

When the distance differs or time differs too much from these data, the bot will remind you to take another road.

18:22:22 ‎jnanar‎: travel ‎18:22:23 ‎server‎: Usage: travel car start % stop conveyance = car, bus, metro, tramway etc. Example: travel car rue du parc 4000 Liège % Place saint Lambert 15 4000 Liège ‎ Examples 18:42:08 ‎jnanar‎: travel car rue du parc 4000 Liège % Place saint Lambert 15 4000 Liège ‎18:42:09 ‎server‎: travel car travel rue du parc 4000 liège to place saint lambert 15 4000 liège Summary: Quai Orban Distance: 2.46 km Duration in traffic: 9.22 min Duration (normal): 8.05 min

In order to use the travel time function you need to define an API key, a work location and a home location in the file named "libs/". Some shortcuts are available: h2w and w2h for home and work location.

18:49:10 ‎jnanar‎: travel h2w ‎18:49:11 ‎server‎: home address to work address Summary: E42 Distance: 7.81 km Duration in traffic: 11.03 min Duration (normal): 11.13 min Obtain the status of the server 18:34:13 ‎jnanar‎: status ‎18:34:13 ‎server: Load: 2.12 2.26 2.31 Memory (Go): 3.94GiB/11.23GiB (17.6%) CPUS : ('14.5%', '11.9%', '19.0%', '10.9%', '35.7%', '7.6%') Memory (Go): 3.94GiB/11.23GiB (17.6%) Use it as a reminder or a TODOlist. ‎‎18:42:45 ‎jnanar‎: reminder list ‎18:42:45 ‎server‎: Todo list ‎18:42:57 ‎jnanar‎: reminder write a blog article 5min ‎18:42:57 ‎server‎: Reminder: write a blog article at 2017-01-04 18:48:04.797349 ‎18:43:23 ‎jnanar‎: reminder 2h program my personal robot ‎18:43:23 ‎server‎: Reminder: program my personal robot at 2017-01-04 20:43:30.599113 ‎18:43:29 ‎jnanar‎: reminder list ‎18:43:29 ‎server‎: Todo list todo: due write a blog article at 2017-01-04 18:48:04.797349 todo: due program my personal robot at 2017-01-04 20:43:30.599113 ‎18:43:57 ‎jnanar‎: reminder 1min do a test ‎18:43:57 ‎server‎: Reminder: do a test at 2017-01-04 18:45:04.779812 ‎18:44:05 ‎jnanar‎: reminder list ‎18:44:05 ‎server‎: Todo list todo: due write a blog article at 2017-01-04 18:48:04.797349 todo: due program my personal robot at 2017-01-04 20:43:30.599113 todo: due do a test at 2017-01-04 18:45:04.779812 ‎18:45:01 ‎server‎: --- Reminder: do a test --- ‎18:45:10 ‎jnanar‎: reminder list ‎18:45:10 ‎server‎: Todo list todo: due write a blog article at 2017-01-04 18:48:04.797349 todo: due program my personal robot at 2017-01-04 20:43:30.599113 todo: done do a test at 2017-01-04 18:45:04.779812

chatty_server is written in python v3 and is licensed under the GPLv3 licence.

Install Install the dependencies Clone the repository
  • git clone
  • Modify libs/ and rename it as libs/

Erlang Solutions: Build a complete iOS messaging app using XMPPFramework - Part 2

Planet Jabber - 12 January, 2017 - 10:37
First steps: XMPPFramework

Build a complete iOS messaging app using XMPPFramework is a tutorial that shows you how to build a fully functional instant messaging iOS app using the very cool XMPPFramework protocol and Swift3. In this part, we are going to get our hands dirty! To recap on the theory, or if you just landed here randomly, have a quick read through the first part, then get your Xcode ready and let's start!

In this issue we are going to be integrating the library to our project, creating a connection with the server and authenticating. The XMPPFramework library is the most used XMPP library for iOS and macOS. At the beginning it may be a little bit overwhelming but after a few days working with it you will learn to love it.

Installing the library

Let's create a brand new Xcode project and install the library. In this tutorial we are going to be using Swift 3. The easiest way to integrate XMPPFramework to the project is using CocoaPods.

Let's create our Podfile using the pod init command in the folder where our .xcodeproj lives. There are thousands of forks but the maintained one is the original: robbiehanson/XMPPFramework.

So let's add the pod to our Podfile and remember to uncomment the use_frameworks!.

use_frameworks! target 'CrazyMessages' do pod 'XMPPFramework', :git=> '', :branch => 'master' end


Then pod install and CocoaPods is going to do its magic and create a .xcworkspace with the library integrated. Now we just need to import XMPPFramework in the files we want to use the library and that's it.

  Starting to build our Instant Messaging app

The most important thing in an XMPP application is the stream, that's where we are going to "write" our stanzas, so we need an object that is going to hold it. We are going to create an XMPPController class with an XMPPStream:

import Foundation import XMPPFramework class XMPPController: NSObject { var xmppStream: XMPPStream init() { self.xmppStream = XMPPStream() } }


We are dealing with a highly asynchronous library here. For every action we are going to have a response some time in the future. To handle this XMPPFramework defines the XMPPStreamDelegate. So implementing that delegate is going to help us answer lots of different questions like: "How do I know when XMPP has successfully connected?", "How do I know if I'm correctly authenticated?", "How do I know if I received a message?". XMPPStreamDelegate is your friend!

So we have our XMPPController and our XMPPStream, what do we need to do now? Configure our stream with the hostName, port and ourJID. To provide all this info to the controller we are going to make some changes to the init to be able to receive all these parameters:

enum XMPPControllerError: Error { case wrongUserJID } class XMPPController: NSObject { var xmppStream: XMPPStream let hostName: String let userJID: XMPPJID let hostPort: UInt16 let password: String init(hostName: String, userJIDString: String, hostPort: UInt16 = 5222, password: String) throws { guard let userJID = XMPPJID(string: userJIDString) else { throw XMPPControllerError.wrongUserJID } self.hostName = hostName self.userJID = userJID self.hostPort = hostPort self.password = password // Stream Configuration self.xmppStream = XMPPStream() self.xmppStream.hostName = hostName self.xmppStream.hostPort = hostPort self.xmppStream.startTLSPolicy = XMPPStreamStartTLSPolicy.allowed self.xmppStream.myJID = userJID super.init() self.xmppStream.addDelegate(self, delegateQueue: DispatchQueue.main) } }


Our next step is going to actually connect to a server and authenticate using our userJID and password, so we are adding a connect method to our XMPPController.

func connect() { if !self.xmppStream.isDisconnected() { return } try! self.xmppStream.connect(withTimeout: XMPPStreamTimeoutNone) }


But how do we know we have successfully connected to the server? As I said earlier, we need to check for a suitable delegate method from XMPPStreamDelegate. After we connect to the server we need to authenticate so we are going to do the following:

extension XMPPController: XMPPStreamDelegate { func xmppStreamDidConnect(_ stream: XMPPStream!) { print("Stream: Connected") try! stream.authenticate(withPassword: self.password) } func xmppStreamDidAuthenticate(_ sender: XMPPStream!) { self.xmppStream.send(XMPPPresence()) print("Stream: Authenticated") } }


We need to test this. Let's just create an instance of XMPPController in the AppDelegate to test how it works:

try! self.xmppController = XMPPController(hostName: "", userJIDString: "", password: "password") self.xmppController.connect()

If everything goes fine we should see two messages in the logs but of course that's not happening, we missed something. We never told to our xmppStream who was the delegate object! We need to add the following line after the super.init()

self.xmppStream.addDelegate(self, delegateQueue: DispatchQueue.main)

If we run the app again:

Stream: Connected Stream: Authenticated


Success! We have our own XMPPController with a fully functional and authenticated stream!

Something that may catch your attention is how we are setting our delegate, we are not doing:

self.xmppStream.delegate = self


Why not? Because we can "broadcast" the events to multiple delegates, we can have 10 different objects implementing those methods. Also we can tell what's the thread where we want to receive that call, in the previous example we want it in the main thread.

Getting a Log In

Our app is super ugly, let's put on some makeup! We have nothing but an XMPPController and a hardcoded call in the AppDelegate. I'm going to create a ViewController that is going to be presented modally as soon as the app starts, that ViewController will have the neccesary fields/info to log in to the server.

I'm going to create a LogInViewControllerDelegate that is going to tell to our ViewController that the Log in button was pressed and that's it. In that delegate implementation we are going to create our XMPPController, add the ViewControlleras delegate of the XMPPStream and connect!

extension ViewController: LogInViewControllerDelegate { func didTouchLogIn(sender: LogInViewController, userJID: String, userPassword: String, server: String) { self.logInViewController = sender do { try self.xmppController = XMPPController(hostName: server, userJIDString: userJID, password: userPassword) self.xmppController.xmppStream.addDelegate(self, delegateQueue: DispatchQueue.main) self.xmppController.connect() } catch { sender.showErrorMessage(message: "Something went wrong") } } }


Why are we adding ViewController as a delegate of XMPPStream if our XMPPController alreay has that delegate implemented? Because we need to know if this connection and authentication was successfull or not in our ViewController so we are able to dismiss the LogInViewController or show an error message if something failed. This is why being able to add multiple delegates is so useful.

So as I said I'm going to make ViewController to comform to the XMPPStreamDelegate:

extension ViewController: XMPPStreamDelegate { func xmppStreamDidAuthenticate(_ sender: XMPPStream!) { self.logInViewController?.dismiss(animated: true, completion: nil) } func xmppStream(_ sender: XMPPStream!, didNotAuthenticate error: DDXMLElement!) { self.logInViewController?.showErrorMessage(message: "Wrong password or username") } }


And that's it! Our app can log in to our server as I'm showing here:


We've been talking a lot about XMPP, stanzas and streams... but is there a way I can see the stream? Yes SR! XMPPFramework got us covered!

XMPPFramework ships with CocoaLumberJack, a pretty well known logging framework. We just need to configure it, set the logging level we want and that's it. Logs are going to start showing up!

Configuring CocoaLumberjack

This is a really simple task, you just need to add to your func application(application: UIApplication, didFinishLaunchingWithOptions ... method the following line (remember to import CocoaLumberjack):

DDLog.add(DDTTYLogger.sharedInstance(), with: DDLogLevel.all)

I'm not going to paste here all the connection process log because it makes no sense to try to understand what's going on at this stage of our learning. But I think showing what some stanzas look like is a good idea. To do this I'm going to be sending messages from Adium.

I'm going to send this <message/>:

<message to=""> <body>This is a message sent from Adium!</body> </message>


Let's see how it looks like when it reaches our app:

<message xmlns="jabber:client" from="" to=""> <body>This is a message sent from Adium!</body> </message>


Let's send a <presence/> from Adium:

<presence> <status>On vacation</status> </presence>


We are receiving:

<presence xmlns="jabber:client" from="" to=""> <status>On vacation</status> </presence>


No doubts at all right? We send something and we receive it on the other end! That's it!

Test Time!

I want to be sure that you are understanding and following everything and not just copy and pasting from a tutorial (as I usually do 

Prosodical Thoughts: Prosody 0.9.12 released

Planet Jabber - 10 January, 2017 - 19:57

We are pleased to announce a new minor release from our stable branch.

This release fixes a few minor issues, and fixes valid certificates failing to verify correctly when Prosody 0.9.x is used with LuaSec 0.6.

A summary of changes in this release:

Minor changes
  • Dependencies: Fix certificate verification failures when using LuaSec 0.6 (fixes #781)
  • mod_s2s: Lower log message to 'warn' level, standard for remotely-triggered protocol issues
  • certs/Makefile: Remove -c flag from chmod call (a GNU extension)
  • Networking: Prevent writes after a handler is closed (fixes #783)

As usual, download instructions for many platforms can be found on our download page

If you have any questions, comments or other issues with this release, let us know!

Peter Saint-Andre: Thoreau on Magnanimity

Planet Jabber - 8 January, 2017 - 00:00
Reading is one thing; understanding is another. Part of what I do while "working through" the writings of a thinker like Thoreau is to delve deeply into key themes, concepts, and even words. Consider, for example, this sentence from Economy, the first chapter of Walden: "To be a philosopher is not merely to have subtle thoughts, nor even to found a school, but so to love wisdom as to live according to its dictates, a life of simplicity, independence, magnanimity, and trust." When reading on the surface, it's easy to gloss over a sentence like this and merely have a pleasant feeling that it's a good thing to live philosophically. Yet what exactly is Thoreau talking about here? What does he mean by the somewhat vague and uncommon word magnanimity? To figure that out can require quite a bit of digging....

Peter Saint-Andre: Corporatization

Planet Jabber - 6 January, 2017 - 00:00
While taking my dog to two different doctors the other day (long story), I discovered that veterinary practices are increasing being bought up by large corporate entities like PetVet and VCA. Your seemingly small, local caregiver just might have sold his or her practice to one of these companies, supposedly while still retaining control over medical decision-making (that little voice in the back of my head is saying "he who pays the piper, calls the tune")....

Ignite Realtime Blog: First Release Candidate of Smack 4.2 has been released

Planet Jabber - 3 January, 2017 - 14:14

The Ignite Realtime community is proud to announce that nearly 2 years after the release of Smack 4.1, the first Release Candidate (RC) of Smack 4.2 has been uploaded to Maven Central. Smack 4.2 marks another milestone in the development of Smack. With the availability of the first RC, the API of Smack 4.2 was sealed. This means that now is the ideal time for Smack users to adopt their codebase to the new Smack 4.2 API, and eventually start using Smack 4.2 in the experimental/development branch of their codebase. Please consult the Smack 4.2 Readme and Upgrade Guide for more information.


I'd like to use this post also to draw your attention at a very important topic. The codebase of smack-core and -tcp has grown historically over the past 15 years. This is not an issue per se. Smack was well designed from the beginning, is now modular and not affected by bit rot. But especially on important class, namely XMPPTCPConnection, has come to age. It is based on threads, when it should use NIO. It uses triggers for state changes, when it should be designed as finite state machine. And some more. I know that a lot of people are affected by Smack creating at least 2 threads per connection (instead of using NIO). This all also contributed at some amount to the latest security vulnerability found in Smack (SMACK-739 / CVE 2016-10027).


The only solution to tackle this would be to re-implement the affected code from scratch. But needles to say that this also would require funding, as it is not a simple one weekend task. I hope to have the resource to do this at some point in the future. If you think you can help, or know someone who possibly would be interested support the funding, then please contact me.

Distribuir contenido