Agregador de noticias

Swift Blog: Keyword Highlighting Support

Planet Jabber - 13 February, 2015 - 00:00

One of the interesting new features in the upcoming Swift 3.0 release is support for “keyword highlighting”. This allows users to setup Swift such that it’ll alert them to activity that matches their configured highlighting rules. This is particularly useful where a user wants to be alerted when particular discussion topics, or keywords, are mentioned in chatrooms (highlighting rules are configured independently for private chats and chatrooms) - e.g. a Swift developer might choose to have a highlight configured to alert them when the word “Swift” is mentioned in a chatroom they watch, or a military operator may be interested in keywords such as “MEDEVAC”. Highlights can either be configured to be visual (with foreground/background colour applicable per rule), or may be audible (either with the default sound, or user-provided sounds per-rule). Here a keyword highlight for “Swift” rendered with black text on a green background is shown, along with a blue-on-red highlight for “late”.

As well as per-keyword highlighting rules, messages from a particular user may be subject to highlighting, e.g. the following screenshot shows a highlight configured for the Queen of Hearts’s user (black on yellow).

These features will be released with Swift 3.0, and can currently be configured by selecting “Edit Highlight Rules” from the general menu in Swift.

(This post describes a currently unreleased feature, so details may change slightly before release)

ProcessOne: ejabberd joins the Elixir revolution

Planet Jabber - 10 February, 2015 - 17:14

ejabberd has always been a key project for Erlang.

When I talk to many of the developers that have learned Erlang in that past 10 years, they often thank us for ejabberd. “ejabberd is the main reason why I have learned Erlang”.

That said, Erlang is not for everyone. Some people hate the syntax and cannot overcome their relunctance to learn it.

We already made the life of ejabberd users easier by providing YAML syntax for configuration files. YAML format is quite well know and avoided the typical mistakes make by users when editing “Erlang
tuple-atoms-and-list” syntax file. So, YAML configuration files format was received as a relief by many users.

Today, we are getting further and are making Elixir language a first class citizen for ejabberd. You can now develop any module you want in ejabberd leveraging all ejabberd API using only Elixir language.

For those who already know about Elixir, I already hear the excitement that this new feature is generating. I know, I am extremely excited myself. This change is probably the most important change in the life of ejabberd and we are already working with Elixir developer to improve on this existing implementation and boost our development community by making ejabberd development more accessible.

In turn, we are hoping to do for Elixir, what ejabberd did for Erlang in terms of recognition. For those who do not know about Elixir: This is a clean, modern programming language, created by Jose Valim, supported by hundreds of enthousiastic developers. It is inspired by Ruby syntax, with all the benefit of Erlang VM, that is clustering, lightweight processes, robustness, fault tolerance, etc.

If you do not yet know Elixir, you now have the best reason of the world to learn it :)

How to get started

Here is how to start using Elixir in ejabberd today. The change are available in ejabberd master branch and will be integrated in next ejabberd official version.

Prerequisite

Install Erlang R17

git clone and build ejabberd with Elixir support $ git clone git@github.com:processone/ejabberd.git $ cd ejabberd $ chmod +x autogen.sh $ ./autogen.sh $ ./configure --prefix=$HOME/my-ejabberd --enable-elixir $ make && make install

Your ejabberd is now Elixir-enabled:

$ cd $HOME/my-ejabberd/ $ ./sbin/ejabberdctl live (ejabberd@localhost)1> m('Elixir.Enum'). Module 'Elixir.Enum' compiled: Date: January 24 2015, Time: 16.27 Compiler options: [debug_info] Object file: /Users/mremond/my-ejabberd/lib/ejabberd/ebin/Elixir.Enum.beam ...

ejabberdctl module has now extra options:
– iexlive: Start ejabberd and keep an Elixir command open
– iexdebug: Attach and Elixir console to an already running ejabberd

It means you can use ejabberd shell using Elixir interactive commands:

$ cd $HOME/my-ejabberd/ $ ./sbin/ejabberdctl iexlive ... iex(ejabberd@localhost)1> IO.puts "Hi ejabberd + elixir" Hi ejabberd + elixir :ok ... # Creating a user: iex(ejabberd@localhost)3> :ejabberd_auth.try_register("test2", "localhost", "mypass") {:atomic, :ok}

Welcome to the revolution !

Writing ejabberd plugins in Elixir

You can now write plugins in Elixir and register hooks to expand ejabberd features in Elixir.

ejabberd lib directory is the place where you put your Elixir file so that the build chain knows how to compile them.

In ejabberd lib/ directory, add the file mod_presence_demo.ex:

defmodule ModPresenceDemo do @behaviour :gen_mod def start(_host, _opts) do :ok end def stop(_host) do :ok end end

This is the smallest possible ejabberd module. We ignore the host and
the options for now.

When you type make your module should build properly.

When doing make install, it should install properly the newly created
module.

You can now use it in ejabberd configuration file ejabberd.yml. Just
add this line in the module section:

modules: ... ModPresenceDemo: {}

As you see, you can directly use the Elixir module name. ejabberd can
detect this is an Elixir module and use it appropriately.

Let’s expand a bit on this module:

defmodule ModPresenceDemo do import Ejabberd.Logger # this allow using info, error, etc for logging @behaviour :gen_mod def start(host, _opts) do info('Starting ejabberd module Presence Demo') Ejabberd.Hooks.add(:set_presence_hook, host, __ENV__.module, :on_presence, 50) :ok end def stop(host) do info('Stopping ejabberd module Presence Demo') Ejabberd.Hooks.delete(:set_presence_hook, host, __ENV__.module, :on_presence, 50) :ok end def on_presence(user, _server, _resource, _packet) do info('Receive presence for #{user}') :none end end

When you launch ejabberd with that new module, you should see the following line in the log file (or console if running live):

15:17:58.913 [info] Starting ejabberd module Presence Demo test

And anytime an XMPP client changes its presence, you should see the following in the log file:

15:30:01.266 [info] Receive presence for test

We are in the process of revamping our developer documentation to help both Erlang and Elixir developer get up to speed on ejabberd module development. You can expect follow up articles how how to get further
developing ejabberd with the power of Elixir.

In the meantime, all the ejabberd community is very glad to help get your started with ejabberd development using Elixir.

Please, join ejabberd mailing list or join the ejabberd chat room on XMPP (ejabberd@conference.jabber.ru)

We are all eager to see what great ejabberd extension you are going to build with Elixir.

ProcessOne: Using ejabberd as a customer messaging tool at Mila – SeaBeyond 2014 Video

Planet Jabber - 9 February, 2015 - 16:09

Michael Weibel explains at SeaBeyond conference how Mila enabled their online platform for professionals with realtime messaging features with ejabberd.

ProcessOne: ProcessOne ejabberd and Boxcar roadmap – SeaBeyond 2014 Video

Planet Jabber - 9 February, 2015 - 15:56

Mickaël Rémond presents ProcessOne past product development and explains how it fits into a consistent long term vision about ejabberd, XMPP, push, mobile and realtime messaging in general.

For ejabberd, focus is on two areas:
– ejabberd Community continuous improvements and accelerating the collaboration with existing communities.
– ejabberd SaaS turn key solution for robust, possibly massive scale, cost effective, no hassle deployments.

For Boxcar, we will be focusing on developers, offering new services relating to push and bridging with our XMPP / ejabberd skills and toolset:
– Widgets and watches support
– Analytics
– Ability to chat from a push notification

Here is the full ProcessOne roadmap talk, putting our development effort into perspective:

Enjoy !

Ignite Realtime Blog: Introducing restAPI plugin for Openfire

Planet Jabber - 6 February, 2015 - 14:53

The Ignite Realtime Community is pleased to announce the 1.0.0 release of the REST API plugin for Openfire.  This plugin is being developed by community member Redeyes. This plugin merges and replaces the functionality found in the "MUC Service Plugin" and the REST functionality found in the "User Service Plugin".  This new plugin allows for REST style administration of Openfire.

 

The current feature list, taken from the README file includes:

  • Get overview over all or specific user and to create, update or delete a user
  • Get overview over all user roster entries and to add, update or delete a roster entry
  • Add user to a group and remove a user from a group
  • Lockout or unlock the user (enable / disable)
  • Get overview over all or specific system properties and to create, update or delete system property
  • Get overview over all or specific chat room and to create, update or delete a chat room

 

Please report any issues or feature ideas for this plugin in the Community Forums.

Peter Saint-Andre: RFC 7457

Planet Jabber - 5 February, 2015 - 00:00
I'm in the midst of a big push to finish off the ~15 Internet-Drafts I have underway at the IETF, on topics such as security, internationalization, SIP-XMPP interworking, and even Uniform Resource Names (the lesser-known cousin of URLs). The first of these to be published as an RFC is a document entitled "Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)", a.k.a. RFC 7457. Here I'll freely admit that Yaron Scheffer and Ralph Holz did most of the hard work, but they were gracious enough to include me as a co-author. The three of us are also close to finishing a companion document that describes how to address some of these attacks, so look for that soon!

Ignite Realtime Blog: Smack 4.1.0-beta2 released --- FOSDEM 2015: "XMPP and Android" Slides

Planet Jabber - 3 February, 2015 - 17:24

I'd like to thank everyone at FOSDEM 2015 and XMPP Summit for such a nice time and interesting talks. I sure haven't talk to all people at the XMPP Summit, but hope that we'll meet again soon. You can find my slides of my lightning talk "XMPP and Android" at http://geekplace.eu/files/xmpp_and_android.pdf

 

While travelling home from Brussels in the ICE, I was able to prepare and upload beta2 of Smack 4.1. Please update your build setups and report any issues in the forum.

ProcessOne: Widgets and Watches support with Boxcar Developer Platform – SeaBeyond 2014 Video

Planet Jabber - 3 February, 2015 - 11:14

Mickaël Rémond shows how Boxcar Developer platform is going to merge push notifications and mobile widget state display into a single consistent platform.

He then explains how this feature can directly support both Android Wear and Apple Watch.

Enjoy !

ProcessOne: Bridging Push and Chat to build a Mobile only Chat Support Service

Planet Jabber - 28 January, 2015 - 11:23

Mickaël Rémond introduces how push and XMPP chat can work together to build a seamless, mobile only chat support service.

Chat support on mobile is a powerful way to engage with your true mobile users and have a real conversation with them.

This platform leverages two core skills of ProcessOne: XMPP and Push expertise.

The XMPP Standards Foundation: It’s all about choices and control

Planet Jabber - 26 January, 2015 - 13:39

“Why should I use XMPP?” is a question we get asked a lot. Our answer is often technically-focussed, as there are plenty of reasons XMPP might be the right choice, or we might explain about the benefits of a federated approach – where everyone can run their own server and control their own data. Either way, the fact it is an ‘open standard’ never ceases to be mentioned.

Open standards have many advantages over proprietary formats (too many to list in one blog post) but one in particular is that it gives you the choices and control about how you access your data and services.

For example (get ready for the analogies) imagine you are an individual accessing someone else’s XMPP service. Because XMPP is built on open standards, you get to choose what applications you use to connect to their system; for example, a mobile phone provider does not mandate that to use their services you must use a specific handset – the choice is yours). Your provider may have one that they prefer, or offer, but there are myriad other XMPP applications – the choice remains yours and you can make that choice based on your individual preferences and requirements.

Even better, if a new project implements a better XMPP client than the one you are currently using, firstly, that project is able to do so, and secondly – you are free to start using it! Back to our phone analogy, imagine if a new mobile handset came out that was even better than the one you had chosen, and you could just pop your sim card out of the old phone and straight into the new one… no hassle, but a much better service for you.

And if you have particular needs not being met by existing clients, you are freely able to implement your own or to extend any of the open source options to meet those requirements. The power is all yours.

This is a critically important difference between open standards (like XMPP) and access to proprietary systems – if you use a proprietary system, the operator is in control of how you access the service; and on a whim they could choose to shut down your choice of third-party clients. Using our phone analogy, this is like your mobile service provider controlling which handsets you can use, and on a whim deciding that they have 1 choice and only than handset can be used from now on. In this situation you might find yourself unable to access your data in a useful way. A proprietary system may also release a new version of the client that you don’t like or that doesn’t run on your systems; if they force upgrades you may no longer be able to access the systems or your data. As you can see, the choice isn’t really yours.

Alternatively, imagine you are an organisation running an internal service. You might choose to use a cloud provider, in which case the advantages of choosing a vendor using open standards is the same as above. You might also want to apply organisational policies to your internal service; here again, open standards like XMPP are a good choice. They ensure that you can choose the client you need, not the client the vendor of a proprietary system wants you to use. An open-standards system even ensures (with the ability to export your data) the option to migrate from one server provider to another using mechanisms defined for XMPP servers. When its your systems, it should be your choice.

These advantages also apply to third-party developers – developing for XMPP gives you a level playing field and you’re free to implement your client, server, library, or component according to the standards; you don’t run the risk of being locked out of the systems for which you’re developing, either by unpublished protocol changes or by legal action. And if you think the protocols can be better, you can even contribute to the open standards process and make improvements you need.

Using open standards matters whenever your choices are important to you, be it today or tomorrow. And that is why you should use XMPP.

ProcessOne: Adding Push to Mobile App with Boxcar Developer Push – SeaBeyond 2014 Video

Planet Jabber - 26 January, 2015 - 10:53

In this Boxcar Developer Push Workshop, Mickaël Rémond explains how to integrate mobile push notifications using Boxcar Developer Platform.

Boxcar Platform covers Apple, Google and Amazon push.

Fanout Blog: Building a realtime API in Django

Planet Jabber - 25 January, 2015 - 05:49
Django is an awesome framework for building web services using the Python language. However, it is not well-suited for handling long-lived connections, which are needed for realtime data push. In this article we'll explain how to pair Django with Fanout to reach realtime nirvana.

...

buddycloud: The Buddycloud plan for 2015

Planet Jabber - 23 January, 2015 - 15:32

Some thinking on how we are approaching 2015.

More Incremental Advances

In 2012 we set our sights on designing the best way to build messaging

Today Buddycloud is being added to more and more apps customers apps. This is good. But not good enough: in 2015 we’re doubling down on making incremental changes to the Buddycloud-stack that help with reliability and scalability.

We’ll also be spending more time on the open specification process that powers Buddycloud so that others can build their own messaging products.

Stay Lean and Flexible

We’re fortunate to have a revenue stream from existing Buddycloud customers. And we’re humbled by their trust in our open communication mission.

Each Buddycloud customer has slightly different needs. And this is helping us make sure we keep the Buddycloud stack flexible enough to cover general use cases. 

Improve on Our Competition

Yes, there are other messaging systems out there.

But we notice developers want something that does what it says it will do. Reliably. And with the added benefit of being able to run on-premises and federate with other sites. No other commercial messaging stacks do this. 

Focus on Product Not Sales

We’re a tech team that sees our engineering selling itself - weekend hacking projects becoming enterprise messaging systems.

Boring unsexy, no big launch parties, self funded. And no sales team, just good product selling itself with word-of-mouth. 

And that’s our plan for 2015.

ProcessOne: Beacons and Real Time Services with Boxcar – SeaBeyond 2014

Planet Jabber - 23 January, 2015 - 12:56

Sébastien Luquet introduces our prototype for geolocalized push notifications with Boxcar Beacon. The prototype has been built on top of Estimote beacons.

Talk is followed by a live demo.

Thijs Alkemade: Multi-end to multi-end encryption

Planet Jabber - 23 January, 2015 - 08:48

It’s a week until the XMPP Summit in Brussels, which I won’t be able to attend. However, I do have some thoughts about two of the subjects that are on the agenda that I wanted to share.

Carbons/MAM and e2e-encryption seem to be moving in two completely opposite directions: MAM wants to store messages server-side, while e2e protocols like OTR want to ensure those stored messages are useless. But I don’t think they’d have to be mutually exclusive. I think it would be possible to find a solution that unifies the two concepts.

Background

Many chat services nowadays offer synchronizing the most recent messages between all devices. Given the choice between something that is more secure and something that does synchronize, I fear many people will choose the convenience of synchronization.

So far, everything that I’ve looked at fails on at least one of the following:

  1. History synchronization.
  2. e2e-encrypted one-to-one chats.
  3. Forward-secrecy.

With Carbons/MAM you get 1, but if you turn on OTR, you only get 2 and 3. I could go into detail about a number of other services, but the bottom line is: nothing currently offers all 3. Yet I still think it is possible to make a protocol that does. TextSecure does seem to be working on it, but as far as I know, it’s not possible yet.

Goals

Lets make it a little bit more clear what it is that I think we should aim to achieve:

  1. History synchronization: Every message I receive should go to every device I have. Every message I send should also become visible on every other device I have. When a device has been offline (for a reasonable amount of time), it should receive all the messages I sent and received since it went offline (up to some practical limit).
  2. Messages I send should be e2e-encrypted over every path they take (to each device of the recipient, to each other device I have).
  3. The encryption should be forward-secret: obtaining any long-term private key should not allow the decryption of past messages. Of course we will have to compromise on forward-secrecy a bit, as devices that are offline should still be able to decrypt messages when they come back online. This means whatever is stored to that device’s disk is enough to decrypt all incoming messages while it was offline. However, the stored data should only allow decryption of as few as possible other messages.

I prefer an easy to use over a maximally secure solution: I want users with no idea of what e2e encryption is or why they would want it to be using this opportunistically, without being bothered by it. There are enough ways to achieve good security for people who know what they’re doing, I want to give a (lower) level of security to everyone. For example, manually copying a private key to all your devices is not an acceptable solution. Of course this means the server can tamper with the encrypted chats, but I’d rather have a protocol where the server needs to actively tamper with communications than something where the server can quietly log everything.

Proposal

The following is just an incomplete suggestion of how this could be implemented:

  • I use Axolotl (the TextSecure protocol) to set up sessions between every device I have and every device the recipient of my message has, and among every pair of my own devices.
  • When encrypting a message, the message is first encrypted and authenticated using new, random keys. Then, for every device that should be able to decrypt it, I add an encrypted header that encrypts the keys I’ve just generated. The header also contains the extra data needed for Axolotl (for example, to update the ratchet).
  • The (normal) Carbons extension will make sure this message is delivered to everyone that can decrypt it.
  • Storing messages in MAM is fine and requires no changes to MAM, a device that was offline and comes back online can decrypt all new messages as it saved its Axolotl keys.
  • Even if the MAM archive expires messages after a number of days/weeks/etc. this can still work. Axolotl can detect and recover from missing messages.
  • This does need something that publishes the list of devices someone has, with their public keys (and maybe some “pre-keys”, as TextSecure has). I think PEP could work here, but I haven’t checked.
Some fake FAQs

Why Axolotl, and not OTR?

Axolotl handles sending messages to offline devices better and the cryptographic primitives used are more modern.

Why not draft-miller-xmpp-e2e?

  • Forward-secrecy is completely unspecified by the current version of the draft.
  • There are no “sessions”, messages are encrypted individually. So, there is no protection against an attacker dropping some of the messages.
Conclusion

Of course this is still far from a concrete specification, but I am convinced it is possible to do. Instead of half the XMPP world working on history synchronization and the other half working on breaking that, lets look for a unified solution.

Fanout Blog: Bayeux / Faye compatibility

Planet Jabber - 21 January, 2015 - 19:17
Bayeux is one of the few standard protocols for publish-subscribe messaging on the web. Today we announce Bayeux compatibility in the Fanout.io realtime push service. When you publish JSON objects through our service, they can be received by any Bayeux-compatible client library, such as Faye.

...

Ignite Realtime Blog: Openfire 3.10.0 Beta

Planet Jabber - 21 January, 2015 - 16:59

Hey everyone,

 

Since I took on the role of Openfire project lead, the Openfire developers have been working amazingly hard across almost every part of the server's code, with a view to making a new release we can all be really proud of.

 

After a huge amount of work, the Openfire team is really excited to announce we've reached a beta state with the 3.10.0 release, available from http://www.igniterealtime.org/downloads/beta.jsp

 

This release aims to improve security and stability over the current 3.9.3 stable release, provides a set of important new protocol extensions, and modernizes the XMPP core protocol support - in short, this is going to be the release we wanted to make.

 

While this is a beta release, we're not recommending it for critical production use; however this is running on igniterealtime.org itself and developer sites, and we'd appreciate people trying it out in non-critical production cases.

 

We're hoping it'll reach full release rapidly, and we'll be welcoming experiences of anyone deploying so we can add that last polish. Having dealt with the last remaining blocking bug, we're expecting this to move to a final stable release within a week or two.

 

Dave.

ProcessOne: CryptPad introduction – SeaBeyond 2014 Video

Planet Jabber - 21 January, 2015 - 09:54

Caleb James DeLisles, from XWiki, introduces CryptPad at SeaBeyond 2014 conference.

CryptPad is a zero knowledge realtime collaborative editor, inspired by Bitcoin mechanisms.
Content is encrypted so only people who have the CryptPad link can access and read the content.

You can test it on Cryptpad

ProcessOne: Web Push Notifications with Websockets – SeaBeyond 2014 Video

Planet Jabber - 19 January, 2015 - 10:44

Here is the recording of Christophe Romain’s talk on the WebSockets feature we are adding in our Boxcar Developer Push platform:

The XMPP Standards Foundation: XMPP Summit 17

Planet Jabber - 16 January, 2015 - 12:16

The 17th XSF Summit is approaching!

On January 29th and 30th 2015, just before FOSDEM2015. members of the XMPP community will be gathering at the Cisco offices in Diegem, Brussels to talk about all things XMPP.

Our agenda is evolving but so far includes:

  • XMPP-IoT, Current state of the IoT XEPs
  • Editor team automation sprint
  • e2e encryption & OTR
  • The state of UPNP and their XMPP cloud project (and us as liaisons)
  • Relation/Liaison to W3C interest group on the Web of Things: charter
  • XEP-0322 EXI: Update on/upstreaming of implementation, comments

To keep up to date with Summit plans, please visit the wiki page for Summit 17 . If you intend to come along to the Summit, please join the summit@xmpp.org discussion list and post with your participation request.

 

Distribuir contenido