Planet Jabber

June 28, 2017

Paul Schaub

Fourth week of GSoC and OMEMO thoughts

GSoC

Evaluation phase is there! Time went by faster than I expected. That’s a good sign, I really enjoy working on Smack (besides when my code does not work :D ).

I spent this week to work on the next iteration of my Jingle code. IBB once again works, but SOCKS5 still misses a tiny bit, which I struggle to find. For some reason the sending thread hangs up and blocks just before sending begins. Its probably a minor issue, which can be fixed by changing one line of code, nevertheless I’m struggeling to find the solution.

Apart from that it turned out, that a bug with smack-omemo which I was earlier (unsuccessfully) trying to solve resurrected from the land of closed bug reports. Under very special conditions pubsub results seem to only arrive in Smack exactly after the result listener timed out. This keeps smack-omemo from fetching device bundles on some servers. I originally thought this was a configuration issue with my server, but it turned out that aTalk (a Jitsi for Android fork which is working on including OMEMO support) faces the exact same issue. Looks like I’ll have to investigate this issue once more.

OMEMO – Reflections

It appears that soon the council will decide on the future of OMEMO. I really hope, that the decision will make everyone happy and that the XMPP community (and – perhaps more important – the users) will benefit from the outcome.

There are multiple options for the direction, which the development of OMEMO can take. While everybody aggrees, that something should happen, it is not clear what.

OMEMO is already rather well deployed in the wild, so it is obviously not a good idea to break compatibility with existing implementations. A few months ago, OMEMO underwent a very minor protocol change to mitigate a vulnerability and even though Conversations (birthplace to OMEMO) made a smooth transition over multiple versions, things broke and confused users. While things like this probably cannot be avoided in a protocol which is alive and changing, it is desirable to avoid breaking stuff for users. Technology is made for users. Keeping them happy should be highest priority.

However, at the moment not every user can benefit from OMEMO since the current specification is based on libsignal, which is licensed under the GPLv3. This makes the integration in premissively licensed software either expensive (buying a license from OWS), or laborious (substitute libsignal with other double ratchet library). While the first option is probably unrealistic, the second option has been further investigated during discussions on the standards mailing list.

Already the “official” specification of OMEMO is based on the Olm library instead of libsignal. Olm more or less resembles OWSs double ratchet specification, which has been published by OWS roughly half a year ago. Both Olm and libsignal got audited, while libsignal got significantly more attention both in the media and among experts. One key difference between both libraries is, that libsignal uses the Extended Triple Diffie Hellman (X3DH) key exchange using the XEdDSA signature scheme. The later allows a signature key to be derived from an encryption key, which spares one key. In order to use this functionality, a special conversion algorithm is used. While apparently this algorithm is not too hard to implement, there is no permissive implementation available in any established, trusty crypto library.

In order to work around this issue, one proposal suggests to replace X3DH completely and switch to another form of key exchange. Personally I’m not sure, whether it is desirable to change a whole (audited) protocol in order to replace a single conversion algorithm. Given the huge echo of the Signal protocol in the media, it is only a matter of time until the conversion algorithm makes its way into approved libraries and frameworks. Software follows the principle of supply and demand and as we can conclude from the mailing list discussion, there is quite a lot of demand even alone in the world of XMPP.

I guess everybody aggrees that it is inconvenient, that the “official” OMEMO XEP does not represent, what is currently implemented in the real world (siacs OMEMO). It is open to debate now, how to continue from here on. One suggestion is to document the current state of siacs OMEMO in a historical XEP and continue development of the protocol in a new one. While starting from scratch offers a lot of new possibilities and allows for a quicker development, it also most definitely implies to completely break compatibility to siacs OMEMO at users expense. XMPP is nearly 20 years old now. I do not believe that we are in a hurry :) .

I think siacs OMEMO should not get frozen in time in favor of OMEMO-NEXT. Users are easily confused with names, so I fear that two competing but incompatible OMEMOs are definitely not the way to go. On the other hand, a new standard with a new name that serves the exact same use case is also a bad idea. OMEMO works. Why sould users switch? Instead I’d like to see a smooth transition to a more developer friendly, permissively implementable protocol with broad currency. Already there are OTR and OpenPGP as competitors. We don’t need even more segmentation (let alone the same name for different protocols). I propose to ditch the current official OMEMO XEP in favor of the siacs XEP and from there on go with Andreas’ suggestion, which allows both libsignal as well as Olm to be used simultaneously. This allows permissive implementations of OMEMO, drives development of a permissively licensed conversion algorithm and does not keep users standing in the rain.

To conclude my reflections: Users who use OMEMO will use OMEMO in two or three years. It is up to the community to decide, whether it will be frozen “historical” siacs OMEMO, or collectively developed, smoothly transitioned and unified OMEMO.

Thank you for your time :)

by vanitasvitae at June 28, 2017 00:08

June 27, 2017

Daniel Pocock

How did the world ever work without Facebook?

Almost every day, somebody tells me there is no way they can survive without some social media like Facebook or Twitter. Otherwise mature adults fearful that without these dubious services, they would have no human contact ever again, they would die of hunger and the sky would come crashing down too.

It is particularly disturbing for me to hear this attitude from community activists and campaigners. These are people who aspire to change the world, but can you really change the system using the tools the system gives you?

Revolutionaries like Gandi and the Bolsheviks don't have a lot in common: but both of them changed the world and both of them did so by going against the system. Gandi, of course, relied on non-violence while the Bolsheviks continued to rely on violence long after taking power. Neither of them needed social media but both are likely to be remembered far longer than any viral video clip you have seen recently.

With US border guards asking visitors for their Facebook profiles and Mark Zuckerberg being a regular participant at secretive Bilderberg meetings, it should be clear that Facebook and conventional social media is not on your side, it's on theirs.

Kettling has never been easier

When street protests erupt in major cities such as London, the police build fences around the protesters, cutting them off from the rest of the world. They become an island in the middle of the city, like a construction site or broken down bus that everybody else goes around. The police then set about arresting one person at a time, taking their name and photograph and then slowly letting them leave in different directions. This strategy is called kettling.

Facebook helps kettle activists in their arm chair. The police state can gather far more data about them, while their impact is even more muted than if they ventured out of their home.

You are more likely to win the lottery than make a viral campaign

Every week there is news about some social media campaign that has gone viral. Every day, marketing professionals, professional campaigners and motivated activists sit at their computer spending hours trying to replicate this phenomenon.

Do the math: how many of these campaigns can really be viral success stories? Society can only absorb a small number of these campaigns at any one time. For most of the people trying to ignite such campaigns, their time and energy is wasted, much like money spent buying lottery tickets and with odds that are just as bad.

It is far better to focus on the quality of your work in other ways than to waste any time on social media. If you do something that is truly extraordinary, then other people will pick it up and share it for you and that is how a viral campaign really begins. The time and effort you put into trying to force something to become viral is wasting the energy and concentration you need to make something that is worthy of really being viral.

An earthquake and an escaped lion never needed to announce themselves on social media to become an instant hit. If your news isn't extraordinary enough for random people to spontaneously post, share and tweet it in the first place, how can it ever go far?

The news media deliberately over-rates social media

News media outlets, including TV, radio and print, gain a significant benefit crowd-sourcing live information, free of charge, from the public on social media. It is only logical that they will cheer on social media sites and give them regular attention. Have you noticed that whenever Facebook's publicity department makes an announcement, the media are quick to publish it ahead of more significant stories about social or economic issues that impact our lives? Why do you think the media puts Facebook up on a podium like this, ahead of all other industries, if the media aren't getting something out of it too?

The tail doesn't wag the dog

One particular example is the news media's fascination with Donald Trump's Twitter account. Some people have gone as far as suggesting that this billionaire could have simply parked his jet and spent the whole of 2016 at one of his golf courses sending tweets and he would have won the presidency anyway. Suggesting that Trump's campaign revolved entirely around Twitter is like suggesting the tail wags the dog.

The reality is different: Trump has been a prominent public figure for decades, both in the business and entertainment world. During his presidential campaign, he had at least 220 major campaign rallies attended by over 1.2 million people in the real world. Without this real-world organization and history, the Twitter account would have been largely ignored like the majority of Twitter accounts.

On the left of politics, the media have been just as quick to suggest that Bernie Sanders and Jeremy Corbyn have been supported by the "Facebook generation". This label is superficial and deceiving. The reality, again, is a grass roots movement that has attracted young people to attend local campaign meetings in pubs up and down the country. Getting people to get out and be active is key. Social media is incidental to their campaign, not indispensible.

Real-world meetings, big or small, are immensely more powerful than a social media presence. Consider the Trump example again: if 100,000 people receive one of his tweets, how many even notice it in the non-stop stream of information we are bombarded with today? On the other hand, if 100,000 bellow out a racist slogan at one of his rallies, is there any doubt whether each and every one of those people is engaged with the campaign at that moment? If you could choose between 100 extra Twitter followers or 10 extra activists attending a meeting every month, which would you prefer?

Do we need this new definition of a Friend?

Facebook is redefining what it means to be a friend.

Is somebody who takes pictures of you and insists on sharing them with hundreds of people, tagging your face for the benefit of biometric profiling systems, really a friend?

If you want to find out what a real friend is and who your real friends really are, there is no better way to do so then blowing away your Facebook and Twitter account and waiting to see who contacts you personally about meeting up in the real world.

If you look at a profile on Facebook or Twitter, one of the most prominent features is the number of friends or followers they have. Research suggests that humans can realistically cope with no more than about 150 stable relationships. Facebook, however, has turned Friending people into something like a computer game.

This research is also given far more attention then it deserves though: the number of really meaningful friendships that one person can maintain is far smaller. Think about how many birthdays and spouse's names you can remember and those may be the number of real friendships you can manage well. In his book Busy, Tony Crabbe suggests between 10-20 friendships are in this category and you should spend all your time with these people rather than letting your time be spread thinly across superficial Facebook "friends".

This same logic can be extrapolated to activism and marketing in its many forms: is it better for a campaigner or publicist to have fifty journalists following him on Twitter (where tweets are often lost in the blink of an eye) or three journalists who he meets for drinks from time to time?

Facebook alternatives: the ultimate trap?

Numerous free, open source projects have tried to offer an equivalent to Facebook and Twitter. GNU social, Diaspora and identi.ca are some of the more well known examples.

Trying to persuade people to move from Facebook to one of these platforms rarely works. In most cases, Metcalfe's law suggests the size of Facebook will suck them back in like the gravity of a black hole.

To help people really beat these monstrosities, the most effective strategy is to help them live without social media, whether it is proprietary or not. The best way to convince them may be to give it up yourself and let them see how much you enjoy life without it.

Share your thoughts

The FSFE community has recently been debating the use of propriety software and services. Please feel free to join the list and click here to reply on the thread.

by Daniel.Pocock at June 27, 2017 19:29

June 26, 2017

Tarun Gapta (GSoC 2017)

Week 4

Hello all,

This week was a productive week ! I completed all the elements required for MIX implementation along with their parsers, serializers, and unit tests. The elements completed this week along with their XML examples (taken from XEP) are as follows:
  • Create Element: A client creates a channel by sending a simple request to the MIX service.
<create channel='coven' xmlns='urn:xmpp:mix:1'/>
  • Destroy Element: A client destroys a channel using the destroy payload.
<destroy channel='coven' xmlns='urn:xmpp:mix:1'/>
  • Set Nick Element: The client sends a command to the channel to set / update the nick.
<setnick xmlns='urn:xmpp:mix:1'>
<nick>thirdwitch</nick>
</setnick>
  • Register Nick Element: The client sends a command to the channel to register the nick.
<register xmlns='urn:xmpp:mix:1'>
<nick>thirdwitch</nick>
</register>
  • Update Subscription Element: The client can send a update subscription request updating the list of subscribed nodes.
<update-subscription xmlns='urn:xmpp:mix:1'>
   
<subscribe node='urn:xmpp:mix:nodes:messages'/>
</update-subscription>

This week, I'll be completing service discovery and begin the implementation for MIX use cases. That's all for now !

by Tarun Gupta (noreply@blogger.com) at June 26, 2017 13:53

June 23, 2017

Paweł Alameyo Ścibiorski (GSoC 2017)

#6 Adding certificates to the truststore

Hello ,

Github's pull request of this week included options for adding certificates to the Truststore. Over week I have made long way updating it as initially it was asking user for alias for certificate which he wants to store. Currently it take common name (CN) from subject field of certificate and use it as alias. I also added checking if certificate doesn't exist in Keystore to prevent having many copies of the same certificate (though user can still add copy of certificates with third party tools as Java Keytool or OpenVPN).

 

Overall creating GUI can be time consuming if someone want make it nice looking and easy to use for end user . The biggest issue with graphic interface that I have meet is that it looks sometimes different on different computers. While I PR something what looked for me like this:

spark_my_gui.png

Maybe not totally perfect, some work still will be done here (as adding delete button and fields saying if certificate is valid). But it's look far better than thing that my mentor saw:

spark_guus_screen.png

That spacing at top looks odd and also makes scroll pane with certificates fields smaller . Earlier there were also issues with missing labels. That means there will be need for excessive testing of that GUI with different OS/computers. That's also nice surprise for me as I thought Java should work to quite nice extend independently from platform. Well it was even Java's slogan .

 

For next week I plan to add option to delete certificate as well as take final steps to display certificate extensions.

See you next week,

Paweł

by Paweł Alameyo Ścibiorski (GSoC 2017) (igniterealtime@jiveon.com) at June 23, 2017 21:26

June 21, 2017

ProcessOne

Introducing our Real-time Newsletters

If you have been subscribing our monthly XMPP Radar newsletter, you may have noticed that with every issue it covered a wider area of real-time communication. Apart from XMPP, it also took interest in MQTT, AMQP, many other tools and protocols, other topics like internet of things, and more business-oriented issues of adapting real-time technologies. XMPP Radar also grew substantially, going way past 4,000 subscribers this year, an almost 20% increase in 6 months.

To reflect that growth, we are renaming XMPP Radar to Real-time Stack – a newsletter focused on all real-time technologies. On top of that, we are going to create a separate newsletter called Real-time Enterprise – focused on business aspects, transformation of enterprises using real-time infrastructure, open to employees, customers, business applications and devices.

Subscribe to our Real-time Newsletters! If you are already an XMPP Radar subscriber, you will have an option to update your preferences and opt-into Real-time Enterprise newsletter as well. Both newsletters arrive in your inbox every 4 weeks: one at the end of the month, one in the middle of the month. Enjoy!

by Marek Foss at June 21, 2017 18:07

Peter Saint-Andre

Poetry as Code

A few months ago, in preparation for composing a cycle of poems on Nietzsche's ethical philosophy (now half done and provisionally entitled Songs of Zarathustra), I made the time to re-read my favorite book on the writing of metrical poetry: All the Fun's in How You Say a Thing by Timothy Steele. This also inspired me to revisit and revise some of the poems and translations I published years ago in my book Ancient Fire. Sadly, I discovered that those early poems were rather buggy; the translations of Horace were especially malformed and a few of them required major refactoring so that they would compile from a metrical perspective....

June 21, 2017 00:00

June 20, 2017

Paul Schaub

Third Week of GSoC

Another week is has passed and the first evaluation phase slowly approaches. While I already fulfilled my goals (Jingle File Transfer using InBandBytestreams and SOCKS5Bytestreams), I still have a lot of work to do. The first working implementation I did is only so much – working. Barely. Now its time to learn from mistakes I made while I constructed my prototype and find better ways to do it in the next iteration. This is what I was up to in the past week and what will keep me from my usual sleep cycle for the coming week(s).

I spent the past week doing ground work and writing utility classes which will later allow me to send jingle actions in a clean way. The prototype implementation had all constructions of Jingle elements inside of the control flow, which made reading the code very hard. This will change in the next iteration.

While I worked on my implementation(s), I detected some errors in the XEPs involved and created pull requests against the xsf/xeps repository. In other spots I found some unclarities, but unfortunately my questions on the xsf chat were left unanswered. In some cases I found the solution myselves though.

Also I began upstreaming some changes and additions to the Smack repository. Parsers and elements of IBB have already been merged, as well as some more additions to the HashManager (XEP-0300) I created earlier, and some tests and fixes for the existing Jingle framework. Still open are my PR for SOCKS5 parsers and the first parts of the Jingle file transfer package.

I also dedicated a tiny little bit of my spare time to a non-GSoC project around a blog post on how to create an OMEMO capable chat client using Smack in less than 200 lines of code. The source code of the example application can be found in the FSFE’s brand new git repository. Unfortunately I also found a small bug in my OMEMO code that I have to fix sometime in the next weeks (nothing crucial, just some annoying faulty behavior).

I plan to spend the coming week working on my Jingle code, so that I have a mostly working framework when the evaluation phase begins.

Thats all for now. Happy Hacking :)

by vanitasvitae at June 20, 2017 20:05

Tarun Gapta (GSoC 2017)

Till Week 3 - Elements !

Hello all,

I am Tarun, a senior year student at IIIT Hyderabad, India. This year I was selected as a GSoC student by XMPP Standards Foundation to work on Mediated Information Exchange (MIX), which is intended as a replacement for Multi-User Chat (MUC). I'm being mentored by Tobias and Edwin. Let me begin by explaining why do we need MIX as a replacement for MUC ?
  • In the years after MUC was designed, both Publish-Subscribe and Message Archive Management have been developed and it is desirable to reuse these building blocks (e.g., MAM can be used for message history) rather than using the less robust methods defined in Multi-User Chat .
  • It is difficult to use MUC for building multimedia applications without undesirable adaptations.
  • A number of use cases has emerged in group communication, which are explained here.
I have started by implementing elements (payloads), which will be coming in / send out in the form of XML. Therefore, we need parsers and serializers for each payload to be able to parse the XML and set the private variables for the Element. On the other hand, Serializers serializes an instance (of the Element) to XML format. I am done with some of the elements with their parsers and serializers and unit tests testing the XML's mentioned in the XEP as follows:
  • Join Element (and Subscribe): This element will be used by clients and their local servers to join a channel.
<join xmlns='urn:xmpp:mix:0' channel='coven@mix.shakespeare.example'>
   
<subscribe node='urn:xmpp:mix:nodes:messages'/>
   
<subscribe node='urn:xmpp:mix:nodes:presence'/>
   
<subscribe node='urn:xmpp:mix:nodes:participants'/>
   
<subscribe node='urn:xmpp:mix:nodes:config'/>
</join>
  • Participant Element: This element will be used to store user nick and their real JIDs.
<participant xmlns='urn:xmpp:mix:0'>
   
<nick>thirdwitch</nick>
</participant>
  • User Preference Element: This element will be used to set user preferences like their JID visibility, private messages, etc.
<user-preference xmlns='urn:xmpp:mix:0'>
<x xmlns='jabber:x:data' type='result'>
   
<field var='FORM_TYPE' type='hidden'>
       
<value>urn:xmpp:mix:0</value>
       
</field>
       
<field var='JID Visibility'>
           
<value>never</value>
       
</field>
       
<field var='Private Messages'>
           
<value>allow</value>
         
</field>
       
<field var='vCard'>
         
<value>block</value>
       
</field>
</x>
</user-preference>
  • Leave element: In order to leave a channel, a user sends a MIX "leave" command to the channel.
<leave xmlns='urn:xmpp:mix:0' channel=`coven@mix.shakespeare.example`/>

That's all for this blog post. This week I'll be completing other elements and service discovery feature. 

by Tarun Gupta (noreply@blogger.com) at June 20, 2017 08:20

June 16, 2017

Paweł Alameyo Ścibiorski (GSoC 2017)

#5 Certificates extensions

Hello,

How was going this week? Well, it took a bit longer to merge code from last PR into Spark's base code, but now there are also buttons for showing certificates (earlier it was shown only after double click on table) and button to upload certificate. Other thing that occurs more complicated that I initially thought, is extracting certificates extensions. Java's X509Certificate class provide methods that return extensions OID (object identifier) for critical and noncritical extensions. It provides also method getExtensionValue( OID ) which returns extensions but encoded. Using some of the Bouncy Castle classes I am able to decode some of this values but they have different structures to which I have to adjust extracted values and map the names of the elements in the structure. Unfortunately some of the values are still enigmatic for me or I can't decode them well yet. On the other hand when I will solve this problems similar work can be done for Openfire to show certificates extensions also there.

 

See you next week,

Paweł

by Paweł Alameyo Ścibiorski (GSoC 2017) (igniterealtime@jiveon.com) at June 16, 2017 19:26

June 15, 2017

ProcessOne

ejabberd 17.06-beta

ejabberd 17.06-beta includes a lot of improvements over the previous 17.04 release. To name the most important ones: new caching system, Riak support for several modules and introduction of Certificate Manager.

Certificate Manager is a feature that has been requested by many organisations, allowing administrators to manage their certificate more easily. From now, starting ejabberd with an invalid certificate will dump a clear entry in ejabberd log file, explaining what’s wrong. Upcoming ACME support will further refine these improvements we’ve worked on early this year to give our users a great experience with certificate management.

The new cache system is also a new component that allows fine tuning of ejabberd performance for either small systems or large scale servers. To use data cache for a supported module, you need to set the module option use_cache. You also have the possibility to define a maximum number of cache entries and/or maximum life time of cached data, so you keep control on your memory use. Example:

modules:
  mod_roster:
    use_cache: true
    cache_size: 10000
    cache_life_time: 3600  # 1 hour

The cleanup tasks on all ejabberd API also continue, consider checking against few methods rename.

Some features and fixes are missing from the 17.06 milestone, and will be worked on the next couple of weeks.

Changes

API

  • Deprecate misc:encode_base64/1 and misc:decode_base64/1
  • Rename is_user_exists function to user_exists
  • Allow api access on both ipv4 and 6 loopback addresses

Admin

  • Refactor ejabberdctl
  • Improve ejabberdctl parameters parsing

Configuration

  • Validate module options on start_module/2
  • Validate new options before module reloading
  • Validate second-level options
  • Introduce iqdisc global option
  • stream_management listen option deprecated, use mod_stream_mgmt
  • Check presence of some files during option validation
  • Speedup configuration options lookup
  • Validate all certfiles on startup
  • Only validate certfiles if public_key:short_name_hash/1 is available
  • Introduce Certficate Manager

Commands

  • Add clear_cache admin command
  • Parse correctly presence_broadcast option in change_room_option command
  • Describe command arguments and results in mod_muc_admin
  • Improve export2sql explanation; remove obsolete and duplicated command
  • Fix and document push_roster_all command

Compilation

  • Erlang 17.5 or higher is required
  • Add --enable-system-deps configure option
  • Add --enable-stun and --enable-sip configure options

Core

  • Speedup Mnesia tables initialization
  • Improve Mnesia tables creation and transformation
  • Improve ejabberd_c2s:close()
  • ejabberd_c2s: Don’t close session on stream resume
  • Speedup loading of translation files
  • Fix ejabberd_router:is_my_route/1

Databases

  • New sql_connect_timeout option
  • New sql_query_timeout option
  • Get rid of sql_queries.erl
  • Use round-robin algorithm when selecting worker from DB pool
  • Add Riak as BOSH RAM backend
  • Add Riak as mod_proxy65 RAM backend
  • Add Riak as mod_carboncopy RAM backend
  • Add Riak as router RAM backend
  • Add Riak as session manager RAM backend
  • Fix cleaning of Riak route table

Cache

  • Implement cache for mod_announce
  • Implement cache for mod_private
  • Implement cache for mod_privacy/mod_blocking
  • Implement cache for mod_last
  • Implement cache for mod_vcard and mod_vcard_xupdate
  • Implement cache for roster
  • Add cache options to the validator
  • Use cache for authentication backends
  • Use new cache API in mod_shared_roster_ldap
  • Use new cache API in ejabberd_oauth
  • Use new cache API in mod_mam
  • Use new cache API in mod_caps
  • Use cache in front of Redis/SQL RAM backends

Modules

  • mod_http_upload: Add support for HTTP File Upload 0.3.0
  • mod_mam: Added export function
  • mod_metrics: Don’t leak with UDP sockets
  • mod_metrics: New options ip and port
  • mod_muc: Allow a room admin to un/subscribe another JID
  • mod_offline: Don’t store messages via a single process
  • mod_offline: Make sure only jabber:x:event tag is present in offline event
  • mod_register: New option ‘access_remove’ ACL
  • mod_stream_mgmt: Preserve stanza count on timeout
  • mod_vcard_ldap: Parse ldap_uids like in eldap_utils

Elixir

  • Update elixir to v1.4.4

Installer

  • Upgrade OTP to 19.3

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.

by Christophe Romain at June 15, 2017 08:18

June 14, 2017

Paul Schaub

Tutorial: Home-made OMEMO client

The german interior minister conference recently decided that the best way to fight terrorism is passing new laws that allow the government to demand access to communication from messengers like WhatsApp and co. Very important: Messengers like WhatsApp. Will even free software developers see requests to change their messengers to allow government access to communications in the future? If it comes so far, how are we then still possible to protect our communications?

The answer could be: Build your own messenger. I want to demonstrate, how simple it is to create a very basic messenger that allows you to send and receive end-to-end encrypted text messages via XMPP using Smack. We will use Smacks latest new feature – OMEMO support to create a very simple XMPP based command line chat application that uses state of the art encryption. I assume, that you all know, what XMPP is. If not, please read it up on Wikipedia. Smack is a java library that makes it easy to use XMPP in an application. OMEMO is basically the Signal protocol for XMPP.

So lets hop straight into it.
In my example, I import smack as a gradle dependency. That looks like this:

gradle.build

apply plugin: 'java'
apply plugin: 'idea'

repositories {
    mavenCentral()
    maven {
        url 'https://oss.sonatype.org/content/repositories/snapshots'
    }
}

ext {
    smackVersion="4.2.1-SNAPSHOT"
}

dependencies {
    compile "org.igniterealtime.smack:smack-java7:$smackVersion"
    compile "org.igniterealtime.smack:smack-omemo-signal:$smackVersion"
    compile "org.igniterealtime.smack:smack-resolver-dnsjava:$smackVersion"
    compile "org.igniterealtime.smack:smack-tcp:$smackVersion"
}

//Pack dependencies into the jar
jar {
    from(configurations.compile.collect { it.isDirectory() ? it : zipTree(it) }) {
    exclude "META-INF/*.SF"
    exclude "META-INF/LICENSE"
    }
    manifest {
        attributes(
            'Main-Class': 'Messenger'
        )
    }
}

Now we can start the main function of our client. We need to create a connection to a server and log in to go online. Lets assume, that the user passes username and password as arguments to our main function. For sake of simplicity, we’ll not catch any errors like wrong number of parameters etc. Also we want to get notified of incoming chat messages and we want to send messages to others.

Messenger.java

public class Messenger {

    private AbstractXMPPConnection connection;
    private static Scanner scanner;

    public static void main(String[] args) throws Exception {
        String username = args[0];
        String password = args[1];
        Messenger messenger = new Messenger(username, password);

        scanner = new Scanner(System.in);
        while(true) {
            String input = scanner.nextLine();

            if (input.startsWith("/quit")) {
                break;
            }
            if (input.isEmpty()) {
                continue;
            }
            messenger.handleInput(input);
        }
    }

    public Messenger(String username, String password) throws Exception {
        connection = new XMPPTCPConnection(username, password);
        connection = connection.connect();
        connection.login();

        ChatManager.getInstanceFor(connection).addIncomingListener(
                (from, message, chat) -> System.out.println(from.asBareJid() + ": " + message)
        );

        System.out.println("Logged in");
    }

    private void handleInput(String input) throws Exception {
        String[] split = input.split(" ");
        String command = split[0];

        switch (command) {
            case "/say":
                if (split.length > 3) {
                    String recipient = split[1];
                    EntityBareJid recipientJid = JidCreate.entityBareFrom(recipient);

                    StringBuilder message = new StringBuilder();
                    for (int i=2; i<split.length; i++) message.append(split[i]);

                    ChatManager.getInstanceFor(connection).chatWith(recipientJid).send(message);
                }
                break;
        }
    }
}

If we now compile this code and execute it using credentials of an existing account, we can already log in and start chatting with others using the /say command (eg. /say bob@marley.jm Hi Bob!). But our communications are unencrypted right now (aside from tls transport encryption). Lets change that next. We want to use OMEMO encryption to secure our messages, so we utilize Smacks new OmemoManager which handles OMEMO encryption. For that purpose, we need a new private variable which will hold our OmemoManager. Also we make some changes to the constructor.

Messenger.java

private OmemoManager omemoManager;

public Messenger(String username, String password) throws Exception {
    connection = new XMPPTCPConnection(username, password);
    connection = connection.connect();
    connection.login();

    //additions begin here
    SignalOmemoService.acknowledgeLicense();
    SignalOmemoService.setup();
    //path where keys get stored
    OmemoConfiguration.setFileBasedOmemoStoreDefaultPath(new File("path"));
    omemoManager = OmemoManager.getInstanceFor(connection);

    //Listener for incoming OMEMO messages
    omemoManager.addOmemoMessageListener(new OmemoMessageListener() {
        @Override
        public void onOmemoMessageReceived(String decryptedBody, Message encryptedMessage,
                        Message wrappingMessage, OmemoMessageInformation omemoInformation) {
            System.out.println("(O) " + encryptedMessage.getFrom() + ": " + decryptedBody);
        }

        @Override
        public void onOmemoKeyTransportReceived(CipherAndAuthTag cipherAndAuthTag, Message message,
                        Message wrappingMessage, OmemoMessageInformation omemoInformation) {
            //Not needed
        }
    });

    ChatManager.getInstanceFor(connection).addIncomingListener(
            (from, message, chat) -> System.out.println(from.asBareJid() + ": " + message)
    );
    omemoManager.initialize();
    //additions end here.
    System.out.println("Logged in");
}

Also we must add two new commands that are needed to control OMEMO. /omemo is similar to /say, but will encrypt the message via OMEMO. /trust is used to trust an identity. Before you can send a message, you have to decide, whether you want to trust or distrust an identity. When you call the trust command, the client will present you with a fingerprint which you have to compare with your chat patner. Only if the fingerprint matches, you should trust it. We add the following two cases to the handleInput’s switch case environment:

Messenger.java

case "/omemo":
    if (split.length > 2) {
        String recipient = split[1];
        EntityBareJid recipientJid = JidCreate.entityBareFrom(recipient);

        StringBuilder message = new StringBuilder();
        for (int i=2; i<split.length; i++) message.append(split[i]);

        //encrypt
        Message encrypted = null;
        try {
            encrypted = OmemoManager.getInstanceFor(connection).encrypt(recipientJid, message.toString());
        }
        // In case of undecided devices
        catch (UndecidedOmemoIdentityException e) {
            System.out.println("Undecided Identities: ");
            for (OmemoDevice device : e.getUntrustedDevices()) {
                System.out.println(device);
            }
        }
        //In case we cannot establish session with some devices
        catch (CannotEstablishOmemoSessionException e) {
            encrypted = omemoManager.encryptForExistingSessions(e, message.toString());
        }

        //send
        if (encrypted != null) {
            ChatManager.getInstanceFor(connection).chatWith(recipientJid).send(encrypted);
        }
    }
    break;

case "/trust":
    if (split.length == 2) {
        BareJid contact = JidCreate.bareFrom(split[1]);
        HashMap<OmemoDevice, OmemoFingerprint> fingerprints =
                omemoManager.getActiveFingerprints(contact);

        //Let user decide
        for (OmemoDevice d : fingerprints.keySet()) {
            System.out.println("Trust (1), or distrust (2)?");
            System.out.println(OmemoKeyUtil.prettyFingerprint(fingerprints.get(d)));
            int decision = Integer.parseInt(scanner.nextLine());
            if (decision == 1) {
               omemoManager.trustOmemoIdentity(d, fingerprints.get(d));
            } else {
                omemoManager.distrustOmemoIdentity(d, fingerprints.get(d));
            }
        }
    }
    break;

Now we can trust contact OMEMO identities using /trust bob@marley.jm and send them encrypted messages using /omemo bob@marley.jm Hi Bob!. When we receive OMEMO messages, they are indicated by a “(O)” in front of the sender.
If we want to go really fancy, we can let our messenger display, whether received messages are encrypted using a trusted key. Unfortunately, there is no convenience method for this available yet, so we have to do a small dirty workaround. We modify the onOmemoMessageReceived method of the OmemoMessageListener like this:

Messenger.java

@Override
public void onOmemoMessageReceived(String decryptedBody, Message encryptedMessage,
            Message wrappingMessage, OmemoMessageInformation omemoInformation) {
    //Get identityKey of sender
    IdentityKey senderKey = (IdentityKey) omemoInformation.getSenderIdentityKey().getIdentityKey();
    OmemoService<?,IdentityKey,?,?,?,?,?,?,?> service = (OmemoService<?,IdentityKey,?,?,?,?,?,?,?>) OmemoService.getInstance();

    //get the fingerprint of the key
    OmemoFingerprint fingerprint = service.getOmemoStoreBackend().keyUtil().getFingerprint(senderKey);
    //Lookup trust status
    boolean trusted = omemoManager.isTrustedOmemoIdentity(omemoInformation.getSenderDevice(), fingerprint);

    System.out.println("(O) " + (trusted ? "T" : "D") + " " + encryptedMessage.getFrom() + ": " + decryptedBody);
}

Now when we receive a message from a trusted identity, there will be a “T” before the message, otherwise there is a “D”.
I hope I could give a brief introduction on how to use Smacks OMEMO support. You now have a basic chat client, that is capable of exchanging multi-end-to-multi-end encrypted messages with other XMPP clients that support OMEMO. All took less than 200 lines of code! Now its up to you to add additional features like support for message carbons, offline messages and co. Spoiler: Its not hard at all :)
You can find the source code of this tutorial in the FSFE’s git repository.

When the government is unable or simply not willing to preserve your privacy, you’ll have to do it yourself.

Happy Hacking :)

by vanitasvitae at June 14, 2017 22:19

GSoC – Second week of coding

The second week of GSoC is over! My Jingle implementation progresses.

Most of my efforts went into designing the state machine behind the Jingle and Jingle File Transfer protocol. Because I never really worked with asynchronous communication, let alone network code before, it takes some time to get my head around that.

I’m heavily utilizing the water fall development model – I code until I get stuck at some point I did not consider at all, then I create a new class and start over again. This is very tideous, but I make slow progress towards working Jingle Socks5 Bytestream transports!

All in all I predict, that it’ll take its time to fully complete the Jingle implementation so that it covers every corner case.

Introducing JET!

While working on my Jingle code, I also started writing down my plans for Jingle Encrypted Transfers (jet). My goal is to keep that specification as simple as possible while providing a reasonable way to exchange encrypted data. I decided, that hiding metadata is not in the scope of this document for now, but can later be specified in a seperate document. Contributions and thoughts regarding encrypted Jingle file transfer are welcome :)

Happy Hacking!

by vanitasvitae at June 14, 2017 10:06

June 09, 2017

Paweł Alameyo Ścibiorski (GSoC 2017)

#4 New dialog for single certificate

Hello,

This week I have made another panel for certificates. The one that I did last week was listing all certificates in truststore and the new one shows details about selected certificate. This details include all fields basic fields of certificate such as issuers, signature, or public key value and others. The one thing I still have to add are certificate's extensions. Number of them can be various so number of text fields and labels that have to be added can also vary. Even some standard certificate's attributes, such as value of public key, can take much space on the screen and this have to be somehow accommodated. That means new single certificate panel have to be scrollable to allow see all cert's basic attributes and extensions.

Effect is visible on this screenshots:

certTable.jpgsingleCertificate.jpg

It's not perfect yet, for example "Valid" column shows for each row false value because it's not checking validity isn't yet implemented. Second panel also might need some additional indicators of certificate validity expiration. That goes for next week and also another issues as adding certificates extensions. One of my bigger concerns for now is way of storing list of exemptions but I have nice suggestion from my mentor which I might try.

 

See you next week,

Paweł

by Paweł Alameyo Ścibiorski (GSoC 2017) (igniterealtime@jiveon.com) at June 09, 2017 21:57

June 08, 2017

ProcessOne

XMPP Radar Newsletter #23

The following articles got our attention in the month of May:

Google Summer of Code hosts ejabberd projects

Like in previous years, ejabberd projects are participating in Google Summer of Code 2017. This year, nine BEAM Community projects have been accepted – two of them involve ejabberd.

Coinbase is launching an Ethereum messaging app

Coinbase is reportedly launching a new subsidiary brand focusing on secure messaging and blockchain-enabled payments, its chief executive said in online statements.

Internet of Things and connected assets

Data in the 21st century has been compared to oil in the 19th century: a vast, valuable, and still largely untapped resource. In this series of articles, you can find interesting use cases of IoT and data analysis.

Internet of Things application protocols

Imagine an environment of constrained devices which are Always, Anywhere and Anytime connected with each other and sending data or information which can be further processed over cloud to generate analytic result which can be used to automate an action. How billions of things will communicate?

How to install eJabberd XMPP server on Ubuntu

If you never tried ejabberd before, here’s a super-simple guide on how to get started with one of the most popular XMPP servers.

Google Talk shutting down on June 26

Here’s a friendly reminder that Google announced to completely shut down the Google Talk service after June 26, 2017.

by Marek Foss at June 08, 2017 09:21

June 06, 2017

Ignite Realtime Blog

Smack v4.2 Introduces OMEMO Support!

This blogpost doubles as a GSoC update, as well as a version release blog post.

 

OMEMO Clownfish logo.
OMEMO Clownfish logo (conversations.im)

 

I have the honour to announce the latest release of Smack! Version 4.2.1 brings among bug fixes and additional features like Explicit Message Encryption (XEP-0380) and Message Processing Hints (XEP-0334) support for OMEMO Multi-End-Message-and-Object encryption (XEP-0384). The OMEMO protocol was developed by Andreas Straub for the Conversations messenger (also as a Google Summer of Code project) in 2015. Since then it got quite popular and drew a lot of attention for XMPP in the media. My hope is that my efforts to develop an easy to use Smack module will result in an even broader adoption.

 

The new Smack release is available from the Maven snapshot repository.

 

OMEMO is a protocol for multi-end to multi-end encrypted communication, which utilizes the so called Double Ratchet algorithm. It fulfills amongst the basic requirements of encrypted communication (confidentiality, authenticity and integrity) also the properties of deniability and forward secrecy as well as future secrecy. Smacks implementation brings support for encrypted single and group chats including identity management and session renegotiation.

 

Current implementations (as well as this one) are based upon the libsignal library developed by OpenWhisperSystems for their popular Signal (formerly TextSecure) messenger. Smack's OMEMO support is structured in two modules. There is smack-omemo (APL licensed), which contains the logic specified in the XEP, as well as some basic cryptographic code. The other module smack-omemo-signal (GPLv3 licensed) implements some abstract methods defined by smack-omemo and encapsulates all function calls to libsignal.

 

Currently smack-omemo-signal is the only module available that implements the double ratchet functionality, but there has been a lot of discussion on the XMPP Standards Foundations mailing list regarding the use of alternative (more permissively licensed) libraries for OMEMO (like for example Olm, a double ratchet implementation from our friends over at the [matrix] project). So once there is a new specification that enables the use of other libraries, it should be pretty easy to write another module for smack-omemo enabling OMEMO support for clients that are not GPLv3 compatible as well.

 

Smack’s OMEMO modules are my first bigger contribution to a free software project and started as part of my bachelors thesis. I’m quite happy with the outcome

 

Smack Logo
Also Smack has a new Logo!

 

That was a lot of talking about OMEMO. Now comes the second functioning of this blog post, my GSoC update.

 

My project of implementing Jingle File Transfer (XEP-0234) for Smack is going relatively well. I'm stuck at some points where there are ambiguities in the XEP or things I don't know yet, but most of the time I find another construction site where I can continue my work. Currently I'm implementing stanza providers and elements needed for file transfer. Along the way I steadily create Junit tests to keep the code coverage at a high level. Already it pays off when there are fiddly changes in the element structure. I already got file transfer over Jingle IBB working.

 

It’s a real pleasure to learn all the tools I never used before like code coverage reports or mocking and I think Flow does a good job introducing me to them one by one.

 

That’s all for now. Happy hacking

by Ignite Realtime Blog (igniterealtime@jiveon.com) at June 06, 2017 19:57

June 02, 2017

Paweł Alameyo Ścibiorski (GSoC 2017)

#3 Start of coding and labs on water.

Ahoy ,

Part of the GSoC is time managing and this week I had 2 days laboratories outside of the city, on the lake with Department of Marine Electronics Systems. Just at the start of the first week of coding . As I was unaware of my programming capabilities there I started a bit earlier delivering first chunk of code on Tuesday evening .

 

It include part of the graphic interface listing certificates in table and some of the classes supporting that. Such "support" classes are model class for certificates which will contain all certificate fields and controller class which help in suiting certificates to table and in the future will serve for extracting content of the truststores. Generally that wasn't hard but once I stupidly stuck siting to about 2.00 AM wondering how to display checkbox in the table. To my defense, in the morning next day I figured it in less than 5 minutes so maybe I just didn't slept enough .

 

As I mentioned in the beginning I had laboratories on the lake where I and my student group were driving the boat across lake and working with different echolocation equipment as radars, sonars, ultrasonic wave speed meters, echo sounding sonar and radar guns. Some of the experiments and measurements were conducted on the boat while others in the laboratory building on the pier. Summarizing that was pretty cool, not standard lab. I will throw here picture of the boat as I don't think I will have opportunity to add any picture soon (but you can see code on the Spark's github).

C538OgT.jpgSo what are task for next week?

I have half finished panel listing certificates but I still need to extract data of the certificates into that panel. Also I want to add additional dialog that would show all fields of the particular certificate.

 

See you next week,
Paweł

by Paweł Alameyo Ścibiorski (GSoC 2017) (igniterealtime@jiveon.com) at June 02, 2017 16:45

May 31, 2017

Swift Blog

Swift 4.0 RC2: Now Available

A Release Candiate for Swift 4.0 is now available for download. Read on for more information and download instructions.

Swift 4.0 RC2 is now available from our releases page. This release includes:

  • Support for message carbons (XEP-0280)
  • Trellis mode enabled as a default feature, allowing several tiled chats windows to be shown at once
  • New chat theme including a new font
  • Redesigned keyword highlighting
  • Improved spell checker support on Linux
  • Support for automatic software updates on macOS
  • Support for unicode emojis on macOS
  • And assorted smaller features and usability enhancements

Please email (swift@swift.im) or tweet (@swift_im) any feedback you have to help us further improve Swift.

May 31, 2017 00:00

May 26, 2017

Paweł Alameyo Ścibiorski (GSoC 2017)

#2 Certificates and keystores

Hi again,

This week I was checking tools for managing certificates. First is Java Keytool, that's shell/command line tool which give easy way to access Keystores and list all certificates or extract particular by alias. Other one was easy rsa that comes with openVPN, it's also nice tool for creating certificates, but seems give less options than Java's.

 

After that I started to looking how to manage certificates in Java's code. Extracting certificate from Keystore is pretty straightforward: load Keystore from directory as file, create instance of Keystore in code and load file to that instance using password for Keystore. From now extracting basic fields of certificate is easy as it can be done with getters methods, though getting extensions fields is a bit more complicated.

 

What else could I do about certificates? Create own, that's seems impossible to do easy way with basic Java so I had to add Bouncy Castle library to my dependencies. Often happens that external libraries have more frequent changes that native Java stuff. Effect is that found examples on various websites are often not up to date. So what to do? Check in documentation as in the end everything should be there . However going through can be sometimes like looking for missing pice of puzzles: class A is deprecated use instead class B > class B is also deprecated use class C > constructor of C's class takes different arguments than constructor of A class. But that's what programmers do . In the end I have done self-signed certificates with deprecated tools for now, while I am also close to solve it with new methods. Nevertheless that would be useful in later parts of GSoC project so I have still time for this.

Next week I should have already taken the first steps in doing project of certificate manager for Spark.
Cya,
Paweł

by Paweł Alameyo Ścibiorski (GSoC 2017) (igniterealtime@jiveon.com) at May 26, 2017 21:51

Paul Schaub

Last week of GSoC Community Bonding

This is my report for the last week of community bonding. On next tuesday the coding phase officially begins \o/.

I spent my week like I did the one before; writing tests, increasing the codecoverage of my Smack OMEMO module. Today the coverage finally reached the same level as the main codebase, meaning my PR wouldn’t decrease the percentage anymore. Apart from that I’ve read some tips on java.nio usage for file transfer and made myself more familiar with its non-blocking IO concepts.

Throughout the week I took the one or other chance to distract myself from work by pariticipating in OMEMO related discussions on the standards mailing list. I’m quite happy, that there’s a vital discussion on the topic which seems to have a solution in prospect which is acceptable for everyone. Specifying the OMEMO XEP in a way that enables implementations using different crypto libraries is definitely a huge step forward which might bring a broader adoption without leaving those who pioneered and developed the standard standing in the rain (all my subjective opinion). I was really surprised to see developers of the Matrix project participating in the discussion. That reminded me of what the spirit of floss software really is :)

I plan to spent the last days before the coding phase sketching out my projects structure and relaxing a little before the hard work begins. One of my goals is to plan ahead and I really hope to fulfill this goal.

Happy Hacking :)

Vanitasvitae

by vanitasvitae at May 26, 2017 19:12

May 24, 2017

Tigase Blog

Stateless XMPP: A competitive mobile experience.

With a bevy of new chat platforms available to consumers, it seems more and more that the emphasis of knowing who is online and what they are doing has fallen out of favor.

by Daniel at May 24, 2017 21:07

ProcessOne

Google Summer of Code hosts ejabberd projects

As you may know, our ejabberd XMPP server is written in Erlang. The Erlang VM was originally designed by Ericsson to support distributed, fault-tolerant, soft-real-time, non-stop applications. What you may not know is that ejabberd is part of the BEAM Community – a group of projects that run on the Erlang VM.

Since 2013, BEAM Community hosts relevant Erlang and Elixir projects, making it easier to participate in the Google Summer of Code (GSoC) (and similar initiatives), giving interested students a wide range of projects to choose from.

BEAM Community has been accepted again in 2017 as a GSoC mentoring organisation. This year, nine projects have been accepted:

  • For Lasp:
    • A Biparite Proposal for Lasp’s Lacking Documentation by Matt Wiese
    • Implementing a Real World Application in the Lasp Programming Language by goncalotomas
  • For Erlang:
    • ETS support for Erlang Lab by Kacper Mentel
  • For Elixir:
    • A code formatter for Elixir by alexjiao
    • Language Server Protocol implementation for Elixir by Nishith Kumar Shah
  • For Barrel:
    • Implementation of a RabbitMQ Plugin for BarrelDB by Tah Teche Tende
  • For Zotonic:
    • Port Zotonic Shell Scripts to Erlang EScript by Blaise M.
  • For ejabberd:
    • Ejabberd support for “let’s encrypt” ACME protocol by Konstantinos Kallas
    • Server-to-Server stream management support for ejabberd by Anna Mukharram

You can find more details about these projects here, but first lets look at the ejabberd projects.

Support for “let’s encrypt” ACME protocol

The Automatic Certificate Management Environment (ACME) protocol is a communications protocol for automating interactions between certificate authorities and their users’ web servers, allowing the automated deployment of public key infrastructure at very low cost. Supporting this protocol will reduce the complexity of acquiring certificates for TLS encryption, via the “Let’s encrypt” certificate authority.

The final goal of this project is for ejabberd to fully support the ACME protocol and thus provide an easy and cheap way of acquiring security certificates. This project is executed by Konstantinos Kallas, mentored by Evgeny Khramtsov from ProcessOne.

Server-to-Server stream management support

The goal of this project is to implement XEP-0198 for server-to-server communication in ejabberd. This extension allows to request stanza acknowledgement and quickly resume session. Any messages that were not delivered over previous connection will be retransmitted during session resumption without duplication. This project is executed by Anna Mukharram, mentored by Holger Weiß, an experienced ejabberd & XMPP developer.

Google Summer of Code

ProcessOne is committed to grow the interest of student developers in XMPP, ejabberd and real-time technologies. Through initiatives like the BEAM Community and GSoC involvement, we can have bigger and more positive impact, as well as bring valuable improvements to existing projects.

by Marek Foss at May 24, 2017 16:58

May 20, 2017

Paul Schaub

GSoC: Second, third week of community bonding

Hi all!

This is my report for the second, as well as the first half of the third week of GSoC community bonding, which I spent again working on finalizing my OMEMO code.

I dug deeper into writing test cases, mainly integration tests and I found quite a lot of small, undetectable bugs this way (Yay!). This strengthens my plan to work test driven during my GSoC project. The OMEMO code I currently work on was started as part of my bachelor thesis about 4 to 5 months ago and at this time, I was more concerned about having working code in the end, so I wrote no tests at all. Deploying test cases AFTER the code is already written is not only a tideous task, but its also often very difficult (because the code is not structured properly). So I learned my lesson the hard way :D

During testing I also found another bug in an XMPP server software, which prevents Smack from creating accounts on the server on the fly. Unfortunatelly this bug will not get fixed anymore for the version I use (installed from debian testing repository, which I thought was *reasonable* new), which keeps me from doing proper testing the way its meant to be done. I don’t have the time to compile the server software myselves. Instead, I work around this issue by creating the accounts manually everytime I run the test suite using a small bashscript.

I also had to deal with a really strange bug with file writing and reading. smack-omemo has a set of 4 integration tests, which all write data into a temporary directory. After each test, the directory is deleted to prevent tests influencing eachother. The issue was, that only the first test could read/write to the test directory. All subsequent tests failed for some reason. It took me a long time to notice, that there were two folders created (one in the working directory, another one in the subdirectory of the integration test framework). I am still not really sure what happened. The first folder was logged in all debug output, while files were written (by the first test) to the second filder. I guess it was caused by the temp directory being specified using a relative path, which messed up the tests, which were instanciated by the test framework using reflection. But I’m really not sure about this. Specifying the directory using an absolute path fixed the issue in the end.

Last but not least, me and Flow worked out some more details about my GSoC project (Implementing (encrypted) Jingle file transfer for Smack). The module will most likely be based upon java.nio to be scalable in the future. Flow also emphasized that the API should be as easy to use as possible, but at the same time powerful and extensible, which is a nice challenge (and probably a common one within the XMPP community). My initial plan was to create a XEP for OMEMO encrypted Jingle file transfer. We decided, that it would be of more value, to specify the XEP in a way, which allows arbitrary encryption techniques instead of being OMEMO exclusive.

Currently there is a little bit of tension in the community regarding the OMEMO specification. I really hope (and believe) there is a solution which is suitable of making everybody happy and I’m looking forward to participate in an open discussion :)

Happy hacking!

by vanitasvitae at May 20, 2017 21:56

May 19, 2017

Paweł Alameyo Ścibiorski (GSoC 2017)

#1 Starting with open source

Hello all

I introduced myself-earlier and maybe you are wondering what I have done since that time and before. I started with Spark by doing little changes with graphics interface bugs or improvements. Nothing really hard, sometimes even 1 line of code changes or new XML mapping for emojis, so with next release of Spark you will see emoticons like this for Unicode characters like this ☺. Nothing hard, yeah? But for me one of the first commits for the open source I have done since March when I started contributing.

 

So what I have been doing this week? Unfortunately I didn't fixed any issue with Spark, but started to developing own XMPP client. Don't worry, it's not going to be competitor for Spark but my hands on learning about Smack, the Java library for XMPP propelling Spark. It doesn't have even GUI, it is purely console/text based and doesn't have many futures yet. I also build for first time Openfire from source code. There are some guides how to do it with ant, however it's a bit outdated as Openfire now moved to Maven, and I didn't know how to build it. However with help from my great mentor Guus I have done it and it is totally easier than doing it with ant.

In case you are wondering: install maven > go with shell/cmd to Openfire directory and type "mvn clean package" and maven will build your project. Now go to target/bin directory and run openfire.bat.

 

For next week I plan to do some stuff with Java crypto libraries and Bouncy Castle, as it will be useful for certificate manager project.

Stay tuned,

Paweł

by Paweł Alameyo Ścibiorski (GSoC 2017) (igniterealtime@jiveon.com) at May 19, 2017 20:24

May 12, 2017

Daniel Pocock

Thank you to the OSCAL team

The welcome gift deserves its own blog post. If you want to know what is inside, I hope to see you at OSCAL'17.

by Daniel.Pocock at May 12, 2017 13:26

Kamailio World and FSFE team visit, Tirana arrival

This week I've been thrilled to be in Berlin for Kamailio World 2017, one of the highlights of the SIP, VoIP and telephony enthusiast's calendar. It is an event that reaches far beyond Kamailio and is well attended by leaders of many of the well known free software projects in this space.

HOMER 6 is coming

Alexandr Dubovikov gave me a sneak peek of the new version of the HOMER SIP capture framework for gathering, storing and analyzing messages in a SIP network.

exploring HOMER 6 with Alexandr Dubovikov at Kamailio World 2017

Visiting the FSFE team in Berlin

Having recently joined the FSFE's General Assembly as the fellowship representative, I've been keen to get to know more about the organization. My visit to the FSFE office involved a wide-ranging discussion with Erik Albers about the fellowship program and FSFE in general.

discussing the Fellowship program with Erik Albers

Steak and SDR night

After a hard day of SIP hacking and a long afternoon at Kamailio World's open bar, a developer needs a decent meal and something previously unseen to hack on. A group of us settled at Escados, Alexanderplatz where my SDR kit emerged from my bag and other Debian users found out how easy it is to apt install the packages, attach the dongle and explore the radio spectrum.

playing with SDR after dinner

Next stop OSCAL'17, Tirana

Having left Berlin, I'm now in Tirana, Albania where I'll give an SDR workshop and Free-RTC talk at OSCAL'17. The weather forecast is between 26 - 28 degrees celsius, the food is great and the weekend's schedule is full of interesting talks and workshops. The organizing team have already made me feel very welcome here, meeting me at the airport and leaving a very generous basket of gifts in my hotel room. OSCAL has emerged as a significant annual event in the free software world and if it's too late for you to come this year, don't miss it in 2018.

OSCAL'17 banner

by Daniel.Pocock at May 12, 2017 09:48