Agregador de noticias

Peter Saint-Andre: RFC 8141: Uniform Resource Names

Planet Jabber - 27 April, 2017 - 00:00
Long, long ago on an Internet far, far away, some forward-thinking technologists defined several different types of identifiers called Uniform Resource Locators or URLs (for locating things - say, an article published online) and Uniform Resource Names or URNs (for permanently naming things without necessarily locating them - say, identifying a book by its ISBN no matter where a physical or electronic copy might be located). Some years later, a grand unified theory of identifiers was formulated, leading to the creation of Uniform Resource Identifiers (URIs) including both URLs and URNs (and URCs, but who's ever heard of those?). Even though most URIs that we use today are URLs, URNs as specified in RFC 2141 have continued to be widely deployed, especially for bibliographic purposes and as XML namespace names. Because the communities that use URNs have felt the need to make some slight adjustments to the syntax and to align URNs with the formal definition of URIs, back in 2010 folks at the IETF decided to start work on a new document to obsolete RFC 2141. It took us 7 years (!), but here we are today with RFC 8141 to bring URNs into the modern age (almost exactly 20 years after the publication of RFC 2141 in 1997). Special thanks to John Klensin for co-editing this specification with me!...

Tigase Blog: Experiences with Tigase Messenger for iOS

Planet Jabber - 22 April, 2017 - 06:12

At heart I’m what people call a power user. When I started to use Tigase Messenger for iOS, I was a little reluctant to hand over status to the application, I typically like to have every conceivable feature at my fingertips – even if I don’t use them.

Erlang Solutions: MongooseIM 2.1.0beta1 what happens when you give your team freedom

Planet Jabber - 13 April, 2017 - 11:48
<p><a href="http://www2.erlang-solutions.com/l/23452/2017-04-12/4jzcbj">MongooseIM</a> is a highly technical platform for businesses to build messaging and social apps, or add messaging and social features to an existing app. The fullstack MongooseIM platform offers various components, both for the backend (Erlang, Elixir) and the frontend (iOS, Android, Web) for you to pick up and assemble like pieces of a puzzle. Today, the MongooseIM platform delivers a new beta version of the messaging server, as well as new push notification server.</p> <p>My name is Michał Piotrowski, and I&rsquo;m MongooseIM platform tech lead. With this blog post I&rsquo;d like to announce and describe our latest release. MongooseIM 2.1.0beta1 is one of the strongest releases I have ever worked on. It comes with new features on the XMPP level and it also contains much more internal, technical changes.</p> <p>For this release we created a <a href="http://mongooseim.readthedocs.io/en/2.1.0beta1/Roadmap">roadmap</a> and gave the team the freedom to implement it. The end result is not only implementation of most of the items from the roadmap but also many corresponding changes resulting in improved code quality or performance.</p> <h2>Push Notifications</h2> <h3>For mobile devices</h3> <p>These days most of instant messaging applications are mobile first or mobile only. To deliver great product for mobile devices you have to be able to send push notifications to offline users in one way or another. This was possible so far with the <a href="http://mongooseim.readthedocs.io/en/2.1.0beta1/modules/mod_http_notification/">mod_http_notification</a> module. The problem with this approach is that you need to create your own HTTP service talking to <code>APNS</code> or <code>FCM</code>.</p> <p>In this version we added support for push notifications as described in <a href="https://xmpp.org/extensions/xep-0357.html">XEP-0357: Push Notifications</a>. We also added a new service to our platform <a href="https://github.com/esl/MongoosePush">MongoosePush</a> which can be used to communicate with both APNS and FCM. Configuration of all the required components to enable push notifications is no laughing matter. That&rsquo;s why we create a detailed <a href="http://mongooseim.readthedocs.io/en/latest/user-guide/Push-notifications/">tutorial</a> on this topic.</p> <p>Thanks to this functionality you can enable push notifications in your application based on a standard way. There is no need to create ad-hoc, custom solutions.</p> <h3>For other services</h3> <p>In many cases you may want to get some of the events from MongooseIM in your other services. For example, to apply some business logic or implement a custom archive. Again, this was possible with MongooseIM so far by aforementioned mod_http_notification with the same limitations as described above.</p> <p>MongooseIM 2.1.0beta1 comes with a new and more flexible way to integrate with other services in the whole infrastructure. Thanks to <a href="http://mongooseim.readthedocs.io/en/2.1.0beta1/modules/mod_aws_sns/">mod_aws_sns</a> you can configure MongooseIM to push certain events to your Amazon SNS queues. The sky’s the limit in applying any business logic you may want on all the delivered events.</p> <h2>Full text search for MAM</h2> <p>Most modern instant messaging applications need full text search on the messages from archive. While not officially described in any XEP, it&rsquo;s possible to add custom queries to MAM requests for instant full text search. This is exactly what we did in MongooseIM 2.1.0beta1. With this version you can use custom field full-text-search in your MAM query to get all messages matching provided pattern. Complete example can be found in <a href="https://github.com/esl/MongooseIM/pull/1136">the PR</a> implementing this functionality. Be warned, this has its limitations:</p> <ul> <li>It works only with MySQL, PostgreSQL or Riak KV backends.</li> <li>MySQL and PostgreSQL implementation is not the most efficient as it&rsquo;s based on SQL&rsquo;s full text search.</li> </ul> <p>Please take a look at <a href="http://mongooseim.readthedocs.io/en/2.1.0beta1/modules/mod_mam/">mod_mam</a> documentation to see how to enable this feature.</p> <h2>Continuous load testing</h2> <p>In developing the MongooseIM platform we are always focused on the quality of our product. That&rsquo;s why we integrated MongooseIM with services like <a href="https://travis-ci.org/esl/MongooseIM">travis-ci</a>, <a href="https://coveralls.io/github/esl/MongooseIM">coveralls.io</a> and <a href="http://gadget.inakalabs.com">gadget-ci</a> a long time ago. Thanks to these improvements, every single change is properly tested. Code quality and test coverage are also monitored to ensure we deliver the best possible quality.</p> <p>For the past few months we&rsquo;ve been working on another service which helps us deliver better products. <a href="http://tide.erlang-solutions.com">Tide</a> is our own service integrated with MongooseIM build pipeline. Thanks to this service we are able to continuously load test our pull requests to see the performance impact of proposed changes.</p> <h2>XMPP pipelining</h2> <p>The usual way of connecting to a XMPP server is based on a request response pattern. The client sends a stanza, waits for the reply from the server and then sends another stanza. This is required when the client connects to a server for the first time. Many things about the server capabilities are not known to the client so it needs to wait for the response to proceed. When communicating with familiar server, where the clients know about all the features provided by it, almost all initial requests can be combined in one request.</p> <p>This improves connection or re-connection times significantly. Following diagrams shows re-connection time (with stream resumption) with and without pipelining.</p> <p><img src="https://s3.amazonaws.com/uploads.hipchat.com/15025/1282540/SJcJKBIyYrvSdSo/diagram.png" alt="Reconnection speed with and without pipelining"></p> <p>As you can see the reconnection time with pipelining takes <strong>at most</strong> less than <strong>50ms</strong> while without pipelining it&rsquo;s at least <strong>150ms</strong>.</p> <p>This improvement doesn&rsquo;t come for free though. These changes increase MongooseIM&rsquo;s memory consumption. Tests on our Tide platform before and after the change was merged shows that MongooseIM consumes around 200Mb more memory on a load test with 50K users.</p> <h2>Erlang distribution over TLS</h2> <p>Many of our customers were asking if it’s possible to encrypt the communications between Erlang nodes in the cluster. They need this for various reasons, and improved security is always an important factor when deciding whether to encrypt Erlang traffic or not.</p> <p>Our answer to this problem is yes, it&rsquo;s possible. Magnus Henoch already described how to do this for Erlang in general in his <a href="https://www.erlang-solutions.com/blog/erlang-distribution-over-tls.html">blog post</a>. Starting from there we extended MongooseIM to simplify such encrypted setup and add it to 2.1.0beta1. Detailed documentation on how to encrypt Erlang traffic for your MongooseIM cluster you can read in the <a href="http://mongooseim.readthedocs.io/en/2.1.0beta1/operation-and-maintenance/tls-distribution/">Distribution over TLS</a> guide.</p> <p>You can expect a dedicated blog post with load test results on this topic in the near future. <a href="http://www2.erlang-solutions.com/emailpreference">Sign up to the Erlang Solutions Newsletter</a> to be notified of this blog post when it’s published. </p> <h2>Changelog</h2> <p>Please feel free to read the detailed <a href="https://github.com/esl/MongooseIM/releases/tag/2.0.1">changelog</a>, where you can follow links and find the code changes.</p> <h2>Special thanks to our contributors!</h2> <p>Special thanks to our contributors: <a href="https://github.com/astro">@astro</a>, <a href="https://github.com/aszlig">@aszlig</a>!</p> <h2>Next?</h2> <h3>From beta1 to final release through beta2</h3> <p>This release is a beta which means we are still adding a lot of changes before final release. We work to ensure that our product is as high a quality as possible with every change - I strongly recommend giving this beta a try. This also means that you can influence the final 2.1.0 release by giving us your feedback.</p> <h3>Peer to peer or mediated binary streaming</h3> <p>We will deliver an ICE/STUN/TURN server, coded in Elixir, to allow peer to peer and one to one media streaming, like voice, video, screen sharing, and whiteboarding. The signalling part, named <a href="https://xmpp.org/about/technology-overview.html#jingle">Jingle</a>, is already available.</p> <h2>Test our work on MongooseIM 2.1.0beta1 and share your feedback</h2> <ul> <li>Star our repo: <a href="https://github.com/esl/MongooseIM">github.com/esl/MongooseIM</a></li> <li>Follow us on Twitter: <a href="https://twitter.com/MongooseIM/">twitter.com/MongooseIM</a></li> </ul>

Daniel Pocock: What is the risk of using proprietary software for people who prefer not to?

Planet Jabber - 12 April, 2017 - 06:43

Jonas Öberg has recently blogged about Using Proprietary Software for Freedom. He argues that it can be acceptable to use proprietary software to further free and open source software ambitions if that is indeed the purpose. Jonas' blog suggests that each time proprietary software is used, the relative risk and reward should be considered and there may be situations where the reward is big enough and the risk low enough that proprietary software can be used.

A question of leadership

Many of the free software users and developers I've spoken to express frustration about how difficult it is to communicate to their family and friends about the risks of proprietary software. A typical example is explaining to family members why you would never install Skype.

Imagine a doctor who gives a talk to school children about the dangers of smoking and is then spotted having a fag at the bus stop. After a month, if you ask the children what they remember about that doctor, is it more likely to be what he said or what he did?

When contemplating Jonas' words, it is important to consider this leadership factor as a significant risk every time proprietary software or services are used. Getting busted with just one piece of proprietary software undermines your own credibility and posture now and well into the future.

Research has shown that when communicating with people, what they see and how you communicate is ninety three percent of the impression you make. What you actually say to them is only seven percent. When giving a talk at a conference or a demo to a client, or communicating with family members in our everyday lives, using a proprietary application or a product or service that is obviously proprietary like an iPhone or Facebook will have far more impact than the words you say.

It is not only a question of what you are seen doing in public: somebody who lives happily and comfortably without using proprietary software sounds a lot more credible than somebody who tries to explain freedom without living it.

The many faces of proprietary software

One of the first things to consider is that even for those developers who have a completely free operating system, there may well be some proprietary code lurking in their BIOS or other parts of their hardware. Their mobile phone, their car, their oven and even their alarm clock are all likely to contain some proprietary code too. The risks associated with these technologies may well be quite minimal, at least until that alarm clock becomes part of the Internet of Things and can be hacked by the bored teenager next door. Accessing most web sites these days inevitably involves some interaction with proprietary software, even if it is not running on your own computer.

There is no need to give up

Some people may consider this state of affairs and simply give up, using whatever appears to be the easiest solution for each problem at hand without thinking too much about whether it is proprietary or not.

I don't think Jonas' blog intended to sanction this level of complacency. Every time you come across a piece of software, it is worth considering whether a free alternative exists and whether the software is really needed at all.

An orderly migration to free software

In our professional context, most software developers come across proprietary software every day in the networks operated by our employers and their clients. Sometimes we have the opportunity to influence the future of these systems. There are many cases where telling the client to go cold-turkey on their proprietary software would simply lead to the client choosing to get advice from somebody else. The free software engineer who looks at the situation strategically may find that it is possible to continue using the proprietary software as part of a staged migration, gradually helping the user to reduce their exposure over a period of months or even a few years. This may be one of the scenarios where Jonas is sanctioning the use of proprietary software.

On a technical level, it may be possible to show the client that we are concerned about the dangers but that we also want to ensure the continuity of their business. We may propose a solution that involves sandboxing the proprietary software in a virtual machine or a DMZ to prevent it from compromising other systems or "calling home" to the vendor.

As well as technical concerns about a sudden migration, promoters of free software frequently encounter political issues as well. For example, the IT manager in a company may be five years from retirement and is not concerned about his employer's long term ability to extricate itself from a web of Microsoft licenses after he or she has the freedom to go fishing every day. The free software professional may need to invest significant time winning the trust of senior management before he is able to work around a belligerant IT manager like this.

No deal is better than a bad deal

People in the UK have probably encountered the expression "No deal is better than a bad deal" many times already in the last few weeks. Please excuse me for borrowing it. If there is no free software alternative to a particular piece of proprietary software, maybe it is better to simply do without it. Facebook is a great example of this principle: life without social media is great and rather than trying to find or create a free alternative, why not just do something in the real world, like riding motorcycles, reading books or getting a cat or dog?

Burning bridges behind you

For those who are keen to be the visionaries and leaders in a world where free software is the dominant paradigm, would you really feel satisfied if you got there on the back of proprietary solutions? Or are you concerned that taking such shortcuts is only going to put that vision further out of reach?

Each time you solve a problem with free software, whether it is small or large, in your personal life or in your business, the process you went through strengthens you to solve bigger problems the same way. Each time you solve a problem using a proprietary solution, not only do you miss out on that process of discovery but you also risk conditioning yourself to be dependent in future.

For those who hope to build a successful startup company or be part of one, how would you feel if you reach your goal and then the rug is pulled out underneath you when a proprietary software vendor or cloud service you depend on changes the rules?

Personally, in my own life, I prefer to avoid and weed out proprietary solutions wherever I can and force myself to either make free solutions work or do without them. Using proprietary software and services is living your life like a rat in a maze, where the oligarchs in Silicon Valley can move the walls around as they see fit.

ProcessOne: ejabberd 17.04

Planet Jabber - 11 April, 2017 - 15:42

Less than a month after previous release, ejabberd 17.04 is out with bug-fixes and new features: Redis and SQL backends can now be used to store some RAM tables, the same way Mnesia is doing.

This release fixes few regressions from previous refactor. If you have troubles using PEP or using external modules with ejabberd 17.03, upgrade to 17.04 should fix everything.

Refactor efforts are still in progress. If you’re a developer, consider ‘jlib’ module as obsolete and do call common helpers (like type convertors) from the new ‘misc’ module instead.

Improvements Admin
  • Add more examples on config template
  • Generate ejabberd lib dir when not available in code server
  • Set default prefix to /usr/local
  • Start supervisors after ext_mod
  • Don’t log warning on successful ping reply
  • New muc_register_nick command
Core
  • Deprecate jlib.erl in favor of misc.erl
  • Add support for file-based queues
  • ejabberd_sm: Fix routing of headline and groupchat messages
  • Fix c2s connection close on demand
  • Improve overloaded S2S queue processing
Databases
  • Improve Redis related code
  • Add Redis pool support
  • Improve logging of Redis errors
  • Add Redis and SQL as mod_proxy65 RAM backends
  • Add Redis and SQL as mod_carboncopy RAM backends
  • Add Redis and SQL as mod_bosh RAM backends
  • Add Redis and SQL as router RAM backends
  • Add SQL as mod_muc RAM backend
  • Remove obsolete Pubsub mnesia migration calls
Miscellany
  • ejabberd_http: Expand @VERSION@ in custom headers
  • ejabberd_http: Add “custom_headers” option
  • mod_client_state: Queue stanzas of each full JID
  • mod_http_upload: Don’t add “Server” header line
  • Pubsub: Refactor pubsub’s get_last_items
  • Pubsub: Fix PEP issues
Feedback

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.

Erlang Solutions: How Would the World Embrace Video Collaboration if it Couldn’t Scale?

Planet Jabber - 3 April, 2017 - 17:02
<h3>“How would the world embrace video collaboration if it couldn’t scale?”</h3> <p>This is a big question that Vidyo spotted early on, way back in 2005, as it set out to pioneer the next generation of video conferencing. </p> <p>Video collaboration at that time was primarily used for communicating between one traditional conference room to another. Since then, the world has changed. Today, in a time when “the office” can increasingly mean “pretty much anywhere” for millions of workers, (and consumer-facing apps are turning to video to service millions of customers), building a scalable video platform presents a new set of requirements. </p> <p>We are happy to share what we’ve learned over the years with developers who are interested in the next wave of video communications. At 1 PM EST on 3/29, <a href="http://www2.erlang-solutions.com/l/23452/2017-03-27/4jbrbg">join us</a> for our <strong><a href="http://www2.erlang-solutions.com/l/23452/2017-03-27/4jbrbg">“Building a Global Video Chat Platform for Developers”</a></strong> webinar, as we discuss the challenges faced and solved when building a developer platform that delivers real-time, mobile, multiparty video. </p> <p><strong>UPDATE: The webinar was recorded - <a href="http://www2.erlang-solutions.com/l/23452/2017-04-03/4jm2f8">watch it now</a>.</strong></p> <h1>Today’s video collaboration landscape</h1> <p>Today, clear and reliable video collaboration has lept out of the conference room and into our pockets, letting us hop on a video call from our smartphone or tablet while on the train, in the airport or on the road - with more or less the same audio/visual quality as a dedicated room system that enjoys a perfect ethernet connection and high bandwidth. </p> <p>When hundreds of people can reliably connect face-to-face at the same time, from wherever they happen to be, this method of communicating is proving to be transformative for critical fields like healthcare, banking, government and education. This is especially true as we work to make nuisances like dropped calls, lag, grainy or blurry visuals and frozen screens a thing of the past - and stunning levels of clarity and consistency become more of the norm, from basically anywhere. </p> <h1>Behind the scenes</h1> <p>Vidyo has diligently developed patented <a href="https://vidyo.io/platform/sfu-video-router/?utm_source=erlang&amp;utm_campaign=erlang&amp;utm_medium=webinar">adaptive video layering</a> and routing technologies that have ultimately given us a reputation as the go-to enterprise-grade video service, especially among industries with tight regulations and high security demands. </p> <p>For years, global enterprises have video-enabled their applications using our APIs and SDK. Now, however, the video conferencing market is shifting to embedded video - with the vision that developers should be able to easily video-enable any application on virtually any device - effectively “video-enabling the world”. When we decided to make the shift to embedded video and roll out our video API platform, <strong><a href="http://www.vidyo.io/?utm_source=erlang&amp;utm_campaign=erlang&amp;utm_medium=webinar">Vidyo.io</a></strong>, we knew that our customers would continue to demand Vidyo’s specific brand of mobile, multiparty video that is highly scalable, without sacrificing its quality. </p> <h1>Spoiler: it’s not all plain sailing</h1> <p>One of the challenges today of offering high-quality video collaboration at scale, is signaling. Initially, we built our own signaling protocol. We had a very scalable platform that was ideal for our enterprise customers, which could easily scale to tens of thousands of users. </p> <p>But, with Vidyo.io, we were building a global video API platform to be used to video-enable any concept or idea that application developers could think of, whether for enterprise business or consumer-facing applications. We chose MongooseIM because we needed signaling that could scale to millions of users. </p> <h1>Why MongooseIM was the solution for us</h1> <p>We found MongooseIM to be simple, flexible and reliable, and designed for this type of global Internet scale. XMPP is the battle-hardened standard, with the interoperability and classical benefits (like chat, historical chat, etc.) that we, as a uniquely enterprise-grade service, needed for an architecture that could get to 99.999% uptime.</p> <p>This is how video collaboration has lept out of the conference room and into the pockets of millions of people around the world. </p> <p>As we brought <strong><a href="http://vidyo.io/?utm_source=erlang&amp;utm_campaign=erlang&amp;utm_medium=webinar">Vidyo.io</a></strong>, to market, our priorities included geo-scalable distribution, easily working through firewalls and accounting for compiled code along with native code and browser access (as WebRTC is becoming increasingly important to the video space). At the time, we evaluated all XMPP platforms. We found that Erlang was the best solution for us, and it has gone on to help us significantly on our mission to offer embedded video to the world that “just works.”</p> <h1>Ask me anything</h1> <p>I’m proud to say that today, Vidyo.io has been featured on DevOps.com, ProgrammableWeb, App Developer Magazine, Software Development Times and elsewhere. Video is now becoming ingrained in everything people do. </p> <p>I’ll be speaking more in depth on the ups and downs of building a real-time, multiparty video platform with Erlang Solutions. <strong><a href="http://www2.erlang-solutions.com/l/23452/2017-03-27/4jbrbg">Register for the webinar</a></strong> if you are interested in learning more about my experience, the technology, and to take part in the Q&amp;A panel afterwards. You can ask me anything!</p> <p><strong>UPDATE: The webinar was recorded - <a href="http://www2.erlang-solutions.com/l/23452/2017-04-03/4jm2f8">watch it now</a>.</strong></p> <p>Learn more about <strong><a href="http://www2.erlang-solutions.com/l/23452/2017-03-27/4jbrdl">MongooseIM</a></strong>, Erlang Solutions’ high volume messaging solution. </p>

Alexander Gnauck: Introducing MatriX vNext

Planet Jabber - 2 April, 2017 - 18:14

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 = "server.com", }; 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");

Releases are available as a Nuget packages here: https://www.nuget.org/packages/Matrix.vNext

Peter Saint-Andre: Conceptism

Planet Jabber - 2 April, 2017 - 00:00
While dipping back into Baltasar Gracián's Art of Worldly Wisdom recently, I got curious about the author, who it turns out was both a practitioner and a theoretician of a 17th-century Iberian literary style called conceptism. My interest was further piqued when I learned that conceptist writers attempted to express intricate conceptual meanings in a very concise form, and that both Schopenhauer and Nietzsche were great admirers of Gracián (in Nietzsche's case perhaps reflected in his aphoristic style). I'm reminded also of Yevgeny Zamyatin's essay Theme and Plot, in which he espoused a concentrated brevity that he called "the art of writing with ninety-proof ink" (Zamyatin, in turn, was a great admirer of Nietzsche). These stylistic currents strike a deep chord with me, given my project of writing six extremely compressed books on eudaimonia. Speaking of which, now that I'm almost done with the book about Thoreau I'm making fast progress on a cycle of philosophical poems about Nietzsche....

Swift Blog: Swift is Changing

Planet Jabber - 1 April, 2017 - 00:00

Due to potential confusion between the Swift XMPP Client and Apple’s Swift programming language, we’re adopting a new name for Swift. Read on for more information and a link to our new website!

It’s has now been over 2 years since the Swift XMPP client became part of Isode’s product set and during that time we’ve seen significant changes to the product and the market within which it operates.

One of the biggest non-technical changes was Apple’s decision (in 2014) to name it’s new programming language “Swift” and its simultaneous decision to adopt an icon for this language with a great many similarities to the one used by our XMPP Client.

From a marketing perspective the possible confusion between our XMPP Client and Apple’s programming language is clearly a cause for concern. We’ve been pondering what moves we should make to protect Swift’s identity as an XMPP client for some time.

I am pleased to announce therefore that we’ll be adopting a new name and new look for the Swift XMPP client which, from today, will be known as Jolly Brisk!™ a name we’ve chosen to reflect the speed of the client and its connection to Isode Ltd, a British company.

We’re still in the early days of establishing a new identity for Jolly Brisk! and we need your help.

We’ve started on the new website which shows off our new corporate identity and some screenshots of our client. We’d appreciate your feedback on this new and radical change.

We expect to fully adopt the new identity with Swift 4.0, which will be launched as Jolly Brisk!™ 1.0.

Christian Schudt: Future<IQ> - About the New Asynchronous API in Babbler

Planet Jabber - 29 March, 2017 - 16:14
This is a topic which is long overdue, but still pretty interesting: The new asynchronous, non-blocking API for IQ requests in Babbler (since version 0.7).

The Problem Until the previous release, all IQ-based API was synchronous and did block until the IQ response has been received.

Lets have a look at what that means and how Last Activity (XEP-0012) of an entity was retrieved to illustrate the problem:

LastActivityManager lastActivityManager = xmppSession.getManager(LastActivityManager.class);
LastActivity lastActivity = lastActivityManager.getLastActivity(Jid.of("juliet@example.com/balcony"));

The method getLastActivity() sends out the IQ request and then waited (blocked) a few milliseconds or even seconds for the response or until a timeout happened.

Having blocking operations is of course resource consuming because you have to dedicate a thread for it, which however is blocking most of the time while waiting on the operation to finish. It's the same issue as with blocking IO and the reason why NIO exists.

Doing multiple blocking IQ queries in parallel means, you have to create a thread for each query.

If you want to do such an IQ query from a JavaFX application you also had to write a lot of boilerplate code like this:

Task<LastActivity> task = new Task<LastActivity>() {
@Override
protected LastActivity call() throws Exception {
LastActivityManager lastActivityManager = xmppSession.getManager(LastActivityManager.class);
return lastActivityManager.getLastActivity(Jid.of("juliet@example.com/balcony"));
}
};
task.stateProperty().addListener((observableValue, state, state1) -> {
switch (state1) {
case SUCCEEDED:
updateUI(task.getValue());
break;
case FAILED:
task.getException().printStacktrace();
break;
default:
break;
}
});
new Thread(task).start();

You don't want to block the UI thread and therefore need to run blocking operations in a background task.

Furthermore the blocking API in Babbler was not interruptible because it didn't throw InterruptedException. Of course we could have solved the interruptible issue easily, but you still would have the drawbacks of a blocking API.

Futures to the Rescue Instead of waiting for the response and then returning the result, all IQ-based APIs now return a java.util.concurrent.Future:

Future<LastActivity> lastActivityFuture = lastActivityManager.getLastActivity(Jid.of("juliet@example.com/balcony"));

The method call is now asynchronous, it no longer blocks and passes control immediately back to the caller!

As with every Future, you can get the result with its get() method:

LastActivity lastActivity = lastActivityManager.getLastActivity(jid).get();

or with a timeout:

LastActivity lastActivity = lastActivityManager.getLastActivity(jid).get(5, TimeUnit.SECONDS);

You might ask, what we've gained now, because the get() method is blocking again and usually you need the IQ result anyway.

Well, that's true. One part of the answer is that we gain interruptibility and the other part is that the returned result is not only a Future, but also a java.util.concurrent.CompletionStage (Java 8's new toy).

CompletionStage<LastActivity> lastActivityFuture = lastActivityManager.getLastActivity(Jid.of("juliet@example.com/balcony"));

It basically allows you to react asynchronously when the result is present, i.e. when the Future is done. Some frameworks like Guava already have such a concept of a "Listenable Future", now it's part of the JDK.

Taking our JavaFX example from above, updating the UI with the result as in the above example can now become a simple one-liner:

lastActivityManager.getLastActivity(jid).thenAcceptAsync(this::updateUI, Platform::runLater);

It sends the IQ request and later when the response is received it asynchronously executes the updateUI method in the JavaFX thread.

No more blocking, no more extra threads, everything is asynchronous!

Even better:

CompletionStages can be chained together. There are use cases, which require multiple IQ queries like Service Discovery or File Transfer. They can then be composed together into one:

CompletionStage<Boolean> isSupported = xmppClient.isSupported(LastActivity.NAMESPACE, jid);
CompletionStage<LastActivity> lastActivityFuture = isSupported.thenCompose(result -> {
if (result) {
return lastActivityManager.getLastActivity(jid);
} else {
throw new RuntimeException("XEP-0012 not supported by" + jid);
}
});

This code first checks if Last Activity is supported (using Service Discovery) and only if it is, queries the entity.

File Transfer is pretty complicated, with a lot of queries going on. This pseudo-code example illustrates the power of composing asynchronous calls (IBB fallback not shown here):

CompletionStage<ByteStreamSession> future =
initiateStream() // Initiate a file transfer stream with somebody
.thenCompose(streamInitiation -> discoverStreamHosts() // When accepted, discover SOCKS5 stream hosts
.thenCompose(streamHosts -> letReceiverChoseOne() // Query the receiver and let him choose a stream host
.thenCompose(streamHostUsed -> activateStreamHost() // When receiver responds with the chosen stream host, activate it
.thenApply(result -> createByteStreamSession())))); // After activation, create a stream session.

For convenience there's also a class AsyncResult, which implements both interfaces.

I think asynchronous programming is the future :-) and this is a first, but huge step in the right direction.

Peter Saint-Andre: Unethical Philosophers

Planet Jabber - 26 March, 2017 - 00:00
Reports and allegations continue to surface regarding widespread sexual misconduct by male philosophy professors, including "stars" such as John Searle and Thomas Pogge (as well as several professors here in Colorado). The sad irony and arrogant hypocrisy of professors of philosophy engaging in such despicable and deeply unethical behavior cannot be passed by in silence. We witness here in a particularly painful form the truth of Thoreau's observation that "There are nowadays professors of philosophy, but not philosophers." According to Thoreau and the ancients, "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" - which these piddling professors clearly fail to do....

ProcessOne: ejabberd 17.03

Planet Jabber - 24 March, 2017 - 15:03

New modular code, flexible core backend, dynamic configuration reload, spam protection and routing API changes.
These are the most interesting improvements coming in 17.03.

As usual, we also included several other improvements and many bug-fixes. In summary, almost 3K new lines of code and other 10K changed lines.

Many thanks to all of you which tested and sent feedback over the beta testing period!

Improvements Modular code

New modular code allows to develop modules for a wide scope of functionalities without patching the core code such as C2S, S2S and router.

Routing API

Now ‘From’ and ‘To’ arguments must be omitted in functions and structures related to routing.
The commit deprecates the following functions:

  • ejabberd_router:route/3 in favor of ejabberd_router:route/1
  • ejabberd_router:route_error/4 in favor of ejabberd_router:route_error/2
  • ejabberd_local:route_iq/4 in favor of ejabberd_local:route_iq/2
  • ejabberd_local:route_iq/5 in favor of ejabberd_local:route_iq/3

The format of {route, From, To, Packet} is changed in favor of {route, Packet}.
API changes will be better described with 17.03 release when new API documentation will be completed.

Flexible core backend

Ejabberd used to store all in-memory shared data such as ACLs, proxy65, sessions, routes, clustering, etc in internal Mnesia database and this used to be hardcoded. With new API it’s now possible to store such data in any database.
However, currently only Mnesia backend is supported, but we’re working on implementing other backends (redis, sql) in future releases.
For the record, it’s already possible to store client sessions in Redis and/or SQL servers, the API was just extended to make it possible to implement such a backend for any in-memory shared data.

New features Dynamic configuration reload

Using ‘reload_config’ ejabberd’s command it is now possible to reload modules, database connections, listeners, ACLs and global options without restarting ejabberd.
Thanks to this improvement, it’s now possible to add and remove virtual hosts via configuration reload.

Spam protection

If you want to get ride of XMPP SPAM, best option is now to use our new feature implemented by mod_block_strangers. This module just allow to block packets from non-subscribers, this means you won’t receive messages from users not registered in your roster.

S2S dialback

S2S dialback is now an optional module. If not present in the configuration, only TLS mechanism can be used to establish S2S connections.

Upgrade

While upgrading an existing system, you need to care about few required changes. In order to enable S2S dialback, stream management (XEP-0178), legacy client auth or the new anti-spam feature, the following modules should be added to ejabberd’s configuration:

  • mod_s2s_dialback
  • mod_stream_mgmt
  • mod_legacy_auth
  • mod_block_strangers

If you have issues using PubSub with Postgres backend, please check the full schema update from sources.
While in runtime, you can run the following bare minimal changes to fix PubSub

ALTER TABLE pubsub_state ALTER COLUMN subscriptions SET DEFAULT '';
UPDATE pubsub_state SET subscriptions='' WHERE subscriptions=null;

Changes

Here are the most relevant changes

Developer
  • tools/hook_deps.sh: checks hook dependencies
  • tools/find-outdated-deps.pl: checks which dependences need update
  • Mark as deprecated add/get_local/global_option config functions
  • Change routing API
Core
  • Fix some corner cases while re-reading RFC6120
  • Attach IP metadata to every stanza received from stream
  • Apply SASLprep before storing/converting passwords
  • Send compressed in correct order
  • Reset XML stream before sending SASL success
  • Speedup features list when a lot of virtual hosts configured
  • Fix s2s_dns_timeout issues
  • Better handling of IPv6 domains
  • Rename mod_sm -> mod_stream_mgmt
  • Don’t count resent stanzas
  • Improve startup procedure, and log startup time
  • Add more processes to supervision
  • sm_sql: Avoid PID collisions
Admin
  • Add ‘supervisor’ listening option
  • Accept “add_commands: admin” in commands section
  • Make sure that api_permissions always have “console commands” section
  • Change name of pam dep from p1_pam to epam
  • Improve compilation with rebar3
  • Add TLS support for external components
  • Specify “ExecReload” command in systemd unit
  • Don’t attempt to resolve _jabber._tcp SRV record
  • Improve error reporting for forbidden servers
  • mod_block_strangers: New module to block packets from non-subscribers
  • mod_register: Report password change in the log
  • Remove relict mod_service_log
  • Remove unused mod_ip_blacklist
  • Remove ejabberd_frontend_socket
  • WebAdmin: improve formatting when showing erlang terms
  • Import from Prosody: Fix import of SCRAM passwords, offline
API & Commands
  • get_last now always returns tuple with UTC XEP-0082 and status
  • Protect users from delete_old_users command using a fixed access rule
  • Separate list of strings with \n for srg_get_info in mod_http_api
  • Support non-JID lines in command create_rooms_file
  • stop_all_connections now stops all s2s connections via supervisor calls
  • Support scrammed passwords in ejabberdctl import_prosody
Configuration
  • Provide example mod_http_api configuration with couple commands
  • Clarify new modules usage in the example config
  • Don’t crash on malformed IP addresses
  • Fix parsing of acl/access rules inside oauth sections of api_permissions
Config reload improvements
  • Start/stop auth modules when host is added/deleted
  • Improve modules start/stop procedures
  • Check result of gen_mod:start/2 callback
  • Improve reload_config admin command
  • Invalidate access permissions on configuration reload
  • Start/stop virtual hosts when reloading configuration file
  • Reload modules when reloading configuration file
  • Restart listeners on configuration reload
  • Make sure all hooks are called with proper host
Databases
  • Add missing NOT NULL restrictions in schemas
  • Move archive tables into lite.sql for better comparison with other schemas
  • Implement database backend interface for mod_proxy65
  • Implement database backend interface for MUC, BOSH and auth_anonyous
  • Implement database backend interface for ejabberd_router
  • Propagate the TRANSACTION_TIMEOUT to pgsql driver
New XMPP stream behavior
  • Reflect cyrsasl API changes in remaining code
  • Improve return values in cyrsasl API
  • More refactoring on session management
  • Add xmpp_stream_out behavior and rewrite s2s/SM code
  • Rewrite ejabberd_service to use new XMPP stream API
MAM & offline storage
  • Make a message is not bounced if it’s archived
  • Archive message before delivering it to offline storage
  • Include stanza ID with archived offline messages
  • Add stanza-id to every archived message
PubSub
  • Avoid orphan_item leak on affiliation/subscription removal
  • Fix pubsub SQL schemas, add NOT NULL restrictions
  • Fix last item cache for multiple hosts
Server to server
  • Several improvements of S2S errors logging
  • Resolve all addresses from SRV lookup
  • Add s2s work-around for gmail.com
Feedback

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.

The XMPP Standards Foundation: First Paris XMPP meetup

Planet Jabber - 23 March, 2017 - 22:59

After Berlin, Stockholm, and London, here is Paris. The trend of new XMPP meetups in major cities in Europe is confirmed.

The Paris meetup is simply organised by the JabberFr community, as this will be mostly oriented discussions on modern XMPP/Jabber.

Details are available on JabberFr, LinuxFr.org, and agendadulibre.

The XMPP Standards Foundation: New XMPP Software Listing Rules

Planet Jabber - 23 March, 2017 - 12:00

The XSF provides a public list of XMPP implementations on its website. For this list to be useful, it should contain up-to-date information about up-to-date software. To achieve this, the XSF Board has decided that all implementations have to reapply once per year, to ensure that they are still actively maintained and that the listed info is accurate. This is a purely formal process, though we encourage implementors to follow the current compliance suites.

If you have an entry in one of the lists, please create a pull request as desribed in the README before the 1st of May 2017. There is an example commit that can be used as a reference. Software that is not updated until that date will be automatically removed from the listing. Alternatively, you can ask in the jdev MUC for a manual update of your listing.

Please also ensure that you repeat this step in the following years.

Swift Blog: Swift and Google Summer of Code 2017

Planet Jabber - 21 March, 2017 - 00:00

It’s Google Summer of Code time again! Swift is participating in GSOC2017 under the banner of the XMPP Standards Foundation and we’ve posted a range of project ideas covering Swift and Swiften on the XSF wiki. Read on for more information.

As reported in a post on the XMPP Standards Foundation blog, the XSF has once again been accepted as one of the Open Source organizations participating in Google Summer of Code.

We’ve listed some "potential ideas for Swift and Swiften GSOC projects on the XMPP Wiki so, if you’re interested in participating as a GSOC student this year, please take a look.

If any of these projects are of interest, or if you have ideas of your own you’d like to propose, then please join the swift@rooms.swift.im chat room to discuss GSOC and ask questions. We’ve had some great experiences with previous GSOC projects and we’re very much looking forward to working with students this summer.

Ignite Realtime Blog: Smack 4.2.0 released

Planet Jabber - 20 March, 2017 - 15:48

Around two years ago, on 2015-03-29 to be precise, Smack 4.1.0 was tagged and released. A few days ago I've tagged and released Smack 4.2.0 to Maven Central. The 4.2.0 release marks a milestone for Smack, but before I got into the exciting new features, I'd like to thank the various contributors:

 

$ git shortlog -sn 4.1.0..4.2.0

   459  Florian Schmaus

     8  Fernando Ramirez

     3  Anno van Vliet

     3  Tibo-lg

     3  damencho

     3  ramabit

     2  Andrey Starodubtsev

     2  Vyacheslav Blinov

     2  stawny

     1  Andrey Prokopenko

     1  Craig

     1  Daniel Hintze

     1  Dave Cridland

     1  David Black

     1  Dmitry Deshevoy

     1  Grigory Fedorov

     1  Hugues Bruant

     1  Ishan Khanna

     1  TheHaf

     1  Tomas Nosek

     1  Tomáš Havlas

     1  UltimateZero

     1  Vaibhav

     1  meisterfuu

     1  rohanag12

     1  vfite

 

I can not remember when Smack had so many contributors. Thanks everyone and keep the contributions coming.

 

The notable changes to Smack 4.2 include support for DNSSEC (thanks to a previous MiniDNS GSOC project), JIDs as first class citizens by using JXMPP's JID API, and tons of other improvements, new features and bug fixes. You can read more in the Smack 4.2 Readme and Upgrade Guide and the Smack's JIRA release notes.

 

Last but not least, thanks to Bilal Siddiq, Smack now has a logo.

 

Ever wanted to contribute to open source? Are you interested in XMPP/DNS/DNSSEC? Google gives students the chance to work on open source projects and get paid for it as part of Google's Summer of Code 2017. The XSF acts as umbrella organization for projects like Smack and MiniDNS [4]. Feel free to contact me in the gsoc@muc.xmpp.org if you are interested in participating or if you want to discuss your own Smack/MiniDNS related project ideas.

Christian Schudt: Babbler Version 0.7.4 released

Planet Jabber - 16 March, 2017 - 15:26
Version 0.7.4 of the Java XMPP library has been released to Maven Central!

It turned out there was a rare deadlock, when using Stream Management. It happened only rarely and was hard to spot, but when it did, it was of course a blocker.

Here's the full changelog:
  • Resolve rare deadlock when using Stream Management
  • Rework how WebSocket connections are closed
  • Don’t let a stream error close the stream immediately, but instead wait for the closing stream element and then close the connection.
  • Increase performance of IBB stream
  • Prevent rare, but possible NullPointerException after sending stanzas.
  • Fix error when using pages (XEP-0141) within data forms (XEP-0004)
  • Reset nick to null, if entering a chat room fails

Jérôme Poisson: Cagou(SàT): development progress of the desktop and Android XMPP frontend

Planet Jabber - 14 March, 2017 - 21:56

Salut à Vous !

It's been a little more that one year now that the crowdfunding campain has been successfuly completed, and that we have promised to develop a new Desktop/Android frontend for "Salut à Toi", our Multipurpose, multi frontend communication tool based on XMPP.

It's time for an overview of the state of the development. You'll find below a link to the first .apk (pre-alpha), FOR TESTING PURPOSE ONLY.

Cagou (SàT)

As we've already announced, the new Desktop/mobiles (Android only for now) frontend will be named "Cagou", a wind to the Kivy framework that we're using, and to this endemic bird of New Caledonia, which bark and can't fly.

Oh, and yes we know that "Cagou" has different meaning in different languages.

Development

This part is technical, you can go directly to the next one if you're not interested.

After a short time to get familiar with the Kivy ecosystem, the first step has been to integrate "Quick Frontend", which is a common base that we are using, as you guess, to quickly develop a frontend and factorise the code (cache handling, contact list – or "roster" in XMPP world –, widgets, etc.), then to integrate the "bridge" which is the name that we are using for the IPC and which handle the communication between the backend (which is the heart of SàT) and the frontends.

This phase went relatively well, and was followed by a thought on the architecture and user interface.

Once all of this was more or less usable, the Android port could began.

Things have been a big more complicated there. The Kivy community has created several tools to develop on this platform, including python-for-android (compilation and archive creation tool), and Buildozer (multi-platform tool to facilitate the use of the first one). Using these tools take some efforts, specially for a project already well advanced (it's far more easy if you start directly with Kivy and the Android port).

There a 2 "chains" for developing on Android: the old and the new one. After the first unsuccessful tries with the new one, it has been temporarly put aside for the old one, the time to build the foundations of the port.

Pure Python dependencies can be imported easily, but as soon as it get more complicated, you'll have to creates "recipes" to tell how to build something to python-for-android. Fortunately, most of those needed for SàT (Twisted in particular) were already available, and just needed to be updated.

After all this dependencies and building chain problems solved, and after the joy to see the first .apk (no working), 2 other big troubles showed up: D-Bus which is the main "bridge" is not usable on Android, and how to have the backend and the frontend running together?

Being my first Android development, I've had to read a lot or documentation (which luckily is not lacking), and after a first try with a bridge "embedded", allowing to have backend and frontend in the same process, it's finally a new "pb" bridge which solved the issue. "pb" stands for "Perspective Broker", the Twisted IPC. Android native IPC is an other option to be evaluated in the future.

To launch the backend, Kivy comes with modules to start it as an Android service. With it, the backend can stay in background and process messages and other activities when the frontend is not visible to the user (which means frozen until the user show it again on Android).

This section is already long, so I'll skip other problems (like the lack of HTML widget), and let's now talk about the UI.

UI

At the moment Cagou is usable on desktop (GNU/Linux, but other platforms will most certainly follow), and on Android.

The current release is a pre-alpha, the .apk is available below, only to have a rough idea of the software. It is really bugged, doesn't check yet server certificates, doesn't handle SRV record on Android, etc. This is linked for 2 reasons: showing the progress, and having feedbacks early enought to go in the right direction.

You can't create account from the application (this will come before the release), so if you have no account yet you can use Libervia(SàT), the demo instance of our web frontend, to create one.

main concepts

Cagou's UI take inspiration from the excelent Blender. The widget selection and splitting are the most obvious examples. The huge bars that you can see should disappear later in favor of a small button, which may follow Blender example again. The goal here is that a newcomer can switch widgets intuitively, and an advanced user can use this splitting feature.

The contacts list is not the central element in the interface, it can be displayed if wanted, but it's not needed to use Cagou.

The upper menu, which is for now always visible, will certainly be only available on Desktop. On Android the menu button or a floating touch one should replace it before the release.

If you have notifications, they should appear for a couple of second on the top, but you can read them later by touching the cagou head on the upper left.

If there is an event needing user action (for instance a website needs your authorisation with XMPP), an other cagou will appear on the right, and the dialog will only appear after touching it. The idea is to never have an unwanted popup stealing the focus when you are doing something else: popups are displayed only with explicit user action.

In Android case, it may be replaced by the native notification system in the future, but it's not decided yet because notifications history would not be available anymore.

To change the mode (widget), you just have to click on the upper left button in the current widget. Only 4 widgets are available so far: the selector which display all widgets available, the settings, the contact list, and the chat. Other are planed, notabily the blogging one.

Inside a widget (only for chat so far), you can swipe horizontaly to switch between active conversations.

For now it's not easy to use the first time (you have to do a very quick swipe), it needs some tuning.

As for other SàT parts, Cagou is thought since the beginning to work with plugins and being easy to extend. All the widgets and file transmitting system (see below) are plugins.

instant messaging (chat)

As we want a frontend usable on small screens, which is simple but without making sacrifice on features, we have to find a compromise between data displayed on the screen and the elements/buttons needed for actions. Too many elements will make the UI more complicated and take room, but not enough will make the actions more difficult to do.

The current design (which can evolve) has a header with an input bar and a button (in addition to widget selection button), the body with messages, and a bottom input bar with a button too.

To talk with one or more contact(s), type some letters belonging to its name (anywhere in the name). For now, only identifiers ("jid") and already opened talks are looked for, but later the search will include names, nicknames and bookmarks.

Cagou detect if you want to talk to a single person, or to a group chat room, and will act consequently.

The end 2 end encryption is there, but only with OTR (v2) for the moment. OX (modern OpenPGP) and OMEMO are planed, but it's not sure that they will be available for the next release (they may be there for the following one, 0.8). To use it, you just have to click on the lock, it will be closed if the chat is encrypted, and will have a question mark if your contact is not authenticated.

Let's go directly to the input bar. You'll see on the right a "+" button, click on it and you'll have a sending dialog.

This dialog has 2 buttons on the top, with which you can choose between uploading the file or sending it directly using peer 2 peer. A text under them explain in simple language where your file will go, and if encryption is done (for now all files are sent unencrypted).

This text message is important to let the user understand where the data are transiting, it's the kind of information we plan to put in several locations.

The buttons below are the various transmitting options. On desktop, you can only use a file browser (for now), but on Android you can also send a picture from your gallery, take a new photo or a video, or record a voice message.

He is a screenshot of voice recording:

around Cagou

In addition to the work on Cagou itself, other things have been done.

A now mandatory feature with the explosion of mobile devices, carbon copy has been implemented. Server archives is implemented for long fot blogging, but not yet for chat messages, it will be done before the stable release.

Small binary files handling ("BoB" for "Bits of Binary") is now available. Implentation has been motivated by its use on the friend project Movim.

Delivery receipts and HTTP authentification have been contributed by Chteufleur.

Since the 0.6.1 version, messages handling has been improved, making now possible to implement features like last message correction, planed for the release.

Lastly, component (for gateways) and static blogs have also been implemented, but we'll talk about this later.

help

SàT is a huge project with strong ethical values (check the social contract), and it need help! It can be as easy as coming to talk with us (our room is at sat@chat.jabberfr.org, also availble by clicking here).

If you can, financial aid would of course be useful, we have recently opened an account on the excellent Liberapay.

You can also join us in our association, all informations are available here

And of course contributions are useful, specially development but also translations, icons, CSS, etc. Most of the coding is done in Python, and working on SàT is working on a tool you may use everyday. You'll not find us on big centralised forges, but we are in the process of modernising our development tools (more to come on that).

Talk about our association and project around you is always useful.

I think the most important things have been said, I'll try to keep you up to date with shorted posts.

Oh, and the link with the pre-alpha version (once again: FOR TESTING PURPOSE ONLY): https://www.goffi.org/public/Cagou-0.1-debug.apk

Tigase Blog: tigase-server project structure change

Planet Jabber - 13 March, 2017 - 19:59

Previously, our main project, tigase-server has used a couple of maven modules (separate for the server sources, documentation and one responsible for building distribution packages). Unfortunately for equally as long, the file structure did not follow the standard maven structure.

Tigase Blog: XMPP Summit 21 Reflections

Planet Jabber - 8 March, 2017 - 00:56

The XMPP Standards foundation had its 21st Summit this past month in Brussels, Belgium just prior to a strong showing at FOSDEM in the same city.

Distribuir contenido