Agregador de noticias

Daniel Baczynski (GSoC 2015): Account and AccountsManager classes

Planet Jabber - 10 June, 2015 - 16:15
I have extracted some global-specific object instances out of MainController class. This way I started preparing MainController to be created for every account (we need to have multiple MainControllers and one Swift window).

We have now an Account and AccountsManager classes that control MainController instances (Account is passed for every MainController). Profile settings are loaded using current implementation of ProfileSettingsProvider and new options are set to default when loading a profile that has been created previously (backward compatibility). We can still log in into one account only but the aim was to prepare an appropriate design for multiple sessions.

I will test it more to find out potential problems and then it's time for login window GUI.

Daniel Baczynski (GSoC 2015): Coding started - plan for the summer

Planet Jabber - 10 June, 2015 - 15:53
Coding started this week. This is my sketch of a plan for multi account support project:

25 May
* weeks 1-2: Extract some global-type things out of MainController so they're not initialized with every account. Change interfaces/implementation of single-account oriented classes to prepare them to multi-account use (partially).

* weeks 3-5: Accounts list in login window. Ability to change colour of account, name, connection options, select default, write and remember password. Logging in into one account from list enabled – one instance of MainController.
26 June: Mid-term
* week 6: Expandable list in roster header but changing accounts inactive. Accounts colour bar in roster.
* week 7-9: Logging in to multiple accounts (many complications expected).
* week 10-11: Edit profile, add contact, enter room, start chat, run server command – able to select account before an action. Changing status for every account at once. 
* week 12: Chat window account identifying convenience implemented. Searching contacts.
17 August: Suggested “pencils down”
* week 13: Last adjustments.
28 August: The end

Adhish Singla (GSoC 2015): Week 2

Planet Jabber - 10 June, 2015 - 13:46
Objective Identifying Devices and Extending Client to all WebPages Abstract

ConverseJs is a Chat Client that uses XMPP standards. We need to extend its support to XEP-0323 and XEP-0325 standards, so that the client can distinguish between friends and devices.

Work
  • Extended Chat Client to all Pages.
  • Instantiated our own BOSH Server at ‘http://jabber.sust.se/xmpp-httpbind/’.
  • Made a Script that uses XEP-0323 and XEP-0325 to distinguish between devices by sending a Disco Query.
  • This is the Sequence Diagram for a Successful IoT-Sensor Data Request.
Road Ahead
  • Set up a Different Tab for Devices which can read and write values to it.
  • Creating IoT Device APIs for Devices like intel edison, intel galileo, raspberry PI 2, beagle bone black, etc.

Adhish Singla (GSoC 2015): Week 2

Planet Jabber - 10 June, 2015 - 13:46
Objective Identifying Devices and Extending Client to all WebPages Abstract

ConverseJs is a Chat Client that uses XMPP standards. We need to extend its support to XEP-0323 and XEP-0325 standards, so that the client can distinguish between friends and devices.

Work
  • Extended Chat Client to all Pages.
  • Instantiated our own BOSH Server at ‘http://jabber.sust.se/xmpp-httpbind/’.
  • Made a Script that uses XEP-0323 and XEP-0325 to distinguish between devices by sending a Disco Query.
  • This is the Sequence Diagram for a Successful IoT-Sensor Data Request.
Road Ahead
  • Set up a Different Tab for Devices which can read and write values to it.
  • Creating IoT Device APIs for Devices like intel edison, intel galileo, raspberry PI 2, beagle bone black, etc.

Andreas Straub (GSoC 2015): Week 02 - Sessions

Planet Jabber - 10 June, 2015 - 07:00
Hey everyone, and welcome back to this week's progress report!

Last week, I talked about design decisions regarding session trust. As a result of those considerations, I spent this week implementing session handling. As a reminder: In our approach, we need to maintain one session per remote device, as well as one session per own device. Within each of those sessions, we use the TextSecure-style "trust on first use" policy, so that sessions can be established easily. This means that, if we simply pass messages to these axolotl sessions, they will happily encrypt them, which we don't want. We want to only ever send out messages on sessions that the user has manually confirmed as trusted. So we need to keep track of which sessions have been marked as trusted.

Because we can't easily modify the libaxolotl-java data structures without patching the entire library, I wrote a session wrapper class that encapsulates libaxolotl-java sessions and provides higher-level interfaces to the rest of the code. Furthermore, I expanded on the AxolotlService implementation, which is the central entity that manages all axolotl-based communications for a given account. It now provides two primitives that handle all the behind-the-scenes machinations involved with sending/receiving messages. I also implemented a basic form of payload encryption using the axolotl-based key transport mechanism, although this is more of a mockup right now, in order to obtain testable working code. Lastly, I designed and implemented the core data structures that will be used internally to manage and pass around messages during the various stages of encryption and tackled a basic form of wire protocol XML generation. This stuff is still subject to change, so I will go into more detail on the wire protocol in a future post.

I am anticipating spending still more time on internals next week before getting a to a working basic state. Most notably, the wire protocol still needs some tweaking. Then I can get started with connecting the AxolotlService up to the rest of Conversations, and hopefully run some testing to figure out any architectural issues before I continue on with the implementation of actual multi-end to multi-end session handling. Stay tuned.

Peter Saint-Andre: RFCs 7572 and 7573: SIP-XMPP Messaging

Planet Jabber - 10 June, 2015 - 00:00
And the hits keep coming! Today two more of my RFCs were published through the Internet Engineering Task Force, defining how SIP and XMPP can interoperate for one-to-one messaging: RFC 7572 covers single messages (also called "pager-mode" messaging in the SIP world), whereas RFC 7573 covers one-to-one chat sessions (a.k.a. "session-mode" messaging). These documents continue in the series started with RFCs 7247 and 7248 and have been in the works since early 2008, if you can believe it. I hate to brag, but it shows how much I care about interoperability that I've kept pushing these specs forward all this time. :-) There are two more documents still to be published in this series: one on multi-party text chat rooms and the other on voice and video call signaling, so stay tuned for more RFCs in the relatively near future...

Tarun Gupta (GSoC 2015): Week 2 & 3

Planet Jabber - 9 June, 2015 - 17:02
So Far ...
Hello everyone. Two weeks have gone past start of coding period. It has been quite a nice week with some coding and testing!
As far as progress is concerned, I have implemented all of the avatar functionalities for Stroke, but there are some minor bugs which needs to be fixed for proper implementation. And therefore some tests are still being implemented. I have started implementing different elements, their parsers and serializers, and have implemented some, including VCard Element, Bytestreams Element. Although a large amount of Elements are yet to be implemented, I will try to finish off with these by the end of this week.
I had some problems in implementing Avatars, so I have put them up for review on Gerrit. So just waiting for feedback on them so that I can squash bugs and yeah, still waiting for older commits to be reviewed and merged finally!

Adhish Singla (GSoC 2015): Week 1

Planet Jabber - 6 June, 2015 - 07:12
Objective Create an Interactive user interface for Web Visualisation Client Abstract

For the devices to interact with our website we need a chat client that uses XMPP Protocol.

Work Road Ahead
  • Extend Chat Client to all Pages.
  • Instantiate our own BOSH Server.
  • Differentiate between Friends and Devices.

Adhish Singla (GSoC 2015): Week 1

Planet Jabber - 6 June, 2015 - 07:12
Objective Create an Interactive user interface for Web Visualisation Client Abstract

For the devices to interact with our website we need a chat client that uses XMPP Protocol.

Work Road Ahead
  • Extend Chat Client to all Pages.
  • Instantiate our own BOSH Server.
  • Differentiate between Friends and Devices.

Marvin Wißfeld (GSoC 2015): GSoC 2015 started - DNSSEC for the Java world

Planet Jabber - 3 June, 2015 - 00:00

May 25, 2015, a day most do not realize to be special. In some european countries, people will remember the date as a holiday. For 1,051 students from 73 countries it’s the official starting shot for a 13 week period to produce awesome, new, open-source software as part of the Google Summer of Code.

I am happy to be able to say, that I was accepted to participate at Google Summer of Code for the XMPP Standards Foundation. Beginning May 25, I will add full DNSSEC support to the Java DNS client library minidns, which will then be used by leading open source libraries and tools including smack and OpenKeychain.

What happened?

Wait. You just realized that May 25 is already one and a half way ago? True thing. And there is already nice progress to report

  • minidns is now able to parse DNSKEY, RRSIG, NSEC and DS resource records from the wire (see RFC 4034 for details).
  • As DNSSEC records might contain longer keys and signatures, they do not fit into classic 512 byte DNS packets. I thus added “support” for EDNS (and the OPT resource record), which is able to handle any size of UDP packets the network supports (which is usually about 1500 byte).
  • Unfortunately, 1500 byte UDP packets are not even enough for all use-cases. And it’s worth to note that some firewalls restrict the DNS packet size, which renders EDNS useless. I thus also added support for DNS over TCP, which allows arbitrary packet size and should work on every network.
What will happen?

When a Google Summer of Code project starts, people are often curious of what they can expect as a result. Of course a full featured DNSSEC resolver, including recursive resolving abilities is in the offing, but that’s not all.

minidns, as the name suggests, is a very light-weight DNS library. Cross-platform compatibility (including support for Android) is also one of its main features. Adding DNSSEC support should not touch these features.

And, as this project adds a security-relevant feature, it will also bring-in a full featured test suite to ensure correctness. This will not only ensure that everything is awesome inside the DNSSEC implementation, but will also be valueable for the complete minidns library.

buddycloud: In-app messaging: Evolving APIs to ProtocolsBuddycloud took part...

Planet Jabber - 2 June, 2015 - 14:56


In-app messaging: Evolving APIs to Protocols

Buddycloud took part of Kamailio World Conference 2015, sharing what’s new and exciting in the real time communications. You can now watch Buddycloud’s talk on APIs and Protocols here: https://www.youtube.com/watch?v=LyZq8jZaJ7U or the open discussion panel moderated by Randy Resnick, Founder VoIP Users Conference: https://www.youtube.com/watch?v=hlPxBnCaXg0.

Thank you Daniel and the rest of the Kamailio World team for organizing everything! We had a great time at the event and look forward to joining again next year. 

Peter Saint-Andre: The Art of the Fugue

Planet Jabber - 2 June, 2015 - 00:00
Ever since I discovered Bach's Art of the Fugue thirty years ago, I have turned to this piece of music for solace when I am in a state of agitation. Finding myself there again this evening, I decided to pay homage to the greatest of composers with this brief pantoum...

Andreas Straub (GSoC 2015): Week 01 - Plumbing

Planet Jabber - 1 June, 2015 - 21:52
Welcome to the development blog for my GSoC 2015 project on implementing axolotl-based multi-end to multi-end encryption in the Android XMPP client Conversations. Here, I will be posting regular progress updates and discussing some of the design choices I am making as the project goes along. So let's jump right in.
This week was mostly spent laying the groundwork for things to come. In order to use libaxolotl-java, one has to implement key- and session persistence layers in the form of four different interfaces. This is mostly straightforward CRUD-type stuff, but there are some subtleties in what data is accessible through these interfaces, and what behavior is expected of their implementations by the surrounding library code. So I spent some time reading through the library code to understand better how my code would fit in the bigger picture.
Coming from the TextSecure world, the library encourages a "trust on first use" model for establishing public key trust. This means that a contact is considered trusted either if their presented key matches the one locally associated with that account, or if there is no key associated locally with the contact. While tenable for one-on-one sessions, this model would lead to big problems in our proposed multi-end to multi-end model. Implementing it this way would effectively allow attackers to eavesdrop on all communications of a particular user without it being immediately obvious to them. (For more information, stay tuned for a future post detailing our proposed protocol)
So there are two options here:
A) either implement the IdentityKeyStore in a way that exposes trust decisions to the user, breaking with the convention proposed by the library, or
B) internally, keep the "trust on first use" policy for the IdentityKeyStore implementation, but externalize actual trust decisions by tagging the Session objects, that wrap connections, as trusted or not
The big drawback of A) is that it introduces the need for a lot of caching. We would have to keep track of received messages until the user has made a trust decision (via a popup, like is done for OTR right now, or a similar mechanism). I discussed this with my mentor and we came to the conclusion that B) is the way to go. That way, we can just let the library establish a session like normal, but externally, tag it as untrusted. Then we can decrypt messages received in that session, and don't need to cache them. As long as the session is untrusted, these messages will be marked in some really obvious way as untrusted in the UI. As soon as the user validates the key, these markers can simply be removed. Of course, we also need to ensure we don't use untrusted sessions to send data,because the library itself won't warn us that the contact is untrusted.

Up next is getting a basic implementation (without PreKey negotiation for now) working so that we can start testing in a real setup.

ProcessOne: Writing web apps for Google Chrome using Boxcar Push Services

Planet Jabber - 1 June, 2015 - 15:49

With the recent announcement of push notification support on Google Chrome for Android a new horizon of web applications is emerging. Even if both push and notification drafts are still going through continuous changes, we have published a beta version of our Boxcar SDK for Google Chrome browsers. Read the full post at our Boxcar Developer Blog.

Tarun Gupta (GSoC 2015): GSoC 2015

Planet Jabber - 28 May, 2015 - 14:12
Extend Stroke Implementation
Hello everyone. I am Tarun Gupta, a sophomore year student at IIIT-Hyderabad, India. I have been selected for GSoC 2015 for XMPP Standards Foundation. Please bear with me as this is my first ever blog entry as well as my first Summer of Code. 
This year XMPP has 6 projects going on under Google Summer of Code, out of which mine deals with extending the implementation of Stroke. Stroke is a java port of the Swiften(C++) XMPP library. The Extensible Messaging and Presence Protocol is an open technology for real-time communication, using the Extensible Markup Language (XML) as the base format for exchanging information. It has a wide variety of applications which you can find here.
As the coding period has already started, I would like to show my progress over here. I have started with the base functionalities and have implemented two functionalities including processing of URL's and UUID Generation. But, as my mentor suggested, I will be taking a detour and implementing Avatar functionalities first.

A quite exciting summer coming and I am very excited towards this project, as I have an opportunity to implement a whole network protocol and getting a deep insight into what goes behind.

Alexander Gnauck: MatriX JS XMPP library in beta now

Planet Jabber - 26 May, 2015 - 17:51

We are pleased to announce our new JavaScript XMPP library MatriX JS which is available for beta now.

MatriX JS is build with Microsoft’s TypeScript. The software design is very similar to our popular MatriX .NET XMPP SDK. TypeScript allowed us to port lots of existing source code, logic and patterns from our MatriX C# library to JavaScript. MatriX JS is also based on LinQ and LinQ to XML. This will make it very easy for our existing customers to port existing code bases to the web or cross platform HTML/JS applications.

Currently BOSH and websockets are supported as transport layers. Node.js and tcp sockets are coming later.

MatriX JS will be licensed under a Creative Commons Attribution-NonCommercial 4.0 International (CC BY-NC 4.0) license.

Contact us to join the MatriX JS beta

The XMPP Standards Foundation: Eyeball Networks become an XSF Sponsor

Planet Jabber - 26 May, 2015 - 13:38

We’re happy to announce that Eyeball Networks are the latest organisation to become an XSF Sponsor.

Eyeball Networks pioneered the STUN/TURN/ICE device-to-device connection technologies adopted by communications standards including SIP, XMPP, IMS, PacketCable, IBM Sametime, Microsoft Lync, and now WebRTC. You can read more about them here.

Sponsors are vital to the ability of the XSF to continue to fulfil its mission to build an open, secure, feature-rich, decentralized infrastructure for real-time communication and collaboration over the Internet.

Our sponsors help us with everything from infrastructure for the XMPP site to funding the regular XMPP Summits so please take the time to thanks Eyeball Networks by visiting their website, getting them involved in discussions and perhaps following them on your social network of choice (from LinkedIn, Facebook, Twitter and Google+).

 

ProcessOne: Code as Craft Interview #1 – CoBrowser.net

Planet Jabber - 26 May, 2015 - 09:12

I had a quick chat of Fernando Ripoll (left) and Alex Knol (middle) from Cobrowser.net at Sea Beyond conference.

Cobrowser is a proactive web based chat solution build using ejabberd.

Distribuir contenido