While the XSF may not be mentoring a project in this years Google’s Summer of Code 2014 - we sure can celebrate and shout about the fact that some of the projects include XMPP as part of their project ideas!
The Jitsi project has several projects relating to WebRTC, XMPP and the Jitsi Videobridge.
XMPP/Jingle/WebRTC also plays a role in Mozilla’s project ideas for InstantBird.
To name just a few…
We are really looking forward to seeing many of these exciting projects get implemented by students around the world!
We are happy to announce that Jitsi is taking part in Google Summer of Code 2014 ! We are looking forward to an exciting summer with some very cool projects! Students, have a look at all the project ideas that we have and get paid $5000 to spend the summer working on them!
We are pleased to announce « Salut à Toi » version 0.4, which comes with many important changes, also regarding the project's life.
Salut à Toi is a powerful communication tool, free and multi-frontends. It offers some features like micro-blogging, instant messaging, an easy way to manage groups permissions (elsewhere called « aspects » or « circles »), games and much more.
Constantly designed with ethical and social thoughts (politically speaking), Salut à Toi (abbr.: SàT) is also bound to its social contract.Being based on XMPP, SàT is decentralised and compatible with the other projects that use this protocol.
Before starting with the traditional listing of the new features, a few words about the evolution of the project. We are now two persons working full-time on SàT: so did Souliane, a friend for a long time, join me. We would like to live from the project, but we also want to respect our ideals (cf. the social contract) : we are firmly opposed to commercial advertisements, selling data or any similar behaviors.
We decided to organize ourselves as a self-managed entity, probably under the terms of a cooperative and we would like to start it this summer.There are 3 economical models that we are thinking about:
- the first would be based on donations. This is a precarious model but it would offer us the largest independance in our decisions taking process.
- the second, more trendy, is the use of the so-called crowdfunding platforms. It is finally very close to the donations system, but it requires more work to file the applications etc. Moreover, we would need to select with care the platforms to be used.
- the third one runs more classically, based on services : technical support, specific customizations etc. This is the one model which would leave us the least interdependancy, and the least time to focus on the project itself.
That being said, let's have a look at the change log!The list is quite long (the last version was more than a year ago), here is a selection:Micro-blogging The micro-blogging has been much improved. Comments are now handled, still using the fine access tuning for Pubsub: comments inherit the permissions from the micro-blogs they are replying to. The unibox of Libervia was disturbing many people and it is now optional, the default behavior for typing messages being more classic.
Rich texts have been implemented. The system is quite versatile and it's easy to add new syntaxes that would be available for all frontends.
When you update some content, you can edit it using the syntax of your choice, even if it has been published with another one. Thus it is possible to edit in Markdown a post that has been originally created in XHTML.
For now, XHTML, Markdown and raw text are available, more should arrive soon (for instance Dokuwiki and Dotclear's syntax).
The textual (micro)blogs are now recognizing and displaying inline URLs.In addition to the rich text edition, a WYSIWYG edition (also to be used as a preview feature) is available in Libervia.
And there's still the static blog to display your public messages. It is now completed with an Atom feed. We are getting closer to a full decentralised blog engine and we plan to
move our own blogs to SàT by the next release, so some import tools to migrate from Dotclear and Dokuwiki are to be expected.
It is possible to send messages in carbon copy or blind carbon copy, according to the XEP-0033
The MUC configuration has been implemented (the menu is currently only available in Primitivus)Chat states notifications have been implemented, letting you know if someone is writing to you or if she/he left.
one plugin is adding some IRC-like commands e.g. /nick or /join Command line thanks to Dal, jp – the command line frontend – has been upgraded to ArgParse, allowing a proper commands refactorisation and confirming jp as being an XMPP “swiss knife”.
it's easy to forward a command or pipe output to a contact, but also to create a remote control (see below) or to transfer a file. Some more commands to publish micro-bloggs, manage your roster etc. are planned.
there's a bundled script to offer you the auto-completion with Zsh Misc important work on the extra-features for the discussion rooms. The Collective Radio (allowing the members of a discussion room to upload some music and listen to it at the same time) has been improved, it also handles the user leaving and return.
Ad-Hoc commands are available, allowing to remotely control an entity with any XMPP client
based on the Ad-Hoc commands, a universal remote control has been implemented to offer the possibility to control most of the softwares. A post on my blog is presenting this feature, there's also a short demonstration video featuring VLC
command export : command export : another original feature - it's possible to redirect the input/output of a process to any of your contact (including to another network via a gateway), again the easy way with the fine accesses tuning. There is a demonstration on my blog with an FTP session export to a contact using Gajim
messages notifications are available in Libervia (a contribution from Link Mauve): if someone is talking to you while the tab is hidden, a message should appear on your desktop.
In Libervia: in addition to the drag and drop which was already available, you can click on a contact or a group to open the associated widget. Widgets can now be moved from one tab to another.
considering the importance of the groups in SàT (used a lot to manage the permissions), a roster management user interface has been added to Libervia
a mini XMPP discovery service has been started, it's already running on the libervia.org demonstration server. Under and around the hood: Some heavy refactorisations have been done to ease the development of future frontends e.g for small screen devices.The SQLite database is automatically upgraded.
Some work has been done on the testing system, with the installation of a buildbot ( https://buildbot.goffi.org ) which is running a test batch after each commit.Some SàTellites projects:
- SàT Pubsub (based on Idavoll) is a Pubsub component for Prosody to manage fine access tuning, it's used for micro-blogging
- Urwid SàText (based on Urwid) is a widgets library for console display, used by the frontend Primitivus.
- "Salut" is a XMPP directory, at a very early development stage
In Libervia you can position your widgets over several columns / lines
SàT comes with an IMAP server that let you use a MUA like Firefox or KMail to read your messages Future Beside our projects regarding the cooperative, the following should happen from the technical perspective:
- an important work concerning the security. Until now, we left on purpose this aspect behind, to not do things by halves and fully focus on it when the time has come. So we plan to integrate HTTPS to Libervia, end to end encryption and password encryption in the database.
- finish the micro-blogging support and migrate our own blogs to SàT
- frontends/ports for telephones and tablets, Windows (and Mac?)
- update the Bellaciao frontend (Qt-based)
- RSS/Atom feed integration
- event and calendar management, etc.
- Link Mauve (Emmanuel Gil Peyrot): notifications Twisted plugin for Libervia, style improvments
- Dal: jp profiles management, ArgParse in jp
- Robotux (Thomas Preud'homme): locales correction, distribute update
Come and join us on XMPP MUC room firstname.lastname@example.org
Another update to Pontarius XMPP, a client XMPP library for Haskell, has now been released, courtesy of Philonous.
In addition to a bunch of general improvements and bugfixes, this new version supports plugins (the possibility to transform incoming and outgoing stanzas) and lenses (allowing users to access XMPP-related types more conveniently and composably). Since one of the bugs fixed is quite major (Pontarius XMPP didn’t check the JID of IQResult stanzas), we recommend that all Pontarius XMPP users upgrade.
The Pontarius project will use this new plugin feature to build end-to-end security on top of Pontarius XMPP.
Stay tuned for further updates!
There has been a lot of buzz recently around Whatsapp acquisition by Facebook and the record price paid for the company. FastCompany’s Ainsley O’Connell wrote Inside Erlang, The Rare Programming Language Behind WhatsApp’s Success, giving some technical background around the story.
As the founder of leading instant messaging technology provider developed in Erlang, I want to had a few words on my perspective of this story.
I discovered Erlang in 1998 when it was release as Open Source and I was hooked. I was exploring the potential of the technology and how I could apply it to my internet project.
ICQ was a big thing at that time. Yahoo!, AOL, MSN were launching their own instant messaging service. Jeremy Miller started working in 1999 on an open and federated protocol for instant messaging called Jabber. I started getting interested in that protocol since the very beginning and got the chance with my company at that time to work on early commercial Jabber projects. At that time, the collision between Erlang and XMPP already happened as my company was working on an Erlang layer to turning Jabber first C server into a large scale cluster.
In 2002, I joined Alexey Shchepin that just started building an XMPP server fully in Erlang. We work together for all this years and when I felt the time had come, I founded ProcessOne in 2005. ProcessOne is an Erlang company selling technology and expertise to build large scale realtime messaging services.
We worked across the world with major brands to build messaging services in Erlang with ejabberd. We expanded during the passed years to all kind of messaging realtime application. We have a large scale Push notification service build in Erlang, that is sending billions of notifications. We have build the most used XMPP messaging server, the reference implementation that nearly everyone is using. And we are getting further, building even larger scale platforms for the Internet of Things.
During that time we have seen big companies and small companies embrace our vision. Facebook chat started from our vision: Why was Erlang chosen for use in Facebook chat?:Facebook chat started out as a hackathon project in January 2007, by mid 2007 it became an official project with a dedicated team. Facebook engineers choose to use ejabberd since back in 2007 it was the only chat server which had clustering built in for free. As you can imagine at Facebook’s traffic every service needs to scale horizontally and ejabberd was solving an important problem for them.
Funny thing is that a couple of year laters in june 2009, Whatsapp team is building its own platform sharing the same vision. Here is a post of Jan Koum on ejabberd mailing list: client access control:hi there, i installed ejabberd today, got it work with adium/ichat and wanted to ask you all a couple of things: …
I remember the call that followed with Brian Acton and Jan Koum, talking about our technology and our vision.
And here is the most interesting piece: when Facebook acquires Whatsapp, they also buy a technology that they know fits well with their existing messaging platform.
Finally, this is just two of the success stories our vision, expertise and technology helped sparkled. I would not be surprised that more such success stories arise in the coming months and years.
It all started with ejabberd and we are proud of it !
For us, this is business as usual and just the beginning of a great story.
This Saturday (February 22, 2014), XMPP site operators are again flipping the “encrypt all traffic” switch.
This is the second of four test days kicked off by the manifesto first published last fall. The aim is to encrypt all traffic between servers and clients on the public, federated XMPP network.
You can take part, too: ensure you have valid certificates on your server and that encryption is properly set up (see http://wiki.xmpp.org/web/Securing_XMPP along with the documentation for your XMPP server software), then test your configuration using the tools at the IM Observatory running at XMPP.net.
The manifesto team has managed to push the encryption level up to 12.5% of XMPP server-to-server traffic (see https://xmpp.net/reports.php#starttls). The test days help to keep nudging this value up and to prepare for an “everything is encrypted…or else” day in May of this year (some operators have not flipped back to unencrypted traffic and are now running 100% encrypted servers).
To join the team running the manifesto and thus help to secure the communications of XMPP users everywhere:
- test your server at the IM Observatory
- sign the manifesto at https://github.com/stpeter/manifesto
- chat with other XMPP operators in the email@example.com chatroom
- join the conversation on the firstname.lastname@example.org email list
It’s that easy!
jp ad-hoc remote -g flatmates -- amarokwhere "flatmates" is the name of the group which can control Amarok. You may also want to remote control Okular (e.g. for a talk), or VLC on your phone.Below is an example with VLC.
The syntax may seem complex in apparence, it's actualy very simple:
- " jp ad-hoc remote" tell that we want a remote control
- "-pgoffi" say thaat we want to use the profile "goffi", but if it's the default profile, it's not needed
- "-cl" the "-c" means "connect this profile if it's not already done", the "-l" means that we want to loop on commands (after launching a command, we will return to the command menu instead of finishing the ad-hoc session).
- "-g coloc" is a filter (coloc mean "flatmates" in french): it tells that in addition of your own jid, the jids from the group "coloc" are allowed to use the remote
- " -- vlc" the "--" is just here to terminate optional arguments, and "vlc" is the name of the software to control.
once the command entered, SàT fill look in D-Bus's Session bus to find buses which have "vlc" in their names, and add commands which don't need arguments. The output show what has been found.
Now, let's see how we can use the remote in Libervia (web interface of SàT):
We use the remote with the ad-hoc "commands" menu
we enter the jid which exported the remote. So far, we have to enter manualy the full jid, but in the future, a simple right click should be enough.
vlc is indeed visible in commands
and voilà ! Commands are available. Once again, it's a bit unfriendly at the moment, but it will be easy to replace common names like "play", "stop", "previous", etc with nice icons...
And it's of course working with every XMPP clients featuring ad-hoc commands, like Gajim or Psi (here Louise can use the remote control created by Goffi because she is in her group "coloc").There are many advantages: ease of use, it's generic (the software just need to have its commands exported via D-Bus, which is pretty common on freedesktop environments like Kde, Gnome or XFCE), authorisation can be easily managed, and it works everywhere where an XMPP client featuring ad-hoc commands is available. An another proof that XMPP can be used for far more than just instant messaging, and a demonstration of the potential of jp, the command line frontend of SàT...
To conclude, a short demo video (in french).
As usual, to watch the video you can use a recent browser (the last Firefox/Iceweasel for example).
You can also use VLC (version >=1.1 only), by using the "Media/Open Netword Stream" menu and by entering this URL: http://www.goffi.org/videos/pr%c3%a9sentation_S%c3%a0T_7_t%c3%a9l%c3%a9commande_universelle.webm
Last but not least, you can use mplayer:: mplayer "http://www.goffi.org/videos/pr%c3%a9sentation_S%c3%a0T_7_t%c3%a9l%c3%a9commande_universelle.webm"
this video is licenced under Creative Common BY-SA
Zurl is a gateway that converts between ZeroMQ messages and outbound HTTP requests or WebSocket connections. It gives you powerful access to these protocols from within a message-oriented architecture. The following diagram shows how Zurl may fit in among the entities involved:
Any number of workers can contact any number of HTTP or WebSocket servers, and Zurl will perform conversions to/from ZeroMQ messages as necessary. It uses libcurl under the hood.
The format of the messages exchanged between workers and Zurl is described by the ZHTTP protocol. ZHTTP is an abstraction of HTTP using JSON-formatted or TNetString-formatted messages. The protocol makes it easy to work with HTTP at a high level, without needing to worry about details such as persistent connections or chunking. Zurl takes care of those things for you when gatewaying to the servers.
In the past couple of years, a number of attacks have been found on “TLS”, but often those attacks were only shown with HTTPS. The majority of TLS encrypted traffic is probably HTTPS, but it’s important to understand which of these attacks can be translated to other protocols. I’ll use XMPP, but I’ll try to get the attacks down to the core features the used protocol needs to support to help others determine which other protocols are also vulnerable.
I shall mostly assume that the attacker knows your full JID and is therefore capable of routing stanzas to you. This may not always be realistic, but targeted attacks do happen.The Target
First of all, there needs to be something that is going to be extracted. Something secret that was transmitted which the attacker wants to obtain. For HTTPS, this is often cookies: they are transmitted often, an attacker can cause them to be retransmitted whenever they want, and they (often) give full access to your account. Other attacks attempt to extract data from the body of a page, like email addresses.
On XMPP, possible targets include:
- The user’s password (assuming we’re using SASL PLAIN)
- If we wouldn’t have it yet, the user’s JID
- The user’s contact list
- Message meta-data
- Message content
BEAST exploits a problem with CBC mode in TLS which leads to predictable IVs. CBC mode is a block cipher mode that xors a plain text block with the previous cipher text block before encrypting it, to ensure equal plain text blocks do not turn into the same cipher text blocks. However, TLS 1.0 also does this when that block has already been transmitted. This means the attacker can observe that block and pick the next block to be encrypted based on that information.
In other words, suppose P[i] are the plain text blocks the client sends and C[i] are the cipher text blocks. Then C[i] := AES(P[i] XOR C[i-1]). Suppose C[a] was the last block of a packet. Then, if the server could somehow convince the client to send P[a+1] = C[a] XOR Q, then the encrypted packet will be C[a] = AES(P[a+1] XOR C[a]) = AES(C[a] XOR Q XOR C[a]). If you recall the properties of XOR, this is equal to AES(Q). So the attacker can obtain the encryption of any block Q!
This is what’s known as an encryption oracle. The attacker can pick any value Q and obtain its encryption, but it can not decrypt anything. But by making clever guesses, the attacker might be able to obtain the decryption of specific blocks, if they guessed correctly. Suppose the attacker is interested in the contents of the bth block, then the attacker must make a guess of what that block was, lets call its guess B, and it will make the client send B XOR C[b-1] (to account for the CBC mode). If AES(B XOR C[b-1]) was equal to C[b], then the attacker knows their guess was correct and that P[b] = B. If the guess was wrong, the attacker will have to try a different value instead of B and continue until the encryption is equal.
Now, guessing even a 10 character cookie or password correctly is going to take a long time, so BEAST uses another trick: it will insert content before the cookie to make sure the first character of the cookie falls in one block, but the rest of the cookie in the next. If the attacker does know the rest of the block, it only needs to guess one character, which can be done quite quickly. For the next connection, the attacker will insert one character less, so two characters of the cookie fall in the first block. It already knows the first one of the two, so it again needs to guess only one character. It can continue this until it has the entire cookie. This means the attacker is able to guess a long cookie in quite a low number of guesses.On XMPP
Attacking the password on XMPP is much harder, as the attacker can not insert new content before the password. It is quite likely the password spans different blocks, but that still leaves a large number of possibilities. The contact list is likely also too hard to guess without any prior information. Guessing the JID might be possible if the attacker has a list of all users on the server, but if the attacker didn’t know the JID, it would be much harder for them to actually do this attack.
Guessing messages is also hard, but obtaining message meta-data might be possible.
Suppose the attacker already has a list of contacts who are on my contact list. I send a packet and the attacker is interested in finding out whether it was a message to one of my contacts, and if so, to whom. Here’s the plain text of the message, shown split at the block boundraries:1: <message type='c 2: hat' id='purplea 3: 1074a2d' to='jul 4: email@example.com 5: om'><active xmln 6: s='http://jabber 7: .org/protocol/ch ...
The interesting info is spread over blocks 3, 4 and 5. However, block 3 also contains part of purplea1074a2d. We can guess this (hint: it’s an incrementing counter), but lets suppose we don’t know it, just its length. The attacker can use BEAST to test every person on my contact list to the 4th block, leaving out the first 3 characters and using at most 16 characters of every JID. It might fail (the attacker doesn’t know for sure it’s a message, it could be an <iq/> stanza or groupchat message), but if the message is for one of my contacts, the attacker will find that.
There is, however, one more requirement on BEAST that we need to satisfy: the attacker must be able to fully specify the first block in a new packet. It won’t work if it’s a later block. In general, the client will only start new packet with a new stanza. So the packet will almost always start with <iq, <message or <presence, and anything the client sends must be valid UTF-8 and valid XML. Therefore, making the client send B XOR C[b-1] exactly is very hard.
One way the attacker might try to get the client to use certain contents in its first block is by sending the target an <id/> with the payload in the ‘id’ attribute:1: <iq id='�u��_$ճH 2: ' type='get' to= ...
The client will then mirror the ‘id’ and send a reply or error back:1: <iq id='�u��_$ճH 2: ' type='error' t ...
But because of the prefix, the attack can only be successfull when B XOR C[b-1] happens to start with <iq id='. The probabilty of that happening is 2-64, which is neglible.Conclusion
The main requirement for BEAST is that the attacker must be able to choose the block a client will use as the start of a new packet. Additionally, the secret needs to be either easy to guess or it needs to be movable by the attacker so it can be placed on a block boundrary. I do not know of a way to do the former in XMPP, so it is unlikely XMPP is vulnerable.
Finally Tigase XMPP Server 5.2.0, dubbed FTL - Faster Than Light, has landed in it's destination (that is our servers) and it's available for download. As always - binaries are available for download in the files section on the project tracking system. Sources are available in our code repository under the tag tigase-server-5.2.0 - tags/tigase-server-5.2.0. Maven artifacts have been deployed to our maven repository. To put a cherry on top we also run automated tests - successful results are available in our test page.
It could be expected that this version is not only blazing fast but is also packed with features - to recapitulate what has already been mentioned regarding 5.2.0 in previous posts (Tigase XMPP Server 5.2.0 RC2, Tigase XMPP Server 5.2.0 RC1, Tigase XMPP Server 5.2.0 Beta3, Tigase XMPP Server 5.2.0 Beta2, Tigase XMPP Server 5.2.0 - FTL - Beta1):
Major additions to the Tigase XMPP Server in this release:
- HTTP API with REST as the Tigase server component
- Websocket support as a Tigase server connection manager
- Message Archiving Component - XEP-0136
- Socks5 Proxy Component with lots of interesting functions - RFC 1928
- STUN Server Component - STUN
- XEP-0198 - stream management extension with full support with ACK and Stream resumption. It is fresh but extensively tested already. If you do not have software to check it out or to test it, you can either use our JaXMPP2 client library which offers full support for the XEP or have a look at our Android client which can also make use of it.
- XEP-0280 message carbons extension. Similarly to the above XEP full support for it is also included in our client side library and mobile messenger.
- Tigase ACS - which includes main clustering strategy as well as MUC and PubSub cluster-enabled components! Those are not open source but we make them available for free for development and testing.
- In addition to Derby, MySQL and Postresql Tigase now supports as well MS SQL Server.
- Top notch improvements in security (v. Tigase XMPP Server - grade A software).
- Inclusion of new PubSub 3.0.0 which features performance improvements due to reworked schema (v: PubSub database schema conversion),
Other changes which have been made in this release:
- Switched JDK compatibility to JDK7. Number of issues in Tigase server were related to bugs in JDK6 and patching them and creating workarounds was taking up resources. Therefore we decided to switch over to JDK7.
- Optimization to sending presence.
- Cluster auto-configuration with cluster mode active by default.
- OSGi support built-in to the core of the Tigase XMPP Server.
- New API for SASL extensions and custom SASL mechanisms.
- API changes in plugin/processors, old API still available although deprecated, new API way faster and less resource consuming.
- Optimizations, lots of them, we expect this version to be significantly faster and use less resources.
- Some metrics names changed to avoid confusion whether this is a number of elements waiting in queue or number of packets already processed.
- Custom RosterAbstract implementation can be now plugged from a configuration file.
- See-other-host implementation improved, now the redirection can be sent to the client after successful login. Still most of XMPP clients do not support this part of RFC so it is optional.
- Improved multi-threading support, Timer replaced with ScheduledExecutorService where appropriate to avoid Timer single-thread bottleneck.
- Extended per-vhost configuration at run-time with new parameters: s2s secret, default filtering policy.
- Changed the way Tigase delivers messages to bare JID - now more common practice, delivers to all active resources.
- TLS required - full implementation, now Tigase won't allow user authentication without TLS if TLS required is set.
- The server whole active configuration is dumped to a text file which can be reviewed and/or copied to init.properties with custom values.
- Invisibility through the extension - XEP-0186.
- Improved IPv6 support.
- Clientaccesspolicy.xml support added.
- Lots of s2s improvements and bug fixes.
- Fixed a bug in service disco plugin and all plugins extending XMPPProcessorAbstract with a packet delivery for non-existen resource.
- Improved discovery of sessions with stale connections (#1363).
- Implemented ability to set list of enabled SSL/TLS protocols using 'tls-enabled-protocols' system property.
- Implemented ability to disable client certificate request using 'sasl-external-disabled' system property.
- Fixed issues with forking messages with type other than chat.
- Fixed returning feature-not-implemented for requests without element (#1418).
- Add number of active users to statistics.
- Added Content-Length header in response to OPTIONS request even if there is no content.
- Fixed sending requests for ack if queue for ack size is bigger than default value of 10.
- Inclusion of HTTP component to the installer (#1384).
- Add heap memory setting, correct script path (#52).
- Increased security level (#1628).
- Added implementation of optimizations for mobile devices - MobileV3.
- Execution of vhost ad-hoc scripts on all nodes in cluster mode (#1587).
- Fix issue with garbled passwords during in-band registration/password change (#826).
- Fixed problem with service discovery incorrect display when a component changed description after it has been initialized.
- Improvements in XML DoS protection (#1364).
- Automatic roster subscription (presence and jabber:iq:roster plugins has new optio: auto-authorize; setting it to true results in automatic, mutual “both” subscription state for both user and contact).
On December 20th 2013 the XSF received some very exciting news, to end what had already been a great year – ISOC were awarding the XMPP community an incredibly generous gift to help support the work we are doing in improving privacy and security.
In their own words:
“The Internet Society takes a great interest in projects that will improve our existing mechanisms for on-line privacy and trust and we appreciate the XMPP Standards Foundations leadership in securing XMPP services in the wake of recent events. We know that the XMPP community is working to ensure ubiquitous TLS encryption on the public XMPP network, use DNSSEC and DANE in XMPP, more widely implement the Off-the-Record (OTR) protocol, and support both key pinning and certificate transparency.”
The XSF has already thanked them directly, but we wanted to share the great news with our wider community.
We are confident that 2014 is going to be a great year, and we look forward to sharing what this gift has enabled our community to do.
Here’s to 2014!
We will be upgrading our servers in the coming weeks. There will be some down time this weekend, February 15th-16th. There may be shorter interruptions following that as we tie things together.
Please bear with us and thank you for your continued support!
We have fixed a few bugs and a some minor issues, so it's time for another release!
A summary of changes in this release:
- A config file passed as command line argument is no longer forgotten when config is reloaded
- MUC: Allow admins to always bypass restrict_room_creation
- Strip trailing '.' when normalizing hostnames
- HTTP: Prevent silent connection failures
- Components: Allow easier overriding of component authentication by plugins
- Components: Enable TCP keepalives
- Migrator: Better error reporting and improved robustness
- S2S: Include IP in log messages, if hostname is unavailable
- TLS: Log error when initialization fails
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!
Hi there, I'm Smack's new maintainer. Some of you may know me already as the maintainer of aSmack, the Android port of Smack. I first like to thank Robin for his work on Smack in the past.
Smack has a long development history. The first recorded commit dates back to Jan 13 2003. Now, over 11 years later, we are going make fundamental changes to Smack in order to ensure that it will last another decade.
Most importantly: Ignite Realtime is applying as Google Summer of Code organization. We propose a project to modernize and modularize Smacks build system. One reason why this is necessary, is that we want Smack to be able to target Java SE and Android. Read more about it here.
Smacks SVN repository has been migrated to git, and the code is now hosted on GitHub. We are currently evaluating hosting the code in our own Atlassian Stash, but that isn't decided yet and is not a high priority right now.
Let's have a look at Smack's contributors of the last 11 years:
513 Gaston Dombiak
474 Matt Tucker
105 Thiago Camargo
104 Florian Schmaus
69 Alex Wenckus
46 Bill Lynch
43 Derek DeMoro
24 Günther Niess
15 Daniel Henninger
12 Henning Staib
7 Michael Will
7 Wolf Posdorfer
6 Holger Bergunde
6 Jeff Williams
5 Jay Kline
4 Marilyn Daum
3 Francisco Vives
1 (no author)
1 Andrew Wright
1 Pete Matern
1 Tim Jentz
Hopefully this list will grow over the time. If you'd like to contribute bigger patches to Smack, please consult the developers. Either via IRC #smack (freenode) or via the developers forum. All patches will be reviewed, since there are usually a few things that should be improved before the commit is ready for Smack's master branch. Make also sure to read the Guidelines for Smack Developers and Contributors.
Besides the GSOC project, there are more goodies in the queue, like XEP-0198 Stream Mangament and Roster Versioning.
We also work on migrating the build system to gradle, including deployments to sonatype/maven central. I expect the next release to be available as jar and via maven central.
Finally, shortly after the 3.4.0 release, a memory leak was reported in the forum. The cause was , and a fixed nighlty release was made availabe shortly after. I am going to use this importand fix as reason to release Smack 3.4.1 today, in order to get familar with the release process of Smack.
A couple of years ago I wrote the buddycloud channel directory as my GSoC’12 project and as my first buddycloud project to go live in production.
The component is running fine in search.buddycloud.org, however the crawler wasn’t crawling as we required. The crawler was designed on top of XEP-0060, and uses smack with its pub-sub extensions to discover Buddycloud channels and items on the Buddycloud channel server.
But then comes a day when you get the guts to look at old code. Reason: the crawler was dumb dumb. It crawled every single item of every single node every time it ran. Stupid, eh? But there’s more: by using smack’s XEP-0060 implementation, the crawler missed an important feature that the Buddycloud XEP specifies - XEP-0059, a.k.a. RSM.
The Buddycloud XEP uses RSM in several occasions, eg.: disco#items and pubsub <items>.<iq type=’result’ from=’channelserver.example.com’ to=’firstname.lastname@example.org/KillerApp’ id=’items1’>
<entry xmlns=”http://www.w3.org/2005/Atom” xmlns:thr=”http://purl.org/syndication/thread/1.0”>
<content type=”text”>A comment, wondering what all this testing does</content>
<!— [more items…] —>
Thus, we needed to somehow integrate RSM on smack to get the crawler properly working, so that it could page through all results that the channel server provides and avoid looking into the past when not needed.
Finally, we achieved that by creating a class that works as a packet extension called RSMSet and by overriding some of the PubSub classes offered by smack, such as the PubSub class itself. Now, when we need to do RSM, we ask the PubSubManager for a new PubSub packet and then inject the RSMSet extension into it. As in:DiscoverItems discoRequest = new DiscoverItems(); discoRequest.setTo(discoverInfo.getFrom()); RSMSet rsmSet = new RSMSet(); rsmSet.setAfter(discoverInfo.getRsmSet().getLast()); discoRequest.setRsmSet(rsmSet);
And then, we store the last item crawled in every node inside the directory’s database, so the crawler can be smarter about what to crawl.
Next step on performance improvement list: crawl the /firehose when possible.
Yesterday's release of Openfire 3.9.0 had some problems with packaging of the release. Bouncycastle signed jar files were getting packed, which then caused problems when Openfire attempted to load them. We have hopefully fixed this issue and cleaned up a few other details and are proud to announce a 3.9.1 release!
Openfire is a real time collaboration (RTC) server licensed under the Open Source Apache license. It uses the only widely adopted open protocol for instant messaging, XMPP (also called Jabber). Openfire is incredibly easy to setup and administer, but offers rock-solid security and performance.
The download page offers these files and here are their md5sums for your comparison.
Please report any issues to us in the forums. We are always looking for developers to help improve Openfire, so please let us know if interested!