<stream:stream to='jabber.org' version='1.0' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams'>

However, RFC 6120 states that client implementations only MAY declare such a default namespace. Implementations are also free to open the stream without declaring xmlns='jabber:client', and instead declare xmlns='jabber:client' on every child element. This is semantically equivalent, and is a MUST requirement of RFC 6120.

It would be nice if Isode/jabber.org could update its software to conform with this part of the standard.

Also, the XML for errors generated for namespace errors is broken. If we send <stream version="1.0" to="jabber.org" xmlns="http://etherx.jabber.org/streams">, the server will return with a stream error element and a closing stream tag that are not preceded by an opening stream tag:

<stream:error><bad-format xmlns='urn:ietf:params:xml:ns:xmpp-streams'/></stream:error></stream:stream>.

(On a side note, jabber.org/M-Link does not include a language tag in its stream element, which is a MUST requirement of RFC 6120.)

My FSCONS 2012 presentation slides can be found here.

Thanks everyone for a wonderful conference, great presentations, and interesting discussions!

A Yabasta identity is automatically generated upon visiting the site, and can be verified (authenticated) using three different methods: Asking a question to the contact, verifying a shared secret, or simply verifying the fingerprint of the (public key of the) contact.

Three icons are used to represented the security status of contacts:  (incompatible client or key exchange error), (key properly exchanged, but the identity is not verified; conversations will be end-to-end encrypted), and (the identity of the contact is verified).

You can see the prototype in action at Yabasta.com.

This release is the fifth and last of the series of week-long sprints that I have been working on full time since the end of September. The development of Yabasta will continue, but will do so at a slower pace since I will have to attend to other matters as well.

Looking forward, the Yabasta code is going to be reviewed, cleaned-up, partly rewritten, and have some final minor features added before the project will enter beta. So stay tuned!

PS. If anyone reading this is attending FSCONS in Gothenburg next week, I’m going to be talking about Yabasta on Sunday at 16:15. DS.

Colours, shapes, and fonts has been updated on Yabasta.com to make it look a little bit prettier. I’m not a designer, but it’s something for the time-being.

Also, Frederik Strömberg has designed a Yabasta logotype:

The idea was to let Yabasta be symbolized by a sun, since Yabasta is the opposite of cloud computing in many regards. As an initial typographic suggestion, we went with the Cantarell font with a simple Inkscape stroke border.

Just like with the software, the graphics are drafts, and are subject to change in future iterations of Yabasta. One problem with the sun logo is that it’s a little complex, and doesn’t look very good when it’s scaled down to a small icon (such as a smartphone application launch icon, or a “favicon” image).

Anyway… That’s it for this week. As always, suggestions or contributions are welcome.

To create an account, feel free to visit Yabasta.com.

Also, if you want, you may also add me (Yabasta user name: “jon”) to your contacts.

I started out with a set of protocol requirements:

• End-to-end security: The protocol must not allow an intermediate entity to read or manipulate communication between end-users. Any communication shall be secure in terms of confidentiality (not understandable to external entities), integrity (any alterations must be detected by the system), and replay protection (copies of previous communications must be identified by the system).
• Usability: The protocol must allow (or even encourage) implementing systems to be intuitive and easy to use. The necessary configuration for end-users should be minimal. Any password credentials needs to be easy to remember. Connections needs to be firewall-friendly.
• Trust: The protocol must allow end-users to establish trust in each others credentials, such as (self-signed) certificates, a shared secrets, or pre-shared keys. Note that the protocol must not require a trust model that is external to the users, such as a Certificate Authority or a web-of-trust.
• Uncentralization: The protocol must allow end-users to be spread out over a federation of servers. Malicious servers must not be able to cause harm to the rest of the network.
• Perfect forward secrecy: The protocol must prohibit any previous communications be revealed if any of the long-lived (private) keys are compromised. It must also be possible to periodically change the decryption (public) keys.
• Forgeability: The protocol must not allow any recipient of communication to prove who produced or sent the message, or that the message has not been faked or altered.
• Upgradeability: The protocol must signal its current version so that new versions of the protocol can be developed. Also, the protocol must be flexible in terms of what algorithms it supports.
• Identity protection: The protocol authentication credentials should not be related to a name, address, or any other information that can be used to link a credential a specific person.
• Extendability: The protocol must allow the data payloads to be arbitrarily extendable in order to allow Yabasta (and compatible software) to expand into other areas later.
• Efficiency: The protocol must perform well in constrained environments (such as smartphones and web browsers).

I have published a first draft of the protocol, which is basically the beginning of a “Jabberization” of the Off-the-Record protocol. I hope that this can be a starting point for discussions about the future protocol of Yabasta. The draft protocol is indeed “quick and dirty”. While it adds somewhat of a possibility to negotiate the Diffie-Hellman primes, it does assume SHA hashing, AES-128-CTR, etc., and is thus not really as extendable or flexible as I would have liked it to be. My current priority, however, is to get Yabasta up and running quickly.

I will now start to focus on making Yabasta.com an actual XMPP client.

The release is simply a prototype, and its main contributions are to help gather feedback on the usability of the user interface, as well as to aid in further web browser compatibility and visual design efforts.

The main artifact of this release, Yabasta Web, is a simple HTML5/jQuery user interface application. The other artifact released today, Yabasta Core: ECMAScript, is a dummy component that only simulates the future Yabasta “logic” component (which is scheduled to be implemented for version Alpha 1). Both of these components are available through the main Yabasta GitHub project.

The next release will consist of a draft of the protocol (the XMPP extensions) that will serve as the foundation for the future end-to-end cryptography of Yabasta. I’m also working on the JavaScript cryptographic implementation, making Yabasta Core: ECMAScript an actual XMPP client, as well as putting together a good-looking visual design for the application. The Alpha 1 version, scheduled for November, will deliver a working, yet basic, messaging application.

For more information about Yabasta and this release, please visit Yabasta.com.

Also, as I’m working on Yabasta on my free time, donations are more than welcome.