tag:blogger.com,1999:blog-51235643977021448852024-03-04T23:23:48.790-08:00Jabber ManiaAbout Jabber/XMPP, for developers, web2 maniacs and protocol junkiesAadaamhttp://www.blogger.com/profile/05843560041038857258noreply@blogger.comBlogger22125tag:blogger.com,1999:blog-5123564397702144885.post-86306401199547034312013-06-26T11:55:00.000-07:002013-06-26T11:58:20.292-07:00How Google pulled the plug on the public Jabber Network<p>I know I'm late but I still can't see this part of the deal showing up...</p>
<p>So, it's no news that Google first disallowed new s2s connections, then started their own protocol, which has no s2s connections at all.</p>
<p>With that, the largest node of the public Jabber network went down, incorporating the largest share of its users. They're pointing to spam:</p>
<br />
<blockquote>
Chee Chew said that "we haven't seen significant uptake" in federation with Google Talk via server-to-server connections. The majority of the uptake Google did see was from organizations or individuals looking to bombard Google Talk users with chat spam </blockquote>
<i><a href="http://arstechnica.com/information-technology/2013/05/hands-on-with-hangouts-googles-new-text-and-video-chat-architecture/">Ars Technica</a></i></p>
<p>And also did the original dream of Jabber.</p>
<br />
<blockquote>
By assigning
server identity as a hostname, servers are also able to route data
directly to each other and their connected clients, thereby creating
a new, inherently open IM network out of all the individual
installed servers and clients.
</blockquote>
<i><a href="http://xmpp.org/internet-drafts/attic/draft-jabber-00.txt">Jabber internet Draft</a></i>
<p>There is no open IM network anymore: we have some walled gardens supporting the XMPP c2s protocol for easy access. </p>
<p>For years, I've been dreaming - and trying to get funds - for a mail system competing GMail, but being compatible with it both in e-mail and IM - that's not possible anymore. </p>
<p>I was <a href="http://www.slideshare.net/aadaam1/unified-instant-messaging-in-hungary">urging</a> Hungarian e-mail providers - some of them providing their own XMPP implementation - to allow external IM connections between each other and gmail - that's not possible anymore.
<p>The open network of communication won't be brought by XMPP, that's for sure.</p>
<p>Jabber failed to provide good enough <a href="http://arstechnica.com/information-technology/2013/05/hands-on-with-hangouts-googles-new-text-and-video-chat-architecture/">spam protection</a>, failed to provide a <a href="http://www.youtube.com/watch?v=mS48X9oEar0">scalable protocol</a>, failed to provide easy transfer of accounts between providers (if I change e-mail address, I don't have to re-add all my friends, it's enough to set a simple forward or inbox pulling - that's not true for Jabber IDs!)</p>
<p>Besides, no matter what was the dream, it turned out, the complexity is mostly on the client side, and that IM networks are <a href="http://public.dhe.ibm.com/software/dw/rationaledge/jun07/BoochEtAl_CH01.pdf?S_TACT=105AGX52&S_CMP=cn-a-r">inherently complex</a>. We had a lot of clients able to transfer basically text-only messages. <a href="https://developer.pidgin.im/ticket/1768#comment:23">Not even files</a>. </p>
<p>Also, given the fragmentation of the community - it's not a product, it's a protocol community somehow - Jabber failed to gain developer interest it seems - instead of Jingle, the way for A/V communications <a href="http://www.geek.com/apps/firefox-22-brings-odinmonkey-for-web-gaming-webrtc-for-chat-1560122/">seems to be WebRTC now</a>. </p>
<p>For message broadcasting and queing, there are a lot of protocols available. XMPP is one of them. For me, XMPP was an open protocol and network for human-to-human communication, and it seems it has failed its mission. It's only used as a fallback protocol for IM clients. </p>
<p>So, it seems we're struck with walled gardens for a while again.</p>Aadaamhttp://www.blogger.com/profile/05843560041038857258noreply@blogger.com15tag:blogger.com,1999:blog-5123564397702144885.post-40709629243878138722011-07-10T01:10:00.000-07:002011-07-10T01:28:53.632-07:00Jingle FT - the million dollar protocolI was speaking with <a href="http://wiki.xmpp.org/web/Florian_Jensen_Application_2011">Florian</a>, one of the board members of XSF, and showed him my pattern about <a href="http://www.scribd.com/doc/59715164/Http-Based-File-Transfer-Pattern">HTTP-based filetransfer in IM clients</a>, just as done by Beejive or Meebo.<br /><br />As far as I remember, the filetransfer argument - namely: it doesn't work in XMPP with 5 parallel standards - was settled down by requiring everyone to implement the most complex one: <a href="http://xmpp.org/extensions/xep-0234.html">Jingle File Transfer</a>.<br /><br />It's like saying we don't need filetransfer to be implemented at all.<br /><br />Jingle is a such complex protocol, that most of the client developers won't even try to implement it. It's just huge. Even Google didn't really succeed with their own implementation (remember the Cricket:: namespace??) and we don't speak about server-side requirements yet.<br /><br />The XMPP community is constantly ignoring the fact that we're living in - albeit perhaps the end of - the web age. XML was proven to be inefficient, no matter how you compress it, it's just isn't par with JSON or other formats. Pull parsing technique requires special parsers to be written for XMPP, meaning loss of reuse (although they give the stanzas to normal parsers afterwards), Nokia didn't take XMPP in its production phones for efficiency reasons and all the social networks - facebook, hyves, meebo, gmail - implement their own client2httpd solution instead of the inefficient <a href="http://xmpp.org/extensions/xep-0206.html">BOSH</a>.<br /><br />You can <a href="http://xmpp.org/extensions/xep-0295.html">joke</a> about it, but the reality is: XMPP is likely to be superseeded sooner or later.Aadaamhttp://www.blogger.com/profile/05843560041038857258noreply@blogger.com9tag:blogger.com,1999:blog-5123564397702144885.post-88516011344929159692009-05-28T13:07:00.000-07:002009-05-28T13:16:26.121-07:00Google took the API stepJust to remind: even if nobody seemed to care after my controversial talk on XMPP Summit this year (not that most of you believed such at all), <a href="http://googletalk.blogspot.com/2009/05/attention-nerds-new-gadgets-api-for.html">Google took the API step</a>. <br /><br />(For a rant on APIs, see <a href="http://jabbermania.blogspot.com/2008/02/widgets-xiclets-and-rest.html">my previous post</a> and the ones listed at the beginning of that)<br /><br />I know <a href="http://sameplace.cc">SamePlace</a> was much before this, but, with all the credits to Massimiliano, GTalk has a much larger user base. <br /><br />Now, what we need is a standard API above <a href="http://meebo.com">Meebo</a>, SamePlace, and this stuff, like Ajax did for the XMLHttpRequest implementationsAadaamhttp://www.blogger.com/profile/05843560041038857258noreply@blogger.com4tag:blogger.com,1999:blog-5123564397702144885.post-61898032077077832512008-07-07T12:20:00.000-07:002008-07-07T12:46:00.878-07:00Active resource representations - aka OEmbed(Note: this isn't a jabber-only posts, although one of the earliest implementations is in Google Talk Gadget, and the jabber community could benefit from this in general)<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://code.google.com/p/php-oembed/"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand" src="http://aadaam.dev.ischmerosok.hu/oembed/oembed_demo.png" border="0" alt="" /></a><br /><br /><a href="http://code.google.com/p/php-oembed/">PHP-OEmbed project page</a><br /><br />Remember when the newly introduced <a href="http://googletalk.blogspot.com/2007/03/google-talk-gadget.html">Google Talk Gadget</a> displayed Youtube videos instead of showing their links? That's what I call "active resource representation", because it represents the given video more [inter]actively than the pure link - which is hardly showing anything in the case of youtube.<br /><br />I believe that a resource usually can be equally represented in a small place: there's no need to load a full page to view a youtube video or a flickr photo, but there isn't need for it to look at a person's social network profile, to accept/reject a calendar invitation, etc - and all of these have URLs nowadays. These technologies could be used in e-mail systems, forums, and chat clients.<br /><br />What <a href="http://oembed.com">OEmbed</a> does, is that it tries to provide metadata about a certain resource found at the given URL. That is: you send the link of a flickr photo, and you get an XML or JSON-formatted structure back. While it <a href="http://www.backdrifter.com/2008/05/09/oembed-fail-represent-restfully/">can be argued</a>, that these could be / should be / in an ideal world, would be solved by HTTP headers, this is not the case, and this solution isn't as bad.<br /><br /><br />I tried to do a server-side PHP framework, which talks the OEmbed protocol for clients to consume, however, it makes you be able to create non-oembed compatible wrappers too (the perfect example is youtube, of course). This could be used in a web-client, given that it talks back javascript to you. <br /><br />Currently, it can handle (proxy) any OEmbed provider (given that you enter their respective address into the providers.xml file), and it has a Youtube provider, which uses some not-so-official part of the "official YouTube Data API". New providers can be added by looking at the provider API - oh, and there's no error handling yet, so you could understand the code :)<br /><br />Note: I extended OEmbed protocol a bit, namely: <br /><ul><br /><li>There could be a description field for every OEmbed-entity (handy for tooltips)</li><br /><li>There could be a duration part (in seconds) for video embeds</li><br /><li>The original resource URL could be in the data response</li><br /></ul><br /><br />Oh, and <a href="http://flickr.com">Flickr</a>: please add thumbnails! Thanks :)Aadaamhttp://www.blogger.com/profile/05843560041038857258noreply@blogger.com1tag:blogger.com,1999:blog-5123564397702144885.post-85046381282590015212008-02-04T11:48:00.000-08:002008-02-04T13:07:02.205-08:00Widgets, Xiclets and the RESTIt seems <a href="http://blog.bluendo.com/ff/xmpp-widgets">Fabio Forno</a> and <a href="http://wiki.jabber.org/index.php/Pedro_Melo_January_2008">Pedro Melo</a> are also brainstorming on some kind of "widget-technology" for jabber, and the same applies to me. I've written several articles in the theme, see:<br /> <br /> <a href="http://jabbermania.blogspot.com/2007/07/why-xmpp4moz-needs-to-be-standard-whats.html">Why xmpp4moz needs to be a standard: What's wrong with XEPs?</a><br /> <a href="http://jabbermania.blogspot.com/2007/11/xmpp-services-as-opensocial-providers.html">XMPP services as OpenSocial providers</a><br /> <a href="http://jabbermania.blogspot.com/2007/11/meebo-invented-everything-us-in-2007.html">Meebo invented everything for us in 2007(?!)</a><br /><br />Why do we need such? Let's see:<br /><ul><br /><li>HTTP is one of the most succesful protocols</li><br /><li>It has the following extensions currently in use:<br /><ul><br /> <li><span style="font-weight:bold;">HTML 4.01 </span>(or XHTML 1.0) for presentation</li><br /> <li><span style="font-weight:bold;">CSS 2.0 </span>for design</li><br /> <li><span style="font-weight:bold;">ECMAScript 3 (JavaScript 1.6)</span> for interactivity (with an included <a href="http://en.wikipedia.org/wiki/Document_Object_Model">DOM</a> API, and with the lack of threads, therefore it should use asynchronous requests)</li><br /></ul><br /></li><br /></ul><br />See? Nothing else. No <a href="http://jcp.org/en/jsr/overview">JSRs</a>, no <a href="http://www.xmpp.org/extensions/">XEPs</a>, no "MAYs", just these three. <br /><br />Does it solve all problems? Not always, but mostly. Does XMPP solve all problems? Not yet.<br /><br />Now let's get back to the topic specifically.<br /><br />The thing is about code mobility, and now we can safely reference to the original REST article (which isn't as bad as restafarians usually are): <a href="http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm">http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm</a><br /><br />Let's have an application, residing on a certain location (URL), being it chess, or a flash-based videoconferencing/VoIP tool; of course, for interactivity, at least two instances should be run, one at each participating user. We can use either the fact that modern IM-clients use an embedded browser to display conversations (official AIM, Y!M, WLM; Adium), or some kind of integration between the IM-client (eg. pidgin) and a browser (eg. firefox). What could this look like?<br /><br />The design issues we met are: <br /><br /><ol><br /><li>Features provided by XMPP<br /><ul><br /><li> (RealTime) Communication channel between two application instances from the same source<br /></li><li> (RT) Communication channel between an application instance and the participating users<br /></li><li> RESTRICTED? Presence information of the participating entities (users + bots)<br /></li><li> STRICTLY RESTRICTED: Roster information + all contacts' presence of the user<br /></li></ul><br /><br /></li><li> Features provided by HTTP<br /><ul><br /><li> Remote script inclusion (like: <a href="http://code.google.com/apis/gadgets/docs/fundamentals.html#JS_URL">Google Gadgets</a>)<br /></li><li> Developers MUST be able to write XMPP-supported applications in pure web-style (eg. PHP scripts)<br /></li><li> It SHOULD be easy to adopt <a href="http://www.facebook.com/apps/">already written</a> <a href="http://wwwl.meebo.com/platform/">applications</a> for the new platform, either which uses real-time communication and those who aren't<br /></li></ul><br /></li><li> Features derived from browsers:<br /><ul><br /><li> Ability to run javascript applications<br /></li><li> Ability to display XHTML + CSS<br /></li><li> DOM API (perhaps E4X as well? at least, at a later time)<br /></li><li> Sandboxing and cross-domain code execution<br /></li><li> Some kind of interaction between the XMPP client (which SHOULD be able to be a web-based client too!) and the application<br /></li></ul><br /></ol><br /><br />Restricted features could be accessed if certain security checks are met (like: the page is from HTTPS, signed by an <a href="https://www.xmpp.net/">acceptable authority</a>, like the enterprise running the XMPP infrastructure, or an official XMPP extension); This was done for years with java applet/midlet technology. <br /><br />Our current example is a Go (simpler than chess) client which should be written in pure PHP + JavaScript (not because we ourselves cannot use more sophisticated, but it's the lowest entry barrier)<br /><br />Another good example is whiteboarding, <a href="http://ca.messenger.yahoo.com/singleimv.php?imv=doodle">it's done such way in Yahoo! Messenger</a>.<br /><br />We'll see if we could extend it further.<br /><br />Hope we could meet at DevCon and have a conversation about that (but it shouldn't stop you to comment :)Aadaamhttp://www.blogger.com/profile/05843560041038857258noreply@blogger.com5tag:blogger.com,1999:blog-5123564397702144885.post-31837865027438932992008-01-16T15:14:00.000-08:002008-01-16T15:24:55.765-08:00Open Source Nights presentationI presented a few hours ago on <a href="http://estek.phanatic.hu/">Open Source Nights</a>, hosted by my long-time friend and ubuntu advocate <a href="http://phanatic.hu">Szilveszter "Phanatic" Farkas</a> about jabber.<br /><br />I quickly translated the slides, you can read them <a href="http://adamnemeth.hu/publications/szestek_eloadas_en.pdf">in English here</a> or <a href="http://adamnemeth.hu/publications/szestek_eloadas.pdf">in Hungarian here</a>.<br /><br />All in all, it was a good evening, hope it will bear us some deployments, or at least, jabber users :)Aadaamhttp://www.blogger.com/profile/05843560041038857258noreply@blogger.com1tag:blogger.com,1999:blog-5123564397702144885.post-8345922921571772892007-11-10T16:02:00.000-08:002007-11-10T16:34:38.605-08:00Meebo invented everything for us in 2007(?!)<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhhtNBRFadZN3cANInMh6ryY03YAgfQxXESbnoPEX7F6Ghy2Le0EgJY-vbJatTDUmYDMtn7ezceJqMWr9C-WA-QfLJ9NPgCCIBQpynWqItNKRfIz7yRU4hv3ZTOrhTf1oEWClpNbV77ANzg/s1600-h/meebo_phone.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhhtNBRFadZN3cANInMh6ryY03YAgfQxXESbnoPEX7F6Ghy2Le0EgJY-vbJatTDUmYDMtn7ezceJqMWr9C-WA-QfLJ9NPgCCIBQpynWqItNKRfIz7yRU4hv3ZTOrhTf1oEWClpNbV77ANzg/s320/meebo_phone.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5131374240229223858" /></a><br /><br />If there would exists a "Jabber Innovation Award 2007" I would definitely give it to Silicon Valley-based <a href="http://meebo.com">Meebo</a>. Their platform, built on top of libgaim and jabber, offers the following things currently:<br /><br /><ul><br /><li>Online Presence / chat widget <a href="http://www.meebome.com/">embeddable</a> at webpages</li><br /><li>Web interface and <a href="http://wiki.meebo.com/doku.php?id=meebome#how_can_i_log_into_my_meebo_me_account_using_my_jabber_client">desktop client</a> support for jabber (your account is user@meebo.org)</li><br /><li>Ad-hoc groupchat functions accessible from any network (through web interface) - most possibly based on MUC</li><br /><li><a href="http://wwwl.meebo.com/rooms/about/">Embeddable groupchat</a> (MUC) for webpages</li><br /><li>Media-recognition (youtube links are added to a media pool in a groupchat)</li><br /><li>Web-based <a href="http://wiki.meebo.com/doku.php?id=im_chat:advanced_features&s=file">filesending </a>abilities, even for groupchat</li><br /><li>Platform-independent <a href="http://wwwl.meebo.com/platform/">web-based plugin capabilities</a>, including:</li><br /><li><a href="http://www.techcrunch.com/2007/10/29/meebo-platform-launches-with-big-san-francisco-party/">Voice and videochat support</a> with any users on any network</li><br /></ul><br /><br />Pretty awesome list, isn't it?<br /><br />I recommend to try it for yourself, as I said above, registering a meebo user means effectively having a jabber address - using other systems happen through gaim. <br /><br />While we're trying to push out new XEPs, they realized two things:<br /><ul><br /><li>Web is the platform you should build on, because it's independent from nearly everything, yet quite popular</li><br /><li>If you have a disadvantage (being a browser-based client it isn't fashionable for geeks) you better start to innovate.</li><br /><li>Even if you're based on jabber, you should make sure protocol does not matter: it's the client which does the user experience</li><br /></ul><br /><br />If we could only ask them, how they achieved this, and how we could make this a common knowledge of humanity and ourselves!<br /><br />(The author still dreams of having an open meebo platform-like solution for desktop clients too through standardizing and WebKit/Gecko/CHtmlView)Aadaamhttp://www.blogger.com/profile/05843560041038857258noreply@blogger.com5tag:blogger.com,1999:blog-5123564397702144885.post-38863470656587463342007-11-02T08:20:00.000-07:002007-11-02T08:33:52.697-07:00XMPP services as OpenSocial providers?I'm just looking at the freshly-out <a href="http://code.google.com/apis/opensocial/">OpenSocial API</a> by Google, and a <a href="http://www.techcrunch.com/2007/11/01/confirmed-myspace-to-join-google-opensocial/">few others.</a> While there's a lot of rationale behind how and why the <a href="http://developers.facebook.com/">Facebook platform</a> works as we know it today, I understand such a system would be hard to use generally for a lot of social network providers, therefore the OpenSocial API is much simpler.<br /><br />Looking at the <a href="http://code.google.com/apis/opensocial/docs/javascript/reference/">API</a>, it feels to me it perfectly fits some usual <a href="http://www.xmpp.org/extensions/xep-0163.html">PEP</a>-<a href="http://www.xmpp.org/extensions/xep-0223.html">PIP</a>-<a href="http://www.xmpp.org/extensions/xep-0222.html">POP</a>, (generally P.?P:) scenarios, and since some of the major XMPP server vendors contain a built-in webserver already, it shouldn't be hard to do as a module for them. <br /><br />What would be the benefit of providing such API? Building systems on top of XMPP allows us to deploy services in the social web scene, which did not get jabber yet as much as it could be.Aadaamhttp://www.blogger.com/profile/05843560041038857258noreply@blogger.com9tag:blogger.com,1999:blog-5123564397702144885.post-12555106090931340562007-08-07T09:21:00.000-07:002007-08-07T09:41:59.064-07:00Push e-mail: are you kidding?I've heard recently that Enterprise IM is the the <a href="http://www.readwriteweb.com/archives/instant_messaging_most_valuable_web_20_tool_for_enterprises.php">most popular "web 2.0"</a> tool amongst corporations.<br /><br />When I asked my cousine, working for a large and well-known company in New York, that why don't she uses their own IM system, just gmail. She told me that they don't use an own IM system.<br />I asked:<br /><blockquote>- Do you use blackberry?<br />- Yes<br />- For Push-email?<br />- Yes<br />- That's IM.</blockquote><br /><br />Come' on: it's <span style="font-weight: bold;">Instant</span> and <span style="font-weight: bold;">Messaging</span>. It does not have presence subscription, but it does have a roster (it's only called <span style="font-style: italic;">Address Book</span>). Surely it has advantages (people who <span style="font-style: italic;">"has an older version of internet installed on their computer" </span>can communicate with you), and there are disadvantages as well (they don't see how busy you are, therefore they can't decide if it's important enough, something which could be solved with presence).<br /><br />But before trying to hurry your marketing departments to advertise XMPP as a free alternative of Blackberry, you should first <span style="font-weight: bold;">migrate from the old system</span>. What am I thinking about?<br /><ol><li>Write a component which is compatible with push-email, so they don't loose functionality<br /></li><li>Write a component which is compatible with postfix, qmail, whatever smtp servers are popular nowadays, to work together with XMPP servers - this way creating an XMPP-based free push e-mail alternative</li><li>Write a client, preferably for mobile phones where this transport could be handled conveiently.</li></ol>Come on, it's your turn EIM jabber vendors: there's a market ruled by a ridicolous propiertary system, which could be easily overriden by just a tiny piece of software - an SMTP server module which catches e-mails and acts as a transport.Aadaamhttp://www.blogger.com/profile/05843560041038857258noreply@blogger.com7tag:blogger.com,1999:blog-5123564397702144885.post-14747315439613653852007-07-28T07:30:00.000-07:002007-07-28T07:51:55.868-07:00Jabber aliases / j2j gatewayI have more jabber accounts than an average guy has an e-mail address. As Jabber usage will start to grow, and different communities and organizations will adopt Jabber as their choice of communication technology (rather than today's e-mail, or e-mail-like systems found in forums and social network sites), we'll have to find a way to connect jabber accounts of a person into one (or a few) bundles. <br /><br />Of course, there exist approaches like Psi's multiple account system, as well as using Gaim, or other MPIM for jabber purposes, but none of them is a real, protocol-level solution.<br /><br />But we can do this by Jabber-To-Jabber transports, like <a href="http://wiki.jrudevels.org/index.php/Eng:J2J">j2j</a> does.<br /><br />It's a XEP-0114 compatible jabber component, so it's suitable for most jabber servers.<br /><br />I was constantly asked for this feature, mostly to connect gmail accounts into a new system, so here it is. Thx for Steve for recommending.Aadaamhttp://www.blogger.com/profile/05843560041038857258noreply@blogger.com9tag:blogger.com,1999:blog-5123564397702144885.post-80027905655587978952007-07-15T08:23:00.001-07:002007-07-16T10:11:20.631-07:00Why xmpp4moz needs to be a standard: What's wrong with XEPs?This post is a long-awaited post for me, but I felt the motivation again after viewing and browsing Douglas <a href="http://crockford.com">Crockford</a>'s <a href="http://developer.yahoo.com/yui/theater/">videos</a> about JavaScript.<br /><br />First, let me tell you that the IM war is mostly a war on <span style="font-weight: bold;">user experience</span>. The more fun the user can get with a given IM-<span style="font-style: italic;">solution</span> (by which I mean both protocol, client, and service provider), the more possibly he's likely to use it. There's nothing with the network effect here: if we really wanted, <span style="font-style:italic;">we could already solve that with transports</span>!<br /> <br />What is jabber? It's<br /><ul><br /><li>An open network with many service providers</li><br /><li>A core protocol (standardized in RFC 3920 and RFC 3921)</li><br /><li>A set of optional extension protocols, called XEPs</li><br /></ul><br /><br /><h2>The fate of CORBA</h2><br /><br />Of course it's nothing a user deals about, it's the thing evangelionists care about, which is nearly good enough. Corba was such a protocol in the nineties, with a core protocol, and a lot of extensions. It was born for interoperability between vendors.<br /><br />But: Corba isn't used today mostly. Corba died in the fact, that most of its parts are optional - this way there's practically no two "ORB"s, which could communicate with each other - sometimes even from the same vendor on two different platforms! This way the open ecosystem of CORBA components simply never were to be born: it was always vendor dependent, and gave its place to other vendor-dependent (Java RMI, .NET Remoting), or more formal (XML-RPC, SOAP WebServices) protocols in order to achieve a greater interoperability market, not to mention JSON and other grassroot standards.<br /><br />It cannot be argued that a network supporting all the XEPs currently in draft, final or experimental would be superior to most of today's IM network. But there's no such network, and without changes it isn't likely to be born, even if XMPP is the only standing standard between formal IM protocols. As one on jdev expressed:<br /><blockquote>We already won, it's just the thing nobody noticed this except us.</blockquote><br /><br /><h2>What's the problem with this XEP thing anyway?</h2><br /><br />The jabber network - by which I mean the open network of providers supporting the XMPP protocol - is a heterogenous environment: not only there are different server implementations and policies, but there are different clients as well. There were <a href="http://www.process-one.net/en/blogs/article/client_and_os_statistics_on_jabberru/">10 clients</a> with a larger marketshare than 3 percent on jabber.ru last month! And that's only one of the service providers, with a popular and feature-rich server implementation. What could those users on that network do with each other? It was determined by:<br /><ul><br /><li>The core protocol support itself</li><br /><li>The support of extensions by the server implementation</li><br /><li>The support of extensions by the client implementations</li><br /></ul><br />What was the largest denominator? What was the bottleneck? I think you already guessed:<br /><br /><blockquote>An XMPP network supports those XEPs which are supported by <span style="font-weight: bold;">all (or vast majority)</span> of the participating implementations - both servers and clients.</blockquote><br /><br />Which exaggerated means that<br /><blockquote>The open jabber network practically does not support (almost) any XEPs, because there's always a client or server between a large share of pairings which does not support the given XEP.</blockquote><br /><br /><h2>In need of the algorhythm</h2><br /><br />XEPs are basically data formats to be exchanged between two parties, but sometimes they even define a protocol of interchange. But what could a client do with plain data? Of course nothing. It needs an algorhytm to process the data and give an answer. Since the XEPs theirselves aren't formal definition in a computer science perspective (using SHOULD and MAY is formal for a human, but not for a computer). The former JSF process put the implementation in the hands of client authors, making it the responsibility of them to implement them. Of course, every client author picked up their own choice of implementing XEPs, and there's hardly an intersection between them.<br /><br />So what we would need is either:<br /><ul><br /><li>An official repository of processing alghorythms with formal description, which means in some kind of computer language, to which an interpreter/compiler could be written for clients</li><br /><li>Make the processing instructions travelling with the data package, possible with weak linking (eg. a processing URL)</li><br /></ul><br />An official repository could be needed if the processing could do malicious or privacy-problematic things on behalf of user, either centrally, or by signing it with usual keys (eg. a client could accept a corporate SSL certificate to use their implementations in an EIM environment, and official XSF-signed extensions).<br /><br /><h2>Representation</h2><br /><br />Of course, if we have the data, and have the alghorythm, one could argue, that a layer is still missing: the view layer. And one could argue that this <span style="font-style: italic;">should</span> vary from client-to-client, but if we do inspect today's popular IM solutions, we should find out that all of the corporate rivals (MSN, AIM, YIM, ICQ, etc) <span style="font-weight: bold;">use an HTML rendering system</span> in that layer in official [windows] clients; while it could be argued that some XMPP clients does not, but it does not mean it's a right way: by using the broad market of HTML rendering engines (Gecko,Webkit, Windows' CHtmlEditCtrl...), a lot of diplay problems could (and should?!) be solved.<br /><br />There's even a space for interactive applications, like board games, crayon-based whiteboards (which I really liked in Yahoo!'s IMVironments), all which could be done by using a proper HTML-based rendering engine and some common features which all clients could share.<br /><br />While HTML is in itself probably a bad idea, <span style="font-weight:bold;">XHTML</span> isn't much difference, while it's still XML. Therefore, <span style="font-weight: bold;">XSLTs and CSSs</span> could still be used over it, giving a client's own look and feel. XSLT is also formal: it could give XSF a tool by which recommendations could be written into XEPs.<br /><br />Hey! It would be even useable on webclients and an iPhone :)<br /><br /><h2>A processing language for view layer?</h2><br /><br />It's also arguable that XSLT in its own would be enough to write collaborative applications, games, etc, but hey, we already have a good view-layer language: it's called <span style="font-weight: bold;">JavaScript</span>, and its core features are used in many interactive application frameworks, most notably Flash and XUL. And this is again a part where HTML rendering engines come in: they have a natural support of JavaScript.<br /><br />But there's also support (or, to be correct, a variant) in Flash, in Java (have you heard of <a href="http://www.mozilla.org/rhino/">Rhino</a>?), in <a href="http://developer.kde.org/language-bindings/js/index.html">KDE</a> applications, and in <a href="http://www.mozilla.org/js/spidermonkey/">C</a>: basically everything. Webclients are in fact written either in JavaScript, or its variant, ActionScript (OK, there's <a href="http://jeti.jabberstudio.org/">Jeti</a> as an exception, I know), so they could also have some support of collaborative JavaScript applications.<br /><br /><h2>The way xmpp4moz works</h2><br /><br /><a href="http://beta.sameplace.cc">xmpp4moz</a> by <a href="http://hyperstruct.net">hyperstruct</a> thinks XMPP of a communication <a href="http://dev.hyperstruct.net/xmpp4moz/wiki/DocArchitecture">layer</a>, on which collaborative applications could be built. It uses the XUL variant of JavaScript [unfortunately, but we'll deal it later], which means it makes the browser-application "presence-enabled" so applications written in javascript could talk with each other. Of course there are <a href="http://dev.hyperstruct.net/xmpp4moz/wiki/DocSecurity">security restrictions</a>: namely an application could only catch those messages which are for the conversation the application currently runs in (can be a MUC or a private conversation). While it's strange for the first minute, since there's no authority, and any webpage could use some collaborative features by using this framework, it's a viable decision.<br /><br />After all, it's a good thought: collaborative applications resides on their own webpage, and they can be used by calling them from a presence-enabling framework; this would fit very well to the web ecosystem. This could be a browser, or a desktop client.<br /><br />The only problem is that xmpp4moz uses firefox-only javascript methods, which are good if you want to expand firefox's possibilities, but is a very wrong approach when you want to design a new collaborative application standard, but it's not a thing which couldn't be solved: after all, both <a href="http://www.igniterealtime.org/projects/xiff/">XIFF</a>, <a href="http://zeank.in-berlin.de/category/jabber/jsjac/">JSJaC</a>, <a href="http://onlinegamegroup.com/projects/libstrophe">libstrophe</a>-JS and xmpp4moz should have their common denominators. But I left this to solve for <span style="font-weight:bold;">You</span>.<br /><br /><span style="font-style:italic;">(All the above text is merely a personal opinion, sometimes perhaps made more pessimistic than in reality to catch attention and start arguments; it's not an official statement nor I think the XMPP world is simply wrong at all.)</span>Aadaamhttp://www.blogger.com/profile/05843560041038857258noreply@blogger.com2tag:blogger.com,1999:blog-5123564397702144885.post-18937568369653252832007-06-06T17:06:00.000-07:002007-06-06T17:05:35.981-07:00After-meetup linksHi all,<br /><br />So, meetup was held, here are some links:<br /><br /><ul><br /><li>My presentation in <a href="http://jo-hely.hu/~aadaam/publications/presence_openim_meetup_final_en.pdf">English</a> and <a href="http://jo-hely.hu/~aadaam/publications/presence_openim_meetup_final.pdf">Hungarian</a><br /><li><a href="https://wiki.sch.bme.hu/bin/view/_Munka/JabberCustomSmileys">Custom Smiley Handling in Jabber</a><br /><li>The two introduced systems: <a href="http://igniterealtime.org">Jive OpenFire</a> and <a href="http://ejabberd.jabber.ru/">ejabberd</a><br /><li>A <a href="http://www.bmannconsulting.com/blog/bmann/twitter-is-jabber-part-ii#comment-136135">blog comment</a> from twitter senior developer Blaine Cook about twitter and jabber (look for "In principle, I Agree")<br /><li><a href="http://jo-hely.hu/~aadaam/jsjabber/">JsJabber</a> (educational javascript client)<br /></ul><br /><br />And here are the five key thoughts I wanted to share, with a very little explanation<br /><ul><br /><li><b>Innovation</b>: The fact that you can build your own userbase, and run your own independent service with just using standards, and that you can extend them is the key component in success of web 2.0 and GSM-networks (in this case: http, html / xhtml, ecmascript, and oma/3gpp standards)<br /><li><b>Service-based distinction:</b> Although you could build an own mobile network which outsiders can't use, of course, it will be possible, but I hope that in most cases you still think it ridicolous. You distinct your own users from outsiders by advanced [innovative?] services and prices, not by not allowing them to talk to gmail users just because "it's a rival". [This was a reaction for freemail's closedness]<br /><li><b>Mash-up</b>: It's better to show your users your own extension protocols (like Gmail does for <a href="http://code.google.com/apis/talk/jep_extensions/extensions.html">Gmail notifications</a> and others), so others can remix it; and it's better to use some remixable system like <a href="http://sameplace.cc">SamePlace</a>, to open a whole new ecosystem of plugins (<b>Note to self: we must find a way to standardise html/http based collaborative application building like which is in sameplace</b>)<br /><li><b>Word-of-mouth</b> Of course you can't tell everybody to use Jabber (but you possibly have just enough media to place it before your users), and can't officially do an MSN-gateway for a large hosting; but you can let this information spread.<br /><li><b>At home</b>: Install a jabberserver (like ejabberd or openfire),and try it for yourself<br /></ul><br /><br />(Presentation and key messages slightly differs!)<br /><br />As you can see, it's a mashup-point-of-view: it's been a popular theme in Hungary this year, and I think we have seen just enough walled gardens here at home to try if we do it better this way.<br /><br />Oh, presentation is CC licensed (as all Budapest New Technology Meetup presentations)Aadaamhttp://www.blogger.com/profile/05843560041038857258noreply@blogger.com5tag:blogger.com,1999:blog-5123564397702144885.post-60019999033062346282007-06-06T16:41:00.000-07:002007-06-06T17:24:49.802-07:00JsJabber: Educational client in javascriptHere is my educational client, built with PWC and jsjac. It does not have presence changing feature, it just shows how a jabber client could be done. Feel free to use it.<br /><br />(Was done in a few hours, probably would be good for a quick workshop:)<br /><br /><a href="http://jo-hely.hu/~aadaam/jsjabber">JsJabber client homepage</a><br /><br />(You can test it in Firefox with a <a href="http://jo-hely.hu">Jo-hely (good places)</a> account, registration is free (Hey, my team built it ;)<br /><br />For those for whom it does not work, a screenshot:<br /><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjP6nl4nIcUEpTuUpjGSm1Oivl20vFuRbSnn7wvsDLse4TcExypPegwhcHKMPP-6iUnnO6onbyPI2LxwWkrx11hSbI2zOPCsHBjGKCSfB73YyPNVcg3WocS4HOPToqyNojMOZ6nfHVOtGvP/s1600-h/jsjabber_in_action.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjP6nl4nIcUEpTuUpjGSm1Oivl20vFuRbSnn7wvsDLse4TcExypPegwhcHKMPP-6iUnnO6onbyPI2LxwWkrx11hSbI2zOPCsHBjGKCSfB73YyPNVcg3WocS4HOPToqyNojMOZ6nfHVOtGvP/s320/jsjabber_in_action.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5073111711738640354" /></a>Aadaamhttp://www.blogger.com/profile/05843560041038857258noreply@blogger.com7tag:blogger.com,1999:blog-5123564397702144885.post-540517185123410422007-06-01T15:18:00.000-07:002007-06-01T15:38:53.483-07:00Unified IM network in Hungary - what would YOU say?I'll have the oppurtinity to talk about <i>'Unified IM network in Hungary?'</i> in a five-minute session on <a href="http://newtech.meetup.com/42/">The Budapest New Technology June Meetup</a>, which will be visited by nearly everyone who counts in the social media industry.<br /><br />The excerpt of the presentation is:<br /><blockquote><br />Everyone knows GTalk; some may know, that is based on a standard protocol, jabber (XMPP). T-Online uses this for messenger in <a href="http://freemail.hu">Freemail</a>. The presentation would be a five minute summary of what is jabber, how one could start a service fast and simple, and what could we gain if we could make a unified network of this, and what problems could arise.<br /></blockquote><br /><br />What would You, dear reader of mine say, if you'd be in my position? <br /><br />Facts: <br /><ul><br /><li>There are 4 major players in Hungarian market, one of them is T-Online.<br /><li>Privacy and security is not an issue (yet) in Hungary (people don't think of it too much, won't be profitable)<br /><li>Nearly everyone has an MSN account (unfortunately), so we have to say what would happen if Jabber would be put under everyone's nose (in webmail and in... and in what?) Why would they switch if at all? Why would it be better?<br /><li>Hot topics are: eventing (mainly twitter), and social networking*, in which monopoly could be broked also<br /><li>Internet penetration is about 34-38%, mobile penetration is above 100%, although mobile internet/wap is rarely used (or it's used by the 60% rest who does not use internet)<br /></ul><br /><br />So, what would <i>you</i> say?<br /><br /><br />* (we have some social network sites, most popular is property of T-Online, called <a href="http://iwiw.hu">iWiW</a> (Who-is-Who?). Although it's not very customisable, when someone logs in, basically could reach everyone's data: name, location, about myself, reach addresses (e-mail only shown for 'friends' by default), 10 MB worth of pictures, one embedded video from youtube; mostly used features are pictures, searching; average connections is about 300-400 per user)Aadaamhttp://www.blogger.com/profile/05843560041038857258noreply@blogger.com8tag:blogger.com,1999:blog-5123564397702144885.post-5788980362377824012007-05-26T15:12:00.000-07:002007-05-26T15:57:22.767-07:00General PubSub (PEP) receiver?Recently, Artur Hefczyc from Tigase project implemented a <a href="http://www.tigase.org/node/1279">StanzaReceiver</a> module, which is, simplified, a general pubsub-like interface, but uses a general <message/> stanza with body instead of pubsub stanzas. <br /><br />This gave an idea of having a general event receiver component of clients: if a pubsub / pep node can't be handled by one of those special protocols (like: User Avatar, User Tune, etc.), then just pop up in a window somehow.<br /><br /><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEikQHTgowoQkUZgkgwO9v5CIf0juD56Vs7razjbj844YaNqaqnCJPCjV86BIJTtCQsFl_B7Wk9pMHpWFvy0S6a-7vGwNLlo61J_6TQKcr0Rbxa4P7Gmp383w2uLzh9IGZRl061VvC9oRFTn/s1600-h/pep_general.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEikQHTgowoQkUZgkgwO9v5CIf0juD56Vs7razjbj844YaNqaqnCJPCjV86BIJTtCQsFl_B7Wk9pMHpWFvy0S6a-7vGwNLlo61J_6TQKcr0Rbxa4P7Gmp383w2uLzh9IGZRl061VvC9oRFTn/s320/pep_general.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5069004075285580802" /></a><br /><br />(Mockup created with OmniGraffle, using CC photo from flickr user Bhalash, just to give the credits.)<br /><br /><b>Why?</b><br /><br />Client compatibility is always a bottleneck. If we do PEP a general protocol over User Tune, User Mood etc, we don't have one new protocol to implement: we have a new one for every capability. Isn't it easier, to, let's say, have a "<human-readeable/>" field for every possible solution, and if a client can't handle such event, well, it simply falls back to a default method?<br /><br />Basically, we still have 3 types of messages: a direct one, a broadcast one, and a get-set pair of them. We know that we just want to 'broadcast' something, in hope that this will be understood by most of our peers - but what happens if not? I think end users would benefit from such.<br /><br />I don't want to force anybody to anything, just trying to get the flexibility of pubsub and the obvious reasons why StanzaReceiver was created get together :)Aadaamhttp://www.blogger.com/profile/05843560041038857258noreply@blogger.com5tag:blogger.com,1999:blog-5123564397702144885.post-51147952980032781242007-04-12T01:41:00.000-07:002007-04-15T05:37:12.160-07:00Future of internetIn the last few days I didn't have constant internet connection - The network was demolished about two weeks ago, just before we moved, and there's no connection yet at the place where we live now. This way I could understand the importancies of my online life, and with a little background, I realized some things. First of all, I realized that IM was my most needed feature, the second one was e-mail, then community portals I'm on came, and just then news sites and blogs came. And I also realized it wasn't an accident.<br /><br />I'd like to congratulate Evgs and the <a href="http://bombus-im.org">Bombus</a> team from this place: they made my life a lot easier in the past few weeks, and their client is wonderful, does more than a lot of desktop clients, yet it was suitable for my phone, even for my old k700i.<br /><br />So, let's see the basic lessons I've taught:<br /><br /><b>I'm only interested in internet when there's people behind there.</b><br /><br />That's what web 2.0 is about in fact. For years, I've been working on CMS-solutions, making portals to enable target audiences to reach the information they want - but that's not the internet I was really looking for.. I was on e-mail lists with other developers far away talking about software projects, on IRC channels with beloved girls and friends, then blogs and social-network mania came. Now the actual hype is around <a href="http://twitter.com">Twitter</a> which is again not about great solutions.<br /><br />I understood this as my possibilities to get online shrink, I wasn't interested in news portals and blogs, whatsoever. I wanted to read my mail, and get in touch with my friends on IM - most of them are already online on jabber; mostly they use gmail or gaim-like clients.<br /><br />But it's just one concrete thing, let's see what it is about in general.<br /><br />When I read my n-th science fiction book (this was currently Solaris, and n wasn't a too small number), I told my friend on art faculty, who's an expert on cyberpunk and SF, that "yup, it was good. Yet is about people too.". He answered: "Good literature is always about people." (Creditz goes to <a href="http://worldshots.hu">Kelt</a>). Let's do a generalization from this:<br /><br /><b>Good media is always about people.</b><br /><br />I guess you do have your own celebrity magazines in your country - at us, it's called Story, but probably you have Hello, or anything other - and have your own series, wether it be brazilian ones like <i>Rosalinda</i> or action ones like 24, CSI, any other. Besides the obvious action - part and the exciting story it's about people - probably that's why Desperate Housewives, or ER or Grace Clinic is so popular. But they aren't real people: celebrity magazines have the need to write about our false friends: we see them every day, and probably some of us are interested in their personal lives. But what about the people around us? You can not see this at a magazine... Oh you can: that magazines are called myspace, facebook, twitter, you see this every day. <br /><br /><b>Mobile internet is about realtime communication.</b><br /><br />Heard it that 'develop for mobile, use css because soon mobile clients will came and flexible layout would be important, everyone would read e-books so paper books are at risks and anyway, mobile is the future, ahoy, mobile internet!' I've been hearing this for years now. But I remember when my mother gave me my first mobile phone - none of my friends had mobile that time - that she gave me this to "always be available". But mobile doesn't do a good job at this: I don't know if I call somebody where will the call find her: at home, at bus, at school, being with her lover... you just don't know that simply. Probably you fear that it will find her at wrong time, that's why you send an SMS: not too interactive, although it has delivery receipt feature, yet you don't know if the recipient was really available and when will an answer come if any.<br /><br />I used my mobile phone to tell my friends where I am now, and mostly to ask help - they were besides real computers, with enjoyable internet connection (mine was gprs 4+2, which means basically dial-up speed), not to mention that firefox and opera maxi (tm :) were compatible with "normal, usual hungarian web pages" where most of the information I wanted to reach resided. It was fun to have the instant availability of my friends in my pocket, that I could chat along a long journey with them if there were nothing else interesting. And I always knew who I can chat with, and answers came instantly.<br /><br />(Note: I was using T-Mobile GPRS Net subscription, which contains 50MB of data transfer per month bundled in the subscription fee - since I use it for jabber only, I'm not talky enough to overrun this just by chatting :)<br /><br />Of course, not "realtime" and "always-on presence" are the only key concepts of future mobile technology, but I'm sure they're one of them. Sorry for bothering you with such general posts - I'm preparing some research papers now on Jabber, so next time I hope I could provide you with more concrete, protocol and a bit implementation-related things :)Aadaamhttp://www.blogger.com/profile/05843560041038857258noreply@blogger.com4tag:blogger.com,1999:blog-5123564397702144885.post-64378939871807653352007-04-07T13:51:00.000-07:002007-04-09T08:12:13.524-07:00Freemail and jabber<i>[This post was originally in Hungarian on my personal <a href="http://adamnemeth.hu">blog</a>, and was sent to some people inside and near Hungarian ISP T-Online, which owns <a href="http://freemail.hu">freemail</a>. Freemail is the oldest e-mail service in Hungary, with roughly 3 million users, that wasn't updated for many years. In March, T-Online announced the public <a href="http://freemail.hu/levelezes">beta</a> of the new freemail, which has a built in IM-client in javascript built on jabber, and a SIP client (for which T-Online has already a desktop VoIP client, called Klip, since 2005 or so) in java. But the jabber service is only available through the web interface (yup, http-binding), and no s2s is allowed.]</i><br /><br /><br />Dear T-Online developers,<br /><br />First, I'd like to express my happiness about that freemail has chosen the standard, open source - rooted Jabber / XMPP protocol instead of proprietary solutions. This - because of the amount of users - is a big step in the history of jabber service too: to the usually cited 50 million users this 3 million growth is significant, let alone considering the internet penetration in our country [it's about 30-40% on 10 million people]. I hope that soon every Hungarian internet user could have a Jabber account, what could cause an innovational movement unprecedented in Hungary. I believe, that there's much unexploited potential behind this technology, and that it can develop further in an open competition, in a market-oriented environment.<br /><br /><a name='more'></a><br />However, users will engage the benefits of a standard solution only if we make it more open: e-mail systems used to be incompatible with each other, now a freemail user can easily send a mail to a gmail user, without worrying about the mail will come through - why should it be different with the also standardized instant messaging systems? Furthermore, e-mail can be read not only on the interface of freemail, but any POP3-compatible client can be used, like it's possible to use most jabber services without an always-open web-browser, at least a hundred client programs are there to choose from. A presence service available only on the interface isn't nearly full-featured, just like standardization - like in case of phones - means service provider and vendor independency.<br /><br />Therefore I would like to present the following requests. I know it isn't easy, politically it's often difficult to understand why it's worth and necessary to follow these steps; but if there's no other way, think of it that it's exactly what made the web "mashup-able", created the movement called "Web 2.0" that the service provider roles, the bindings of service and platform disappeared, separated from each other.<br /><br />Regarding the Freemail beta service, I would like to requests in order to improve the service quality:<br /><ul><br /><li><b>Instant subscribe feature</b>: IM solutions react immediately to the "Add contact" feature if the requested user is available. It isn't the main problem that the page must be refreshed after various kind of emails exchanged, buttons clicked etc, it is that this shouldn't be handled this way when the user is online.</li><br /><li>I would like to request to <b>open the 5222 port for desktop clients</b>. There's no marketing campaign needed, just let the advanced users advertise amongst freemail users that there's a world beyond MSN too. There's no need to develop an own client, just let talk about this. Load won't increase significantly, I could say that in case of what server software which steps could be done to achieve this, most possibly the web interface should be designed to handle hundreds of thousands of connections at the same time, there won't be that much desktop users at all.</li><br /><li>I know that this is the difficult part: I would like to request to <b>make freemail a part of the open jabber network:</b> I know that this is a serious strategic issue, but I would like to draw attention to the fact that e-mail can be exchanged with non-freemail users too. If it isn't possible, at least make it open to gmail; to hungarian jabber servers; for who already use jabber could talk to other users. If someone is to be converted to gmail, then she will, there's no photo gallery, postcard sending in it anyway, and everyone knows her freemail address. There's no progress if instant messages can only be exchanged inside freemail, let alone only from web.</li><br /></ul><br /><br />To clarify historical context: Google first introduced the (also jabber-based) Google Talk service, much earlier than it became a part of gmail. It was rumored that the fact the new service wasn't spreading as fast as expected played a significant role in this step. But it is really important to understand, that Google talk developers claimed on IM-spam (SPIM) when they didn't let connection with other jabber servers at the first time, but they tried to enable some level of federation from the beginning. For example, they were in server-federation with users of Gizmo project from start. Jabber has the methods, specifications regarding the fight against SPIM and harassments, which can also be found in extension protocols too.<br /><br />Any requests for help (whether it be technical kind, about the protocol and the surrounding software families, or strategical kind, about the concepts of the protocol and further extension possibilities) would be honestly given by me,<br /><br />Kind regards:<br /><br />Adam Nemeth, developer, jabbermania.blogspot.comAadaamhttp://www.blogger.com/profile/05843560041038857258noreply@blogger.com6tag:blogger.com,1999:blog-5123564397702144885.post-15239100447069896762007-03-30T14:11:00.000-07:002007-03-30T15:14:00.781-07:00MSN-compatible custom smiley handling in JabberIt's an ongoing university project run by me with the much appreciated help of <a href="http://www.saint-andre.com/blog/">Peter Saint André</a> and others. <br /><br /><a href="https://wiki.sch.bme.hu/bin/view/_Munka/JabberCustomSmileys">You can read about it here.</a>Aadaamhttp://www.blogger.com/profile/05843560041038857258noreply@blogger.com3tag:blogger.com,1999:blog-5123564397702144885.post-57372282098763010412007-03-30T13:42:00.000-07:002007-03-30T15:18:19.737-07:00Twitter posting bot implementationThis is a fast-and-dirty hack to enable posting to <a href="http://twitter.com">twitter</a>. It uses <a href="http://www.igniterealtime.org/projects/smack/index.jsp">Smack</a>, the java library <a href="http://www.igniterealtime.org/projects/openfire/index.jsp">OpenFire</a> (formerly WildFire) and <a href="http://www.igniterealtime.org/projects/spark/index.jsp">Spark</a> are built upon, and I used the same IDE (IntelliJ <a href="http://www.jetbrains.com/idea/">IDEA</a>) which is used by <a href="http://www.jivesoftware.com/">Jive Software</a> to implement their (wonderfully clean-coded) software.<br /><br />Basic "disadvantages":<br /><ul><br /><li>No bothering with config files (educational purposes) => account/password, admin hardcoded</li><br /><li>Also, since educational purposes - <b>public domain</b>! (you'd modify an existing source to learn jabber anyway)</li><br /><li>Uses apache's java <a href="http://jakarta.apache.org/commons/httpclient/">HTTP client library</a> - a simple auth to twitter and a POST</li><br /><li>User binds twitter account by sending a register <twitterusername> <twitterpassword> message to the bot.<br /><li>Doesn't save its state (bot stops => twitter account data lost)- could implement with Serializable markerinterface</li><br /><li>Doesn't use session-handling: logs into twitter every time; normally, twitter api would need to remember session cookies for each user/pass and trying to simply post the status variable, and if fails (with errorcode 403 presumably), relogin and store session cookies again</li><br /><li>No multithreading - if twitter is slow, the bot stops responding while doing HTTP query. Normally, at least two threads (one for the twitter api and one for the XMPP connection) should be used.</li><br /><li>No selective presence/multiple resources/etc - load balancing could be done with bots with same accounts but different resources and probably selective presence/invisibility</li><br /></ul><br /><br /><a href="http://centaur.sch.bme.hu/~aadaam/twitterbot01.tgz">You can download java sourcecode here.</a><br /><br />The needed libraries - which aren't in public domain(!) - are boundled too.Aadaamhttp://www.blogger.com/profile/05843560041038857258noreply@blogger.com15tag:blogger.com,1999:blog-5123564397702144885.post-20001912286847926352007-03-26T13:29:00.000-07:002007-03-30T15:22:38.044-07:00Jabber client example in KDE/QTThis is a small client I developed for educational purposes on top of <a href="http://kde.org">KDE</a> and <a href="http://camaya.net/gloox">gloox</a> (for simplicity) in C++.<br /><br />Basic ideas:<br /><ul><br /><li>Jabber data processing needs a loop and/or an event handler (depending on architecture). Most graphical systems will also need one, this can cause problems. In this example, we used QT's idle processing feature, which called a single cycle of Gloox's message processing. A kgloox wrapper class was written for this.</li><br /><li>In case writing a client application (not a bot or likesome), we need to connect conversations to windows. Most users feel comfortable that they have one window for each contact (or at least, each resource). Because of incoming messages, we'll need a mapping of contact -> window, and also a window->contact mapping. Although the second one could be stored in the window class itself in some environments, the first one will definitely need some window manager object. Some would argue that it's just a matter of observer pattern, but I'd say that it's easier to implement this way, because of contact we haven't opened a window for yet.</li><br /><li>In most of the time, we need to subscribe to specific kind of messages, like messages of specific type (message/presence), of specific origin (given user), or specific namespace (feature query). It's a good idea to have some general handling pattern of such - like, observer pattern, signal-slot mechanisms, or packet catchers/interceptors. It's also a good idea to make it either hierarchical or precisely catcheable (like a PresenceProcessor class catches all <Presence/> stanzas coming from a JabberConnection class, then individual viewports could catch for a specific user, ie. when a window is open with a given contact, it's a good feature that you could see when the contact goes away.)</li><br /><li>It's good to have separate layers of application: not all the components would be responsible, for example, processing of Jabber XML streams, nor all the layers have a hardwired reference of UI.</li><br /></ul><br /><p/><br /><a href="http://centaur.sch.bme.hu/~aadaam/kjabber.kdevelop-0.1.tar.gz">You can download the KDE source here.</a><br /><p/><br /><br /><b>Requirements for build:</b><br /><ul><br /><li>KDevelop, KDE libraries,etc</li><br /><li><a href="http://camaya.net/glooxdownload">gloox</a> (<a href="http://camaya.net/api/gloox-0.9-pre5/index.html">0.9-pre5</a>)</li><br /></ul><br /><br />It was coded with kdevelop because it's easier to write it in an IDE, it's c++, not javascript... ;)<br /><br /><b>Screenshots</b><br /><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiP0R-RysZS2ZR2MuLe0g6NtihpRAGUd0_5fwe60YMuHJ6dXttaUh3D5OBWpP0sqQNOkSit1VEsw7tMSHiu0WDPfotfVFGnFVnWLiRKBmeq3-8sJ2Eiabl6xvJlDPt3BsYrqjkDAj27wS4S/s1600-h/connected.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiP0R-RysZS2ZR2MuLe0g6NtihpRAGUd0_5fwe60YMuHJ6dXttaUh3D5OBWpP0sqQNOkSit1VEsw7tMSHiu0WDPfotfVFGnFVnWLiRKBmeq3-8sJ2Eiabl6xvJlDPt3BsYrqjkDAj27wS4S/s320/connected.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5047819254218707074" /></a><br /><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh8P7DBeG92st2Lr7zwWnGwY4GOzNzDV7G3Ziza6M2nLWvwDB7uRuO3KyBYvt1AsbZFV5YmQovNvs3tNPbwVSCHxfoNi4gOqkBJW137acj7sfN9EKpip_xgj5o4lxWZhEnRew-436D3Uf39/s1600-h/settings.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh8P7DBeG92st2Lr7zwWnGwY4GOzNzDV7G3Ziza6M2nLWvwDB7uRuO3KyBYvt1AsbZFV5YmQovNvs3tNPbwVSCHxfoNi4gOqkBJW137acj7sfN9EKpip_xgj5o4lxWZhEnRew-436D3Uf39/s320/settings.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5047819258513674386" /></a><br /><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh91MraG5kz7YZponV05PtpaWBRACJjdNHtRkddDMPDkmqrUejkAmrV0alKgeETPA2gj4A5f5eEqT7qXwjuLGTJC0xXwzkxtEozXsYr0Orl3STGFOhn0O_SlcmRVpAiW13YVdhBDT70WfqB/s1600-h/beszelgetes.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh91MraG5kz7YZponV05PtpaWBRACJjdNHtRkddDMPDkmqrUejkAmrV0alKgeETPA2gj4A5f5eEqT7qXwjuLGTJC0xXwzkxtEozXsYr0Orl3STGFOhn0O_SlcmRVpAiW13YVdhBDT70WfqB/s320/beszelgetes.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5047819258513674402" /></a>Aadaamhttp://www.blogger.com/profile/05843560041038857258noreply@blogger.com23tag:blogger.com,1999:blog-5123564397702144885.post-75496462291041920882007-03-25T06:37:00.000-07:002007-03-26T13:24:43.565-07:00Jabber introduction slidesI've created these slides for university, it's a short introduction to the jabber protocol.<br /><br /><b>Indented for</b>: techinical people, who heard of jabber, probably used it, but never went into "how it works" questions.<br /><b>Not indented for</b>: Those who now what iq, message and presence stanzas stand for :)<br /><br />Hungarian contains thesis examples too (MSN-like custom emoticon handling, music streaming as presence information, etc).<br /><br /><a href="http://jo-hely.hu/~aadaam/publications/jabber_onlab_bemutato.pdf">Hungarian version</a><br /><br /><a href="http://jo-hely.hu/~aadaam/publications/jabber_onlab_bemutato_angol2.pdf">English version (without thesis examples)</a>Aadaamhttp://www.blogger.com/profile/05843560041038857258noreply@blogger.com8tag:blogger.com,1999:blog-5123564397702144885.post-48502043387252131782007-03-25T04:59:00.000-07:002007-03-25T05:32:34.115-07:00Introduction<blockquote>A beginning is the time for taking the most delicate care that the balances are correct</blockquote><br /><i>Princess Irulan (Frank Herbert: Dune)</i><br /><br />Hi. My name is Adam Nemeth, known as Aadaam. I'm a software developer from Hungary, EU. For years I've been using ICQ, as it was the first instant messaging service, and for me, it was a standard, too. However, as years passed by, more and more instant messaging solutions came, the (at least in my viewpoint that time) ICQ-clone MSN Messenger, and the peer-to-peer VoIP software Skype.<br /><br />I first used Jabber protocol sometimes around 2004 or so: I heard of it before, and some of my friends used it ocassionally, but it was a struggle with icq-transports and clients of that time. But I realized that ICQ is just a service, and as more and more people starts using instant messaging every day, we need to consider it as a part of a communication solution - most of the universities, student clubs were already providing e-mail and webhosting services, as well as some forum and so on. Realtime is getting closer as our life gets faster every day.<br /><br />When Google introduced its XMPP-service called Google Talk, I was way in jabber: I knew how to use the protocol with a pure telnet, knew how to write a client and even had some ideas how to use it on web with XEP (or, at that time JEP) 124. Now I see it as a communication standard.<br /><br />But much work has to be done: for example, it's not clear how we could use alias and forwarding features of e-mail. It's not clear how we could connect to accounts to each other. Practically only ejabberd provides virtual hosting, and erlang is an unusual language for an average programmer working with imperative code like Java or C++ or whatever.<br /><br />There's also a problem with the protocol design itself: given that you have a heterogenous network with all kind of clients, the interoperability between those is the intersection of the supported XEPs of all clients; as more and more clients come in, it gets worse. We need to bundle the logic with the XEP itself, and there are some very good experiments out there for such.<br /><br />We also need to make jabber easier to spread: embeddable clients in webpages, open hosting providers, etc... its not as easy as it seems but it can be done. Also we need a lot of features from other networks - in Hungary, mostly MSN is used today, because of custom smiley handling, for example. Teens love it, and can't imagine a client without that feature- it'd be 'boring'.<br /><br />This blog will focus on mainly three topics: first, and not least, possible use cases on jabber services. Then protocol implementation examples, with simple, educational scripts in GPL or even public domain. And also there'll be some discussions about possible new protocol extensions, like the above mentioned custom smiley protocol I'm designing.Aadaamhttp://www.blogger.com/profile/05843560041038857258noreply@blogger.com6