Tag Archives: XMPP

feeds

Jérôme Poisson: Shell: pipe you commands out via XMPP with SàT

2011/10/07 – 14:28

G'day all,

just a short notice to show a feature i'm currently implementing, the hability to pipe out a command line stream via XMMP, using jp, the command line frontend of the "Salut à Toi" project.

The syntax is quite easy: imagine you have 2 people Pierre and Louise talking together. Louise is talking about the last Blender Foundation movie, Sintel, and Pierre is interested, and want to see the trailer Louise is talking about. To do that, he just has to enter the following command:

jp --pipe-in louise | mplayer -


Which mean "I'm waiting for an incoming stream from louise". Louise correspond to the name Pierre gave to its contact louise@example.org, jp do the association.
He could also have used the full jid instead: louise@example.org/Noumea .

In the other side, Louise can pipe out the trailer to Pierre with the following command:

cat sintel_trailer-480p.ogv | jp --pipe-out pierre

Quite easy isn't it ? You don't have to worry about the IP address of your contact, just to know its jid, or to have it in your roster with an easy-to remember name.

Note that jp was already allowing you to pipe out command line result as a XMPP message (to do some ascii art for example ;) ).

If you want to copy a file, the syntax is quite similar:

jp -wg louise

for reception and:

jp -g sintel_trailer-480p.ogv pierre

to send the file. The -g flag means you want to see the progress bar.

The following short video show this in action. It's in french, but you don't really need the comments to understand it.


To play the video, you nead a recent browser (e.g. Firefox 4+ or the last Chromium).
You can also use VLC (>=1.1 only), by using this url as a flux: http://www.goffi.org/videos/pr%c3%a9sentation_S%c3%a0T_4_copie_et_pipe.webm

Last but not least, you can use mplayer: mplayer "http://www.goffi.org/videos/pr%c3%a9sentation_S%c3%a0T_4_copie_et_pipe.webm"

This video is licensed under Creative Common BY-SA
Your browser doesn't manage the « video » tag, you should update, e.g. with the last Firefox

For the technical side, it's just a modified XEP-0096 . It would be intersting to propose this as a standard to the XSF, but maybe by using jingle transfer instead.

Please not that all of this is really experimental.

I plan to release the next version of "Salut à Toi" soon, stay connected :)

Tags , , , , , , | Permalink | Comments Off
feeds

Jean-Louis Seguineau: Addresses are for routing

2011/09/26 – 00:42

I was reminded by a reader's comment that address handles are still given properties beyond their only designed role: addresses are for routing. That is, routing only. Any attempts at loading an address handle with an additional meaning is only creating confusion. Address handles are not identity tokens. Address handles must not provide application logic. This bad practice is the best way to create lock-ins and decrease applications' scalability and extensibility. An address handle must be used in a single context: to indicate the destination of a communication.

This foreword done, the comment originated from the need for proper conversion rules when translating addresses from a communication space into another. The example was taken from the current XMPP transport practices, where the non-XMPP address handles are encoded as the node part of a JID. I believe this practice is wrong and does not possess any good technical grounding.

In an XMPP addressing space, a component such as a transport will have a JID comprised of a domain part only. Let's say "transport.montague.net". If a user on the XMPP side of the transport has contacts in the legacy side, the common practice is to apply an encoding logic on the legacy address to build the node part of a JID representing that contact in the XMPP world. The result might look like "juliet%capulet_it@transport.montague.net". The issue with this conversion lies in the resulting urge by many developers to use this "logical" encoding of the node to derive a meaning in a client for example. If the contact JID had been "a2ff356@"transport.montague.net" the programmer would never had used the node for anything but its role. The opaque node keeps all the routing properties of an good address handle, which in this case requires that a stanza using this JID be routed to the "transport.montague.net" service. It is also easy to see that this approach is completely independent of the target legacy system.

Introducing a logic in the node encoding of early transports has

  • induced developers to reverse this logic inside their code, creating a de-facto legacy inside the XMPP clients and transports implementation,
  • imposed at a time different encodings because the target legacy systems have different addressing spaces syntax.

Lastly, I believe there is no good reason to use a logical encoding of the JID's node for legacy contacts. Finding the contact's address can be achieved by looking-up the opaque node value in a cached table to obtain the legacy address. In terms of performances, I believe the time difference between a lookup and a decoding does not count much when compared to the actual transport wire transmission overhead.

Technorati Tags: , , , ,
Tags , , , , | Permalink | Comments Off
feeds

Remko Tronçon: Experimental File Transfer support hits Swift

2011/09/25 – 18:55

It’s been a busy summer for Tobias Markmann, one of the XMPP Standards Foundation’s 2011 Google Summer of Code students. He has been working on implementing File Transfer support for Swift, using the fresh Jingle XMPP protocols. I’m happy to announce that we integrated Tobias’s work as an experimental feature into the main Swift branch, where it will be further developed and brushed off before being enabled in our nightly builds and releases.

For those interested in the nitty gritty protocol details: file transfers are negotiated through the Jingle File Transfer protocol (XEP-0234), using SOCKS5 (XEP-0260) as the main transport, and In-Band Bytestreams (XEP-0261) as fallback. To improve connectivity, we use both the NAT Port Mapping Protocol and the UPnP Internet Gateway Device protocols to allow connections through most firewalls, and SOCKS5 relaying proxies in case all else fails.

The new feature has been tested for interoperability against (slightly modified) development versions of both Pidgin and Gajim, which, together with the Pidgin-based Adium, cover a large XMPP user base. After both clients update their protocols to track the newly published Draft specification versions, all 3 should be able to exchange files seamlessly.

What still remains to be done is lots of testing (both internal testing, user testing, reliability testing, and interop testing), bugfixing, and some refactoring here and there to clean up some of the code (which already is in very good shape). Our end goal is to reach a rock solid implementation, with a near guarantee that file exchange will always work (which experience teaches us is far from trivial).

To conclude, we’ld like to thank Tobias for contributing this great new feature to Swift, for providing valuable protocol feedback to the XSF, and for laying the foundation to other exciting Jingle-based features (including voice/video conferencing).

Tags , , , , , , | Permalink | Comments Off
feeds

Jean-Louis Seguineau: Usable interoperability

2011/09/25 – 00:45

The IEEE directory describes inter-operability as

The ability of two or more systems or components to exchange information and to use the information that has been exchanged.

Well, if we take that definition into the human communication space, we could say that speech allow a good level of “protocol” level inter-operability. When we add the knowledge of a language, then we can exchange and hopefully make use of well-formatted (syntax) and meaningful (semantics) messages. What is in my opinion a little flawed in the IEEE definition is the part about usage of the received information. I believe inter-operability does not have a meaning outside the scope of a particular application domain.

In my previous post, I stated why I do not find great interest in the SIMPLE/XMPP “inter-operability” draft proposal. To re-enforce my previous position, I would say the draft describes proper messages syntax, even a beginning of shared semantic between the two protocols, but completely fail to put the inter-operability in context. Without the intimate knowledge of a shared human language, one can receive the perfectly valid speech flow without being able to use it. A bit similar to listening an opera where a Spanish tenor and an Italian diva sing in Russian. They exchange perfect syntax and semantic but with a limited use, mainly providing marks for the other to respond. Don’t you think we may be missing, like the spectator of the opera, a great part of the meaning?

Technorati Tags: , , , , ,
Tags , , , , | Permalink | Comments Off
feeds

Jean-Louis Seguineau: Unnecessary "interoperability" drafting

2011/09/25 – 00:45

After some time out of the communication realm, I will comment on the presentation of an Internet-Draft that defines how to enable basic interoperability between SIP/SIMPLE and XMPP.

It is funny how interoperability and federation between different communication media is always reduced to "mapping". This is once again exemplified by the draft proposal trying to explain how to achieve this hypothetical interoperability. From the architectural assumption, we already get the feeling this is too good to be true. Being amongst the very few people having implemented a federation between these two protocols, and probably the only one having designed a native SIMPLE connectivity on an XMPP server, I can tell you this is slightly more complex than the draft describe…

The draft goes to great length to describe how to convert between a SIP URI and an XMPP JID. This is an excellent and accurate work, and its undisputable merit lies in providing in one single document a thorough description of each address' syntax. But in real life, what are the chances for the addresses in these two communication spaces to require direct translation?. Not very high. Why would the syntactical similarity between a SIP URI and an XMPP JID provide a guarantee that the same address must be used? After all, we do not translate JIDs directly to email addresses, nor SIP URIs either. We do not translate AIM screen names to SIP URIs, nor to JIDs. In the real world, we perform a lookup of one communication space's address in the other... We use directories to achieve the "mapping", rarely direct translation. The only case where this would be used is when SIP/SIMPLE user agents connect directly to an XMPP server, which is somewhat uncommon.

Where the draft is not up to the task is when trying to map the long term presence subscriptions of XMPP with the short term subscription of SIP. It is all fine when there are no existing subscriptions form either side. In this case, translating an XMPP subscription into a SIP SUBSCRIBE would provide the desired effect. But only the first time. The next time, the permanent XMPP subscription will trigger a presence stanza, instead of a subscription stanza. Nothing in the draft addresses how to handle this difference. In SIP we have a well delimited publish-subscribe behaviour. In XMPP we have a variable context behavior: before and after subscription.

The draft indicates that the XMPP subscription could be terminated by the SIP subscription. But this is not realistic. From an XMPP user's stand point this would mean re-subscribing to the contact on every login. And further on, this would force the XMPP user to accept a SIP contact's subscription for every contact’s log in.

Working the other way round is easier, as it is always possible to translate a SIP SUBSCRIBE into an XMPP subscription. If no subscription exists for the SIP contact, the subscription stanza will be sent to the XMPP user's client if and only if the user is online. If the user is offline, the subscription will be stored by the XMPP server, awaiting the user's acceptance. So the gateway will have to deal with this case, which is not described in the draft. Similarly, the draft does not handle the case where the XMPP user refuses the SIP contact's subscription. In SIP, if a subscription is refused it translate into an error response. The gateway would have to be aware of the presence state of the XMPP user to take the right decision. This asynchronous handling does not easily "map" with the request/response nature of SIP. Following the proposed scenario, the gateway would have to maintain a copy of every user's presence. This is both inefficient and non scalable. And again not very realistic.

As said above, SIP presence is based on short lived publish-subscribe, initiated by the requesting user agent. This is the opposite of XMPP, where the server acts as a proxy for the client user agent. SIP relies on expiration to cancel subscriptions. XMPP sessions do not time out. SIP is connectionless, whereas XMPP relies on the client connection state to deduce the end of a client session. All these fundamental differences are not highlighted in the draft, and as a consequence the cases described are both superficial and incomplete.

In the end, I find no real value in issuing a document whose only real complete description is in highlighting the difference between XMPP and SIP address handles representations. It is also detrimental to reduce interoperability between the two protocols as a simple translation between message types. None of the real issues of application interoperability are addressed in this document which looses all its substance, and by consequence its necessity. Beyond having “the longest title in IETF history” I believe this draft would be better off retracted. This energy might have a better result applied to the Jingle specification…

Technorati Tags: , , , , , ,
Tags , , , , | Permalink | Comments Off
feeds

Peter Saint-Andre (Jabber): Drafty

2011/09/23 – 12:43

Today I submitted updated versions of two XMPP-related Internet-Drafts:

One of these days I'll update the Jabber-ID email header spec, too. (I'm not sure whether it's worth moving forward with draft-saintandre-xmpp-pidf...)

Tags , , , , | Permalink | Comments Off
feeds

Peter Saint-Andre (Jabber): Interworking

2011/09/21 – 00:42

As the joke goes among protocol geeks, the great thing about technology standards is that there are so many choose from. That's true in the instant messaging and presence space, where we have both SIMPLE and XMPP. For the last 18 months or so, I've been working here and there on an Internet-Draft that defines how to enable basic interoperability between these two technologies. The document (which has perhaps the longest title in IETF history) can be found here (HTML) and here (TXT). Two weeks ago I issued an unofficial last call for feedback regarding this spec on the SIMPLE and XMPP discussion lists. After IETF 66 I plan to request a standards action regarding this spec, so send in your feedback soon!

Tags , , , , | Permalink | Comments Off
feeds

Peter Saint-Andre (Jabber): XMPP URIs Again

2011/09/20 – 12:43

Over at Educause, Stuart Yeates from the University of Oxford wonders about the state of standardization regarding XMPP URIs:

In an ideal world, of course, the Jabber/XMPP community would get their act into gear and finish standardising already so we could make direct reference to the xmpp: URI scheme.

Well, Stuart, the IESG approved of draft-saintandre-xmpp-iri-04 back on May 8th. However, the IETF wheels can move slowly sometimes -- especially since that Internet-Draft is an individual submission, so there's no guarantee that the RFC Editor will formally publish it as an RFC any time soon (working group submissions take priority). But the document is in the RFC Editor queue so it's only a matter of time at this point, and IMHO it's quite safe to start using XMPP URIs. If you have any questions, feel free to ping me via Jabber. :-)

Tags , , , , | Permalink | Comments Off
feeds

XMPP Glossary

2011/09/16 – 17:28

Roster, JID, full JID or bare JID, BOSH, caps, component, C2S and S2S, MUC, federation, dialback, PubSub, service discovery, resource, priority, transport, stanza, IQ, spim, ICE/STUN/TURN, presence, Jingle, and... Jabber. Maybe most of all these terms mean something to you. But some may not have a meaning in the XMPP context, or some just do not mean anything.

We have put up a small glossary for you. It is in our wiki. Please check it out here: : https://support.process-one.net/doc/display/XMPP/XMPP+glossary You don't need an account to read our wiki.

If you find that a definition is lacking, if you find an error, or if you simply want to extend it, please feel free: you are highly encouraged to contribute.

Tags , , , , , , | Permalink | Comments Off
feeds

ProcessOne: Details on MSN’s XMPP server

2011/09/16 – 08:38

Mickaël posted yesterday On MSN / Live Messenger adopting XMPP. Today, we'll dig a little more in technical details.

Here are some technical details and some explainations, as well as some questions.

Microsoft's public XMPP server

Microsoft's public XMPP server is located at: xmpp:messenger.live.com. You can double check on IMtrends:
http://www.imtrends.com/do/search_domain_simple?domain=messenger.live.com&x=19&y=7

Microsoft had been testing xmpp:beta.xmpp.messenger.live.com since a few months, but now it is redirecting to xmpp:messenger.live.com.

New server?

IMtrends test results say:

Software IMTrends couldn't determine the server running behind messenger.live.com. This makes sense, since it may be a completely new server.

C2S, but no S2S

C2S stands for client-to-server and S2S stands for server-to-server, which are meaningfull: these describe the connections between clients and servers.

On this matter, IMtrends says:
OK:

DNS Client-To-Server record Client-To-Server Stream Not OK: DNS Server-To-Server record Server-To-Server Stream

What does this mean?

This means:

XMPP clients may be able to connect to this XMPP service XMPP servers are not allowed to connect to this XMPP server: Microsoft's XMPP server does not federate with Google's, like Facebook's. As a consequence, we still need gateways ("transports") to MSN service, with MSNP or XMPP protocols, in order to aggregate MSN contacts in an XMPP client.

Questions:

Will Microsoft's XMPP server federate with Google's and the rest of the world? Microsoft has invested in Facebook: will Facebook's XMPP server federate with Microsoft's, Google's and the rest of the world? Microsoft has bought Skype: will Skype (which already offers XMPP on their client) offer an XMPP server? Will it federate?

JID, Jabber ID, XMPP addresses

Justin Karneges, of Psi and Livefyre fame, brought our attention to JID and authentication.

JIDs are in the form: [identifier]@messenger.live.com.

Which means:

Users will have long JIDs, instead of the short [username]@live.com: it would have been simpler to provide the JID as the email address, like it is the case on Gmail/Gtalk and TextOne I hope [identifier] is the username, or something human-readable...

Authentication mechanism

The client-to-server authentication used is SASL, with a specific and proprietary mechanism called X_MESSENGER_OAUTH2. According to Thijs Alkemade (Adium), it is documented, and "extremely similar to Facebook's OAuth2 mechanism".

Which means that all current XMPP clients are NOT able to connect to messenger.live.com. This new authentication schema will need to be developed and tested.

TLS is required, good point.

Summary

Here is a small summary:

Microsoft only offers a client interface to their MSN chat, much like Facebook: they both keep their internal and proprietary chat system Current standard XMPP clients can not connect to Microsoft's XMPP server, since it has a specific and proprietary authentication schema, unlike Facebook Microsoft's XMPP server does not talk to any public and federated XMPP server.

Perspective

This is a big step, and quite a surprise at internet scale (even if some were aware of their beta server). Indeed Microsoft has defended over time their proprietary protocol MSNP (and its mobile version) by changing small bits of their protocol in order to prevent third party clients to connect to their service. A big step, but still a long way to go until full interop and federation with the full XMPP network, including Gtalk, Facebook, and Skype (soon AIM?). ICQ, Yahoo! and QQ are still lagging behind.

Now, given Microsoft's habits to cheat on interop, and "embrace and extend" the open standards, it is needed, not only to run deeper and more strict and exhaustive interop tests, but also run ACID-like tests over XMPP.

Tags , , , , , | Permalink | Comments Off
feeds

On MSN / Live Messenger adopting XMPP

2011/09/14 – 20:46

During Microsoft BUILD conference, the company announced they are now enabling an XMPP interface to connect to their MSN / Live network: Messenger Connect is now “Live Connect” – new APIs for SkyDrive and Hotmail Calendar. More details expected on: dev.live.com.

Long ago, we (at ProcessOne) helped reverse engineer the MSN protocol (mostly newer parts) and had build a gateway from XMPP to MSN for ejabberd.

One of our large deployments was trying to have us discuss together to find a technical official agreement with this large customer.

Microsoft refused to have me joined the call. They said ProcessOne was a bunch of hackers, breaking into their network.

Today, I enjoy the irony as the millions of XMPP users around the world will all be welcome into Microsoft network with their third parties clients. We are all hacking into Microsoft network !

Seeing an open protocol win over the closed world is rewarding and enjoyable moment.

We still have many battles to win:

mobile group messaging, with interop federation (TextOne) against the fragmentation (BBM, iMessage, Huddle, and tens of others): See: Is iMessage evil OpenPush: change the way we see notification. See: http://www.openpush.im

Let's keep on changing the world together !

Note: Crossposted and improved from my Google+ entry.

Tags , , , , , , | Permalink | Comments Off
feeds

Microsoft Adds XMPP Support to Windows Live APIs

2011/09/14 – 18:47

Microsoft has announced that it is adding support for XMPP to its Windows Live APIs, enabling any application or IM network to interoperate with Windows Live Messenger. Details are available at liveside.net and dev.live.com.

Tags , , , , , , | Permalink | Comments Off
feeds

Serving on the Board or Council

2011/09/14 – 03:45

Each year the members of the XSF choose new people to provide technical leadership on the XMPP Council and business leadership on the XSF Board of Directors. These roles typically require only a few hours a week over the one-year term, and are a great way to get involved in the XMPP community. If you’re interested in volunteering or know someone else who might be, visit the wiki page or ask one of the current Board or Council members for insights.

Tags , , , , , , , | Permalink | Comments Off
feeds

Online demonstration of the ejabberd Web Interface

2011/08/10 – 00:42

As of today you can not only see screenshots of ejabberd's web interface, but also online demo's of ejabberd's web interface. They are read-only and will give you a good idea of how the web interface works and looks like. Remark that the CSS style sheet in ejabberd 0.9.8 is standards compliant. And that's not all!

Last week, a patch for ejabberd's web interface was made to achieve full compliancy with W3C specs. This will make from ejabberd the first Jabber/XMPP server with a standards compliant web interface! As you can see there is not only dedication to good Jabber/XMPP protocol support within the ejabberd project.

Tags , , , , | Permalink | Comments Off
feeds

Mark Doliner: Tool to View DNS SRV Records for XMPP

2011/08/04 – 08:49

I wrote a crummy tool that displays the current DNS SRV records for a given XMPP domain. After writing it I discovered that Olark has already created something similar.

My tool attempts to do some really basic sanity checks and warns if it sees problems. If you think of something that it should check for but currently does not, please let me know! And please let me know if you notice any problems or have other suggestions.

Tags , , | Permalink | Comments Off
feeds

The XMPP Standards Foundation: Skype Adds XMPP Support

2011/06/28 – 22:58

Skype has added support for XMPP to its latest Windows beta, according to Phil Wolff of Skype Journal. Janko Roettgers provides further analysis at GigaOM. This is yet another demonstration of the power of open standards.

Tags , , , , , , | Permalink | Comments Off
feeds

Thiago Rocha Camargo: Skype Client XMPP Support for Facebook

2011/06/28 – 21:15

Skype released a beta version for Windows with support for Facebook Chat. They are doing it through XMPP directly from Skype BETA Client.

Packet Trace with the proof that Skype Client now connects to Facebook using XMPP.
Once again XMPP moves forward in becoming the universal bus for 'realtime' communications.
Companies that are not understanding the importance of being 'realtime' will soon realize that their time is gone.

Hopefully in the future we also have support for other open alternatives for Audio/Video Communications on Skype like Jingle and Jingle Nodes. Like Google did adopting the Standard Jingle.
Tags , , , , , , | Permalink | Comments Off

Next Page »

Next Page »