When our newest Board of Directors were elected, they decided that they wanted to set some goals against which their achievements as Board members could be measured.
And so this journey began…
We started by asking the community what THEY cared about and what they wanted the Board to focus on.
We took this information, turned it into measurable objectives and then asked the community to vote – what did they think the most important areas to focus on? There was a lot of debate here, and we listened – the measurables could have been something else, there are other ways of looking at this etc – but, we had to commit to something or a year on we would still be working how to measure what we were doing!
And this is what got decided (the meeting minutes can be found here.)
% based goals
We recognised that there were two top scorers – website traffic and membership engagement. While membership engagement is of obvious importance, the Board felt that engagement would be covered by other activities and was possibly too inwardly focussed.
And that is where we are at. The % based goal and XMPP positioning are both being worked on at the moment, through the development of our new website.
We will keep you posted with our progress…
ejabberd 15.03 is yet another important release. We have added fixes and some major improvements.
You can learn more about the changes and roadmap by meeting part of the team in upcoming ejabberd San Francisco Meetup.New features Websocket
Websocket support is among the major new features introduced in this release. You can write speedy XMPP web clients. This web support has been tested on large deployments and is extremely fast, with very low latency.
More details on ejabberd Guide – WebsocketCustomizable session backends
We have introduced a new major feature to give more flexibility in the way sessions are managed in ejabberd. In the past, session were managed in Mnesia because it was the best compromise between speed, latency and scalability. However, ejabberd is deployed on a large variety of usage patterns and platform types and sizes. We thus have decided to provide more flexibility to accommodate with various use cases. For most deployments Mnesia is still the default choice and best backend to store sessions. For corporate deployments that need to get easy access to online users and status from other components, we provide a SQL backend for live sessions storage. Finally, if you want to avoid duplicating session across nodes to deploy a larger cluster, you can store your session information in a central, fast, in-memory backend like redis.
This improves scalability or flexibility depending on your platform type.Security improvement: SCRAM support for SQL authentication backend
If you use the default ejabberd SQL authentication backend, you can now enable password encryption in the database using the standard SCRAM approach. We also provide a tool to migrate your existing authentication database to the new SCRAM secure scheme.Development community and Elixir improvements
ejabberd 15.03 is also the continuation of 15.02 in the way it simplifies the development and management of contributed modules. The community is growing with more code being contributed by third party developers. You can already find many modules contributed by the community. And now you can even install contributed modules without having developer skills or module compilation.
Interest around ejabberd has been accelerating with the introduction of Elixir. This release improves Elixir support. Moreover, you can now write ejabberd tests in Elixir and they are ran transparently with the rest of the test suite.Package management
This feature allows you to install easily ejabberd contributed module, with a simple command like:$ ejabberdctl module_install modulename
You can find more details on this blog post: Easy installer and structure for ejabberd contributed modulesSimple add cluster command
With our constant desire to simplify deployment we added a new ejabberdctl command to add a node in a cluster in a single command. Those who went to the process of setting up a cluster will certainly love this new command:$ ejabberdctl join_cluster ejabberd@existingnode
More details here: Adding a node in a clusterChangelog overview
As a summary, here is the high level changelog:
We were missing an index on privacy list in the default MySQL schema. The database schema has been updated.
If you want to apply the changes on a running instance, here is the SQL command to issue:
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 you found a bug, please search or fill a bug report on Github.
A slightly tardy share, but we have the presentations from Summit 17 in Brussels starting to trickle in!
As more come in, this post will get longer (and hopefully have a more permanent home on the new site) but here we go:
With their active blog xmppresearch.org, researchers from RWTH Aachen University and TU Dresden are contributing to an ongoing collection of academic works around XMPP, including a high-quality bibliography, demos and reviews. Domink Renzel presented their work and their goals to the Summit members.
Blogging via XMPP
Sergey Dobrov walked us through federated blogging and a combination of XMPP & PubSub/PEP. The presentation includes a call-out for help, and hwo you can get involved.
We would love to showcase more of the presentations, so if you have anything from the Summit you would like to share, please get in touch!
(photo credit: Doc Searls - silos)
Benedict Evans writes that the three phases of messaging were always about unbundling expensive services based on price arbitrage. But what comes next?
Phase 1: Unbundling International voice calling. Remember how prohibitive calls across a border were? Skype won this!
Phase 2: Unbundling Mobile-based messaging. SMS was squeezed by BBM and similar services. The competing services force operators to compete: 10c/SMS collapses to “unlimited SMS” packages. Line, WhatsApp and a hundred others messaging services bloom.We are now at Phase 3
Phase 3: The generic data layer. “Why can’t we just communicate between services?” To use Benedict’s example, “Why is it that if I use a cab service app I can only talk to the driver by a PSTN voice call or SMS? Why does a restaurant booking app send me out to the phone dialer?” Phase 3 will play out with Apps just as WhatsApp will, but with live voice and SMS, being unbundled. WebRTC goes some way to providing a data layer between devices. WebRTC is the a BYOS (bring your own signalling) transport.
When every mobile and web developer can easily add messaging to their app, the power of WhatsApp’s et al.’s ad-hoc messaging communities will shift to specialist apps.
The next unbundling will start on the long tail of messaging: if the fat head of messaging is WhatsApp and Line, the long tail is the tens of thousands of apps that include a way for users to communicate. The long tail includes the AirBnB app where a guest communicates with their host, the Uber app that connects the driver with the passenger and the kidney-disease-support-group app where patients message each other. And thousands more.
The unbundling, as with the previous two phases, will be bottom-up: developers experimenting on weekend projects, apps emerging from studios, and the “fat-head” of mainstream messaging apps being replaced.Messaging is now free
Now we’re in a world where messaging is essentially free (both to use and to run) and we’re also in a world where every developer likes to invent their own messaging service. There’s also a race to offer ever cheaper messaging backends to developers. With WebRTC built into every browser, we can assume we’ve reached free. If one subscribes to Peter Thiel’s Zero to One thinking: this would be the globalisation stage of messaging.What’s coming next
Phase 4: unbundling the silos
To understand how the next stage plays out, it’s useful to look 30-odd years ago at the roots of, arguably the world’s most successful app, email.
Back in, Eric Allman’s sendmail pulled together email from the UUCP network, ARPAnet mail and BerkNet mail systems into one unified system. Users no longer needed to switch between systems to contact other users outside of their mail silo. Eric created a flattened namespace and service to route messages between silos: he federated incompatible messaging silos. And while some of the addressing looked odd (domain!user), users didn’t have to log in and out of different systems to communicate. Eric’s design also meant that organisations could easily join the mail network simply by using an agreed-upon protocol.
The ecosystem of email succeeded because it was an open protocol, implementable by others (sendmail was open source) and most importantly it federated between sites. Back in the pre-cloud days it was also “on-premises”.
Applying this sea change from 30 years ago to messaging: messaging will be apps built on a flat namespace with backend services that interconnect. The specialised silos will still exist but interconnect (Compuserve mail eventually interconnected with AOL mail and even SMTP based email).
No more: I’m greg99 on this service but if you want to reach me on Wire then I’m greg.watson and on this other service I’m known by my phone number. The future will be just firstname.lastname@example.org everywhere: email@example.com on Future-instagram™, firstname.lastname@example.org on future-twitter™ and email@example.com on cat-social-network™. Some might call this “bring your own identity” (BYOI).
Summary: The fourth phase of messaging will be federation of the silos using an open protocol with a flat user namespace.Working on the Fourth Phase
At Buddycloud we’re trying to work on this fourth phase, a “generic data layer” and signaling for messaging. Developers can add the stack to their apps and save development time. Moreover they plug into a larger ecosystem of existing users and services.
If Buddycloud does its job well, we help other companies grow the ecosystem too (for example Surevine Ltd produces a really nice Buddycloud frontend for security-sensitive customers).
From working with customers, we have noticed is that it’s really important for customers to be able to extend messaging. Developers seek more than one-size-fits-all messaging. For example we find that developers each want different message formats and different application logic on the backend.
We also notice that, security is really important - this usually plays out as customers wanting on-premises deployments (for example, the finance or healthcare industries).
Another thing that we have discovered: communication needs to extend beyond the firewall of each enterprise: Imagine only being able to email people inside your organisation. (Remember only being able to email other uses on compuserve - never outside?) It’s quite conceivable to need to communicate with a supplier. When viewed like this network federation is a natural extension of any communication network.
We’re working on Building the fourth phase of communication at Buddycloud. Realtime messaging and video calling between users on any network, anywhere in the world should become as natural as email.
PS: we’re looking for smart engineers to join the team.
Ejabberd comes with a lot of modules, but sometimes you may need an unsupported feature from the official sources or maybe you need to write your own custom implementation for your very special needs.
For many years, such contributed modules are stored on ejabberd-contrib repository.
However, these modules required manual compilation. This means having Erlang/OTP installed, a base knowledge of how to compile ejabberd modules and manual maintenance when ejabberd’s api is updated over time.
Complex operations to manage ejabberd contributed modules is now behind us. ejabberd is now able to fetch module sources by itself, compile with correct flags and install in a local repository, without any external dependencies. You now longer need to know Erlang and have it installed in order to use the contributed modules. This works with ejabberd modules written in Erlang and will also support new Elixir modules.ejabberdctl module_install
Before getting started, you need to use ejabberd official repository on Github. We are gathering feedback before you see that command in the next stable release. It will work with ejabberd HEAD, starting from version 15.02.77 (aa1250a). Once you have an ejabberd compiled from source installed, you can start playing with the commands.
As a user, this is how it works:
First you need to get/update the list of available modules:
$ ejabberdctl modules_update_specs
Then you can list available modules
$ ejabberdctl modules_available
mod_admin_extra Additional ejabberd commands
mod_archive Supports almost all the XEP-0136 version 0.6 except otr
mod_cron Execute scheduled commands
mod_log_chat Logging chat messages in text files
Let’s give mod_cron a try:
$ ejabberdctl module_install mod_cron
This command installs mod_cron from ejabberd-contrib repository. An example default configuration is installed in:
All you have to do is to copy paste the module and add the values in there in the proper place in your ejabberd.yml config file. Be careful, the snippet can include ACLs, listeners and module configuration, that you have to put in the right place in your config file.
Now, check your new module is installed:
$ ejabberdctl modules_installed
And finally, you can remove it:
$ ejabberdctl module_uninstall mod_cron
Please note this is provided as a beta version. We want the work in progress to be released early to gather feedback from developers and users.
For now, you need to edit the configuration snippet provided in module’s conf directory and copy it into your ejabberd’s main configuration. Then you’ll need to restart ejabberd or manually start the module.
However, our plan is to keep iterating on the tool and to make our best to make module installation as easy as possible and avoid need to change main configuration: ejabberd should be able to include module configuration snippets on the fly in a near future.As a developer, how can you provide an ejabberd contribution ?
As a developper, you still need Erlang and Ejabberd if you install everything from sources, but you can even not need Erlang if you installed ejabberd from official ProcesOne installer. The official installer includes everything needed to build ejabberd modules on its own.
First you can work on your own module by creating a repository in $HOME/.ejabberd-modules/sources/mod_mysupermodule, and creating a specification file in YAML format as mod_mysupermodule.spec (see examples from ejabberd-contrib). From that point you should see it as available module.
Before commiting your code, you should check if your module follows the policy and if it compiles correctly:
$ ejabberdctl module_check mod_mysupermodule
if all is OK, your’re done ! Else, just follow the warning/error messages to fix the issues.
You can keep your repository private in this location, ejabberd see it as an available module, or you can publish it as a tgz/zip archive or git repository, and send your spec file for integration in ejabberd-contrib repository. ejabberd-contrib will only host a copy of your spec file and does not need your code to make it available to all ejabberd users.Conclusion
We have a bright vision for the ejabberd modules ecosystem and this is just the first step. We are waiting to hear from you. With your feedback, your ejabberd installation with instantly become much much more powerful.
If you do not yet know Archipel, you should give it a look as it is one of the killer project running on top of ejabberd. Every sysadmin using XMPP as a chat client had a dream at some point: Wouldn’t it be cool to be able to control all the servers of my organisation by chatting with them, getting status update, etc.
Archipel makes that dream come true and much more. Archipel is a solution to manage and supervise virtual machines. It is fully based on XMPP for the realtime component and thus make an heavy use of ejabberd nicest features.
Here is a teaser video about Archipel:
If you are in the Bay Area on the 25th, do not miss the opportunity to meet them. You can register for the meetup here: ejabberd San Francisco Meetup #1.
Tigase JaXMPP 3.0.0 Client Library has been released! This release includes many major changes, as well as numerous bug fixes. Binaries are available from the project's files section.
Since 2002, ejabberd established itself as a major Erlang project. People learn Erlang because of ejabberd. For this reason alone, ProcessOne is one of the major contributors in the open source Erlang community, along with Erlang OTP itself (heavy investment from Ericsson), Elixir mainly from Plataformatec, Riak from Basho, Cowboy from NineNines, ChicagoBoss and Zotonic.
However, ejabberd is just the tips of the iceberg. When we decide to make ejabberd more modular in 2013, we split the code base into small reusable components. They are now “ejabberd dependencies”, but of course count as major contribution from ProcessOne as well and can be reused and improved independently.
This post is a walkthrough all ejabberd dependencies, as multiple spin-off effort of ejabberd development process:ejabberd dependencies
ejabberd code based is split among several repositories so effectively ejabberd code is much more than what is in its primary repository.Required dependencies
The main ejabberd repository is processone/ejabberd
There is hundreds of forks, but we actively maintain ejabberd to make it the most reliable and up to date version. This is thus your best starting point.
When you build ejabberd yourself, the build chain will download a few Erlang dependencies:
Then, we use a few other dependant repositories that may be used if you have enables support in the configure script.
Here are the dependancies for relational database support:
Here are the dependencies for Elixir support:
Here are the dependencies for Riak support:
This is just a taste of what ProcessOne has been building over the past 13 years. I could also mention other major contribution as Tsung, the most scalable and affordable benchmarking platform available. That can be used for testing large scale web or XMPP platforms.
The Ignite Realtime community is participating, as part of the XMPP Standards Foundation (XSF) GSOC organization, in this year's Google Summer of Code. Besides various Openfire projects, there are two Smack related ones:
All XMPP project ideas can be found at the XSF wiki: Summer of Code 2015 - XMPP WIKI
Furthermore we are proud to announce the availability of Smack 4.1.0-rc3, which should fix the last outstanding issues with Stream Management (XEP-198).
Also the first alpha version of Smack 4.2 has been released. Smack 4.2.0-alpha1 is basically Smack 4.1.0-rc3 with two major modifications that introduce the first big API changes in Smack 4.2:
We have a very large number of users in San Francisco Bay Area. ejabberd scalability and flexibility is a perfect fit for startup and we are proud to be powering realtime messaging in the Silicon Valley. As such we have been asked many time to host an event where people working on ejabberd, XMPP, Erlang and Elixir for realtime messaging can meet each other and discuss.
That’s now done and we are very happy to be able to launch ejabberd San Francisco Bay Area Meetup. The first meetup will take place on the 25th of march 2015 in San Francisco. Registration is free and you are welcome to join: ejabberd SF Bay area Meetup #1
If you attend it would be very good if you could have a slide ready to introduce your project in a few minutes. That’s a great way to get exposure and feedback on your architecture, design and features. If you just come to learn and discover, do not be shy, that’s fine as well and you are welcome.
I (Mickaël Rémond, Founder of ProcessOne, ejabberd Lead), will introduce the new features introduce in ejabberd v15.02 and v15.03. I will present the roadmap to show what is the next frontier for ejabberd project. I am also preparing a surprise announcement with the team, so be sure not to miss the event.
See you in a while in San Francisco !
Buildroot can generate any or all of a cross-compilation toolchain, a root filesystem, a kernel image and a boot loader image. The generated root filesystem contains a libc (uClibc, glib, eglibc or musl), busybox and some extra packages. Now buildroot allows to include Erlang and ejabberd in the generated root filesystem.
This makes very easy to build a custom and robust xmpp server for your embedded hardware, router or appliance, as buildroot is designed with simplicity in mind.
ejabberd project and developers are involved as mentors in Google Summer of Code 2015 initiative. This article explains what it could mean for you as a student wanting to contribute to our project.What is Google Summer of Code ?
Google Summer of Code (GSoC) is an annual program in which Google awards stipends (US$5,500) to all students who successfully complete a requested free and open-source software coding project during the summer.
We have been contributing ideas and will be helping students enrolled in two distinct mentoring organisations:
Students are free to get involved in suggested ideas, but can also propose new project ideas on their own.Why get involved in GSoC, working on ejabberd ?
For a student, GSoC is a great opportunity to learn new skills, learn to work with a team of experienced developers, help open source projects and get a fair compensation.
ejabberd is one of the most used XMPP server in the world, deployed on huge scale deployments in large corporations. This is a unique chance to get your code running for tens of millions users and have a real impact with your code.
The suggested ideas should be quite interesting and challenging but still manageable to be completed during the summer. Of course, we are open to your own suggestions.
Here are a few of the idea we have put together, in no particular order:
So, what is the process ?
You will need to submit a proposal on GSoC website, for either XSF or Beam Community. Students should pick their projects and submit proposals from 16th to 27th March. Do not be afraid, you are not alone and, as experienced mentors, we are here to help. You can get in touch with our team (On XMPP groupchat, of course), in the chat room firstname.lastname@example.org.
Please, make sure that you are eligible before investing time on the project. Details are available on Google Summer of Code 2015 Student Participant Agreement.
All the ejabberd community is looking forward working with you !
We’ve just had the great news that Google have again accepted the XSF to mentor XMPP-related projects in the Google Summer of Code this year. GSoC is a programme whereby Google pays students a stipend to work on open source projects for the summer, and when we’re able to participate in this it’s a highlight of the year for us. If you are, or know any, talented students with an interest in realtime communication systems we’ve got a selection of interesting projects at http://wiki.xmpp.org/web/Summer_of_Code_2015. Our page on the GSoC site is at https://www.google-melange.com/gsoc/org2/google/gsoc2015/xmpp, and for more information on GSoC in general please see the Google site at https://www.google-melange.com/gsoc/homepage/google/gsoc2015. Student applications open on March 16th but that’s no reason to delay – come and chat with us about our possible projects with the contact venues listed on http://wiki.xmpp.org/web/Summer_of_Code_2015.
We’ve got the ideas, we’ve got the mentors, all we need are a few students to turn this into a great summer for XMPP.
Mickaël Rémond explains how the BBC have been using large scale push notification service Boxcar to distribute radio content, breaking news and sport football alerts on a huge scale.
Thanks to BBC News and Sport teams for providing many of the slides and other material.
Imagine you are starting a new company: you have a team in-house and around others scattered around the world.
I set up the tools for another company 6 years ago. And was doing it again recently for Buddycloud. And how times have changed.
In light of recent spying events, code developed in a transparent manner (usually open source) is increasingly important. Being free both in dollar terms and in time spent talking to a sales team is also a huge win. But setting up and managing an open source office stack can quickly become a time-sink.
Here’s a quick retrospective to how we used to (about 6 years ago) set up team collaboration. And how we’ve done it today at Buddycloud HQ.Source Code and Issue Tracking
Details are sketchy, but I remember the pain level was high. “Back in the day” one rolled with subversion <shudder if you will>, fronted by Apache and some kind of LDAP authentication. That got you source control.
For bonus points and to view your code, you’d install WebSVN. Oh, dark days! Of course, you’d want to track bugs: Trac was the go-to tool for this. And came with a whole new set of dependencies. These were all cutting edge back then.
Let’s be clear - we weren’t going near SVN for source code wrangling. All of the Buddycloud repositories are based on GitHub. It’s hard to remember the pre-GitHub existence. As one of the best platforms to share code, GitHub offers us the chance to share all of our projects online, forming a straightforward flow to collaborate together in solving issues, commenting proposals and improving the code of our projects. And there’s no need to configure apache virtual hosts or buy SSL certificates for svn.example.com.
Currently, we have nearly 40 repositories. And almost zero admin overhead.Team Organisation
Then: Hire a project manager
Just a few years ago one would hire full-time cat-herders^WW project managers to look after a product team. Their task was to help the team answer “what should I do next?”, “what’s the big picture?”, “what are my colleague working on?”
To answer these questions would take lots of meetings. Some of the worldwide team would be waking up early to jump on team calls. And some would be staying up late to synchronise plans. Add in meetings digging into deep-hack-mode time and you quickly have a non-developer friendly environment.
Trello tasks are added to different topic boards, you tag your work colleagues to them, set up due dates so you get reminded when you have to get your tasks finished and get notifications according to your interests, amongst many other features.
There’s 101 organisation tools out there: We use Trello because of its simple, but effective approach as an agile task tracking/planning tool [and it’s free].
I also highly recommend using Trello on your phone to get into a GTD-type workflow and free up your mind: quickly capture thoughts and tasks for when you are back at your desk.Email, Calendaring and Documents
There was a day when setting up an office involved: Order server from Dell, Install Linux, Setup Postfix, hope you weren’t on a DNSBL, configure something else in /etc that you kinda understood but could never be totally sure about, tweak, configure some more.
And then you’d wonder when there was going to be a good calendering solution released as open source. And be sorely reminded that the solution was called Exchange. Then you’d hope you could get by without calendaring.
We like open source: the Buddycloud stack is all released as open source. But we’re also keen to spend our time on adding value to Buddycloud. Not tweaking spam-rules. Or looking at Exchange CAL costs. So we switched over to Google Apps: Gmail for email. Calendar for planning our meetings and organizing our schedules. Drive for storing and sharing files amongst the team. Hangouts to communicate with far away team members or developers of our community.
We’d rather be using open source. But we’d rather-more be spending our time on shipping Buddycloud code.
(BTW: We started having a Hangout Buddycloud’s Developer Call every Tuesday at 2:30pm GMT+1. This is aimed at bringing other Buddycloud developers and integrators together to share and get help from the dev-team and each other.)Mailing Lists
There are two uses for mailing lists:
Over the years, mailman was the way to power mailing lists. It’s good software. But installing Mailman involved debugging messages like “Premature end of script headers” or “Mailman CGI error!!!” And things always felt fragile. I’d tip-toe around our email stack with the through “perhaps I’ll hold off upgrading Postfix incase Mailman stops working”.
I’d have paid for a branded-hosted solution. It would have been nice to have someone else looking after this for us.
To solve the discussion list problem - we used Google Groups. Our asynchronous communication means we can work without interruption. Developers can also sign-up on a modern web page. And others can just chip in their 2c through the website without needing to join a mailing list. Yes, I feel like a sell-out to the pure open source solution. Yes, I enjoy my free time. As I age I value the latter more.
And for announcements-only lists, MailChimp helps us manage lists of users, Buddycloud-integrators and fans. And shoots off emails to them with updates. List is here if you are interested in a more read-only relationship.Social Media
Then: We’d go down to the pub or beer garden and tell our friends what we were building. They’d tell their friends and the physical “social graph” would relay the message. Or we’d make a post on Slashdot.
Everyone has their own flavour of social network. Buffer spools up announcements and pushes them out to each network. Right now, one Buffer post = a post on Twitter, Facebook, LinkedIn and Google+. And it gives us metrics on reach that keep Mizar in Marketing happy.
A lot has changed in just 5 years: complexity has increased and we’re pushed towards solutions that wrap up the complexity in hosted offerings. Us developers and open source advocates like our principles. And tinkering with new software is a great procrastination technique.
But we also like hosted solutions that let get on with tasks further up the stack.
BTW, Buddycloud builds a hosted messaging stack. Build on open source. Released as open source. And you can install it yourself and tinker with settings. Or just use our hosted option and do something else with your free time.
What are you using for your “office stack”?
There’s some recent discussion about the sky falling for XMPP at Google. See this blog post by Dan York for example.
In reality, we don’t know the state of XMPP inside Google because they don’t share their use of XMPP with the XSF. We do know Android’s Google Cloud Messaging uses it. We know Hangouts Videochat uses it. We know Google Talk still (insecurely) federates with (some) XMPP services. But from an outside perspective, Google has made no major recent changes in terms of how they’re using XMPP from what we can observe.
So what happened?
The Google Talk app for Windows has been deprecated as of February 23, 2015 as explained by the product manager. Google announced a while ago they intended to do this, but it comes as little surprise given the client has not seen much development in this decade.
Instead of Google Talk, Hangouts is promoted. Hangouts does not interoperate with federated XMPP clients. Users appear as visible, but messages from federated contacts are lost, which is a very confusing user experience.
The XSF still believes in the principle of client choice, best explained by Google on their developer pages:
We believe users should have choice in which clients they use to connect to the Google Talk service and we want to encourage the developer community to create new and innovative applications that leverage our service. To enable this, Google Talk uses the standard XMPP protocol for authentication, presence, and messaging.
Note that you can still continue to use the Google Talk Service with a third party XMPP client and the Google Talk XMPP servers continue to federate with other domains.
This is called “service choice”. The principle is, again, best explained by Google:
Service choice is something you have with email and, for the most part, with your regular phone service today. This means that regardless of whom you choose as your email service provider (Gmail, Hotmail, Yahoo! Mail, your school or ISP, etc), you can email anyone who is using another service provider. The same applies to phone service. You can call someone even if they do not use the same phone company as you do. This allows you to choose your service provider based on other more important factors, such as features, quality of service, and price, while still being able to talk to anyone you want.
However, since the Google Talk Service does not support server-to-server encryption via TLS (something that was required by RFC 3920 in 2004), a number of servers (including jabber.org) refuse to establish a connection since May 2014.
We’d love to see Google embrace secure messaging for federated messaging. But aside from this long-standing issue, XMPP is alive and kicking at Google.
At the recent Summit 17, we were very happy to welcome Dominik Renzel and István Koren from the recently launched site xmppresearch.org. The declared mission of the project is to:
“collect and to present scientific research work based on XMPP”
The site, which is a collaboration between RWTH Aachen University and Technische Universität Dresden, contains articles on recent XMPP-related research, demos and a comprehensive bibliography. They’ve recently blogged about their experiences at Summit 17.
We’re looking at ways of more formally linking this excellent site to the XSF’s own online efforts. In the meantime I’m sure they would welcome you contacting them with any relevant XMPP research you are aware of so it can be included on their site.
It is well know that every developer in the world love writing docs :)
Well, I am kidding, but still our goal is to have the most comprehensive and beautiful documentation possible for a project. Given the extremely powerful and numerous ejabberd features and the extensive scope of XMPP, I guess you all understand the challenge.
But, we can as a community be up to the tasks. We have bootstrapped a huge documentation effort for ejabberd, but we hope it will also serve as a good reference to learn XMPP.
To be frank, the work we have started here would hardly fit into a full size book, but we will get there.
As to the goal of producing a beautiful documentation, this is already done and we hope you will all like what we achieve on the ejabberd documentation site design.
We already had very good documentation, but it was both included in massive, intimidating documentation or hard to find.
We have started adding documentation we had on various places on a single documentation site: docs.ejabberd.im. Once this is finished, we will keep on writing new content based on frequent questions we get on mailing list and forums. However, we plan to reorganise it and split it in smaller chunks to make it easier to ingest. I especially think about the extremely complete, but also extremely long, ejabberd Installation and Operation Guide.
The good news is that you can now fork the documentation site and join the effort. It is available on Github: processone/docs.ejabberd.im
Do not hesitate to submit PR to fix typo or improve the wording. There is no small contribution and that’s a great way to join the ejabberd community.