Slashdot Mirror

XMPP (formerly known as Jabber) has been around since 1999 and has most if not all of these features. Any it is missing can be submitted and added as it's an open standard. Google has essentially embraced its role as the new Microsoft and has begun their EEE march. Chrome has become the new IE6 with all of the non-standard extensions they've rolled out without so much as submitting anything to W3C for consideration. I'm now looking for alternatives to all Google properties.

Why not just audit https://xmpp.org/ and call it good?

As a programmer, i have had to read a many white papers and technical specifications. For a work project I started writing a perl script that used XMPP protocol to send messages to co-workers on a OPENFIRE server. For this I had to read the XMPP specifications, and OH MY GOD are they the most beautifully written and clearly explained technical documents I have ever had the privilege of reading: https://xmpp.org/rfcs/rfc6120....

And developing apps using the XMPP protocol was super easy and fun. Sadly, the protocol was mostly abandoned due to lack of features we have seen in proprietary implementations. E.g. XMPP clients don't have universal support for in-lined pictures and video (showing someone embedded youtube video or the picture instead of http://imgur.com/aabbbaa or http://youtube.com?watch=blah) It has no support for video messaging (it was build for chat and IM) nor does it have support for screen-sharing. Also if you close your XMPP client and someone sends you a message, you don't get that message when you log in again. Some servers implement an extension that kinda does this, but because its not an official part of the XMPP protocol its spotty and unreliable. Various XMPP clients tack one or multiple of these features onto the XMPP spec, but this fragmented support tends to drive people away instead of too it.

But if ALL you want is a protocol for real-time chat rooms and instant messaging of text-only, man is XMPP fantastic, cheap, easy to use, and reliable.

remember XMPP?

What's the end-user alternative?

What we really need is to make a concerted effort towards replacing all these centralized web services with distributed equivalents:

• Google Search -> YaCy
• Gmail, Google Drive, etc. -> OwnCloud
• Google Maps -> OpenStreetMap
• Hangouts -> XMPP
• Youtube -> ???
• Facebook -> Diaspora
• Etc...

http://xmpp.org/rfcs/rfc3923.h...

Seriously, stop using proprietary carpware.

Its one thing when proprietary offers you some benefit, but when it comes to IM, using anything other than XMPP from someone who supports federation is just as retarded as using email from someone who doesn't do proper SMTP.

In addition to the Google Talk client, there are many other clients out there that provide a great communications experience. We believe users should have choice in which clients they use to connect to the Google Talk service and we want to encourage the developer community to create new and innovative applications that leverage our service. To enable this, Google Talk uses the standard XMPP protocol for authentication, presence, and messaging.

What does this mean for those who care about security? For one, you can choose software that includes Off-the-Record end-to-end encryption (OTR) such as Pidgin with the OTR plugin on GNU+Linux or Windows, or Adium (which has OTR built-in and enabled by default) on Mac OS X. On Android you can use Beem or Gibberbot, although I personally recommend Beem (and if you are using iOS you obviously don't give a shit about security anyway). By using OTR, Google has no idea what you are typing, even as you use their servers to send & receive XMPP data. As a bonus, you can proxy any of these applications over Tor, so Google has no idea where you are even connecting from, anonymising your IP address.

Because of the benefits of an open protocol, the fact that Google is in the US is far less of a problem than Microsoft being in the US because Skype by design restricts your ability to know how it communicates with Microsoft's supernodes and other Skype clients. This is the very nature of proprietary software: to subjugate you, keep you ignorant, and wield power over you. Google may not be perfect, but at least they are committed to using open standards as the base level of their communication networks, and explicitely encourage people to use what software they want, allow proxied and/or Torified connections to their services, & allow you to use end-to-end encryption with crypto keys that YOU control.

TL,DR:

I am very happy to find out a friend has a Google account, so that as soon as they use it with OTR encryption, I can communicate with them safely & securely from my own XMPP server with end-to-end encryption using an standard, open protocol. Incomparably better than Skype.

In addition to the Google Talk client, there are many other clients out there that provide a great communications experience. We believe users should have choice in which clients they use to connect to the Google Talk service and we want to encourage the developer community to create new and innovative applications that leverage our service. To enable this, Google Talk uses the standard XMPP protocol for authentication, presence, and messaging.

What does this mean for those who care about security? For one, you can choose software that includes Off-the-Record end-to-end encryption (OTR) such as Pidgin with the OTR plugin on GNU+Linux or Windows, or Adium (which has OTR built-in and enabled by default) on Mac OS X. On Android you can use Beem or Gibberbot, although I personally recommend Beem (and if you are using iOS you obviously don't give a shit about security anyway). By using OTR, Google has no idea what you are typing, even as you use their servers to send & receive XMPP data. As a bonus, you can proxy any of these applications over Tor, so Google has no idea where you are even connecting from, anonymising your IP address.

Because of the benefits of an open protocol, the fact that Google is in the US is far less of a problem than Microsoft being in the US because Skype by design restricts your ability to know how it communicates with Microsoft's supernodes and other Skype clients. This is the very nature of proprietary software: to subjugate you, keep you ignorant, and wield power over you. Google may not be perfect, but at least they are committed to using open standards as the base level of their communication networks, and explicitely encourage people to use what software they want, allow proxied and/or Torified connections to their services, & allow you to use end-to-end encryption with crypto keys that YOU control.

TL,DR:

I am very happy to find out a friend has a Google account, so that as soon as they use it with OTR encryption, I can communicate with them safely & securely from my own XMPP server with end-to-end encryption using an standard, open protocol. Incomparably better than Skype.

In addition to the Google Talk client, there are many other clients out there that provide a great communications experience. We believe users should have choice in which clients they use to connect to the Google Talk service and we want to encourage the developer community to create new and innovative applications that leverage our service. To enable this, Google Talk uses the standard XMPP protocol for authentication, presence, and messaging.

What does this mean for those who care about security? For one, you can choose software that includes Off-the-Record end-to-end encryption (OTR) such as Pidgin with the OTR plugin on GNU+Linux or Windows, or Adium (which has OTR built-in and enabled by default) on Mac OS X. On Android you can use Beem or Gibberbot, although I personally recommend Beem (and if you are using iOS you obviously don't give a shit about security anyway). By using OTR, Google has no idea what you are typing, even as you use their servers to send & receive XMPP data. As a bonus, you can proxy any of these applications over Tor, so Google has no idea where you are even connecting from, anonymising your IP address.

Because of the benefits of an open protocol, the fact that Google is in the US is far less of a problem than Microsoft being in the US because Skype by design restricts your ability to know how it communicates with Microsoft's supernodes and other Skype clients. This is the very nature of proprietary software: to subjugate you, keep you ignorant, and wield power over you. Google may not be perfect, but at least they are committed to using open standards as the base level of their communication networks, and explicitely encourage people to use what software they want, allow proxied and/or Torified connections to their services, & allow you to use end-to-end encryption with crypto keys that YOU control.

TL,DR:

I am very happy to find out a friend has a Google account, so that as soon as they use it with OTR encryption, I can communicate with them safely & securely from my own XMPP server with end-to-end encryption using an standard, open protocol. Incomparably better than Skype.

While you're generally correct, at least in IM a standardization process has been happening. Google, Facebook and MSN have adopted the XMPP protocol (RFC 6120) for chatting. Once you have a generic XMPP client, it's easy to connect to those networks (well, some coding is required for MSN and recommended for Facebook to use their oauth implementations, but that's trivial compared to implementing a whole new protocol).

All except Google's are still walled gardens, but I guess that's company policy.

It is feature that is partially targetted to the deaf, too. The spec introduction even explains benefits for the deaf:
http://xmpp.org/extensions/xep-0301.html [xmpp.org]
"Real-time text is text that is sent as it is created. The recipient can watch the sender type "as written words are typed" – similar to a telephone conversation where one listens to a conversation "as words are spoken". It provides a sense of contact in conversation, eliminates waiting times found in messaging, and is also favored by the deaf who prefer text conversation. For a visual animation of real-time text, see RealJabber.org [1]."

There's an excellent reason for the XML (in)elegance.
- We first tried a compact binary protocol, base64 encodings, and other alternate encodings.
- But, XMPP prefers XML-based protocols.
- We wanted ease of software development, so ease outweighed a lot of factors.
- Deaf-friendly: Something that can be added to existing traditional chat interfaces in existing chat software (much like AOL's proprietary Real-Time IM, but as an open standard). It can be turned on/off
- We chose delibrately short XML tags to reduce bandwidth. Yes, that does not follow XML philosophy in naming, but it is a bandwidth compromise.
- We delibrately avoided using tag names of existing HTML tags, even though this is a different XML namespace. We avoided <b> and <i> anyway.

First, see the animated GIF of this real-time text protocol, to see some of the reasons why this XML was chosen:
http://www.marky.com/realjabber/real_time_text_demo.html

Now read section 7.1 through 7.9 of the XEP-0301 specification:
http://xmpp.org/extensions/xep-0301.html#action_elements

As you can watch in the animation,
<t> is insert text, to support transmission of key presses, text block inserts, and text being pasted.
<e> is backspace.
<d> is delete key (forward delete), or cutting / deleting blocks of text
<c> is cursor positioning (optional)
<w> allows transmitting of key press intervals, so that one packet can playback 10 keypresses naturally. XEP-0301 is the world's first real time text standard that packetizes the delays between the key presses, so you can transmit only a few packets per second. And yet keep the typing smooth.
<g> is for backwards compatibility with similiar features like Yahoo Buzz, MSN Nudge, BlackBerry Ping, Jabber XEP-0224 Attention, etc. It is very deaf-friendly and this is optional and can be turned off, but some like this feature.

More info about these action elements:
http://xmpp.org/extensions/xep-0301.html#action_elements
Only the first 3 XML elements are required (insert, backspace, and delete)

So as you can observe, there is excellent rationale for the "turd" we had to use. It is for instant messaging conversations, not for things like Google Wave, and is rather instead an optional add-on to existing instant messaging that can be turned on/off.
http://www.marky.com/realjabber/real_time_text_demo.html

There's an excellent reason for the XML (in)elegance.
- We first tried a compact binary protocol, base64 encodings, and other alternate encodings.
- But, XMPP prefers XML-based protocols.
- We wanted ease of software development, so ease outweighed a lot of factors.
- Deaf-friendly: Something that can be added to existing traditional chat interfaces in existing chat software (much like AOL's proprietary Real-Time IM, but as an open standard). It can be turned on/off
- We chose delibrately short XML tags to reduce bandwidth. Yes, that does not follow XML philosophy in naming, but it is a bandwidth compromise.
- We delibrately avoided using tag names of existing HTML tags, even though this is a different XML namespace. We avoided <b> and <i> anyway.

First, see the animated GIF of this real-time text protocol, to see some of the reasons why this XML was chosen:
http://www.marky.com/realjabber/real_time_text_demo.html

Now read section 7.1 through 7.9 of the XEP-0301 specification:
http://xmpp.org/extensions/xep-0301.html#action_elements

As you can watch in the animation,
<t> is insert text, to support transmission of key presses, text block inserts, and text being pasted.
<e> is backspace.
<d> is delete key (forward delete), or cutting / deleting blocks of text
<c> is cursor positioning (optional)
<w> allows transmitting of key press intervals, so that one packet can playback 10 keypresses naturally. XEP-0301 is the world's first real time text standard that packetizes the delays between the key presses, so you can transmit only a few packets per second. And yet keep the typing smooth.
<g> is for backwards compatibility with similiar features like Yahoo Buzz, MSN Nudge, BlackBerry Ping, Jabber XEP-0224 Attention, etc. It is very deaf-friendly and this is optional and can be turned off, but some like this feature.

More info about these action elements:
http://xmpp.org/extensions/xep-0301.html#action_elements
Only the first 3 XML elements are required (insert, backspace, and delete)

So as you can observe, there is excellent rationale for the "turd" we had to use. It is for instant messaging conversations, not for things like Google Wave, and is rather instead an optional add-on to existing instant messaging that can be turned on/off.
http://www.marky.com/realjabber/real_time_text_demo.html

Hello --

Some general comments that addresses common comments:

(1) This is an optional feature that can be turned on/off.
You only use it when you want it, so you don't have to show off your typos to everyone, if you don't want to.
Just like audio can be turned on/off and video can be turned on/off.

(2) It is feature that is partially targetted to the deaf, too. The spec introduction even explains benefits for the deaf:
http://xmpp.org/extensions/xep-0301.html
"Real-time text is text that is sent as it is created. The recipient can watch the sender type "as written words are typed" – similar to a telephone conversation where one listens to a conversation "as words are spoken". It provides a sense of contact in conversation, eliminates waiting times found in messaging, and is also favored by the deaf who prefer text conversation. For a visual animation of real-time text, see RealJabber.org [1]."

(3) It's not inefficient in message rate. It is only one packet per second, no matter how fast you type, even 30 keypresses per second (holding a key down). As far as I know, this is the world's first real-time text protocol that preserves key-press delays for chats. This means typing still looks smooth, even at low packet rates (1 packet per second), even if you are typing at 10 or 30 keypresses per second. Even over a satellite connection, or even over a dial-up connection (while an FTP is going on in the background), or over a mobile phone connection that has intermittent reception and variable ping latency.

(4) There is an animation of the key press intervals (delay coding) at:
http://www.marky.com/realjabber/real_time_text_demo.html

(5) Some existing software already have this feature, that you may not notice, because it's off by default. For example, AOL Instant Messenger's "Real-Time IM" feature is a proprietary version of real time text, while XEP-0301 is an open standard that anyone can use for Jabber-based networks.

I know. :-)
One thing though, that isn't HTML, it's XML over XMPP. We used a binary code at first for XEP-0301, until I realized XMPP encouraged XML. Our task group chose one-letter XML elements, to save some bandwidth. Key press interval elements ended up being the best way to transmit real-time text, at only 1 packet per second (protecting the network), while fully preserving key-press delays, so that typing comes out naturally, thanks to the delay elements:
http://xmpp.org/extensions/xep-0301.html#key_press_intervals

See examples 7.1 through 7.9:
http://www.xmpp.org/extensions/xep-0301.html

As well as the animation of smooth typing (non-bursting text) even at just 1 packet per second:
http://www.marky.com/realjabber/real_time_text_demo.html

I know. :-)
One thing though, that isn't HTML, it's XML over XMPP. We used a binary code at first for XEP-0301, until I realized XMPP encouraged XML. Our task group chose one-letter XML elements, to save some bandwidth. Key press interval elements ended up being the best way to transmit real-time text, at only 1 packet per second (protecting the network), while fully preserving key-press delays, so that typing comes out naturally, thanks to the delay elements:
http://xmpp.org/extensions/xep-0301.html#key_press_intervals

See examples 7.1 through 7.9:
http://www.xmpp.org/extensions/xep-0301.html

As well as the animation of smooth typing (non-bursting text) even at just 1 packet per second:
http://www.marky.com/realjabber/real_time_text_demo.html

This feature can be turned on/off.

It is a feature that is very friendly to the deaf, as the spec even mentions deaf people in the introduction of the specification document.
http://xmpp.org/extensions/xep-0301.html
"Real-time text is text that is sent as it is created. The recipient can watch the sender type "as written words are typed" – similar to a telephone conversation where one listens to a conversation "as words are spoken". It provides a sense of contact in conversation, eliminates waiting times found in messaging, and is also favored by the deaf who prefer text conversation. For a visual animation of real-time text, see RealJabber.org [1]."

It's a good assistive technology feature for the deaf too. In fact, the Introduction also mentions its use by the deaf, too:
http://xmpp.org/extensions/xep-0301.html
"Real-time text is text that is sent as it is created. The recipient can watch the sender type "as written words are typed" – similar to a telephone conversation where one listens to a conversation "as words are spoken". It provides a sense of contact in conversation, eliminates waiting times found in messaging, and is also favored by the deaf who prefer text conversation. For a visual animation of real-time text, see RealJabber.org [1]."

- It's an optional feature, that can be turned on/off as usage warrants
- Just like audio can be turned on/off, and video can be turned on/off, real-time text can be turned on/off
- It utilizes traditional instant messaging UI, too.

It's also found in AOL Instant Messenger's Real-Time IM
http://help.aol.com/help/microsites/microsite.do?cmd=displayKC&externalId=223568
However, we all wanted an open standard, that works on unmodified Jabber/XMPP, and that is how XEP-0301 got developed.

I actually thought of this.
XMPP real-time text is the world's first real time text protocol that encodes key press delays:
http://www.marky.com/realjabber/real_time_text_demo.html

So even at 10 keypresses per second, even over a satellite connection (or other high-latency bursty connection), it only needs to transmit 1 packet per second, and the typing comes out naturally.

XEP-0301 (the protocol) is a packetization of typing including typing delays, much like VoIP packetizes short snippets of audio.
Explained in first section in section 6:
http://xmpp.org/extensions/xep-0301.html#implementation_notes

Do you really think that matters? The transmitted XML is smaller than the IPv6 header, the TCP header, the ethernet frame headers, etc.

But if you really care, you can use compression schemes to reduce it. The gzip that's currently supported won't help for small messages, but it might help for this:

http://xmpp.org/extensions/inbox/compress-exi.html

I have been looking for XMPP alternatives for Skype for a good while. Jingle using SRTP does look good. http://xmpp.org/extensions/xep-0167.html#srtp

Maybe I missed it, but I find it interesting that the patent doesn't explicitly state what a social networking service *is*. Sure, we all "know" what it is -- but in something like a patent shouldn't this be very clearly defined? What if a "social networking service" encompasses presence/IM/chat software? The XMPP protocol (Jabber, now owned by Cisco, is based off this) has drafts (see XEP-0080) already written for providing user location in that context. I'm sure this isn't the only draft written of its kind. Think of large enterprise solutions such as Microsoft OCS, Cisco Unified Presence, Avaya OneX. I bet they all have location solutions in the works. Do these fit into the realm of "social networking services"?

If the developers set out to create an API, protocol, or specification, and then simultaneously released an initial implementation, this might be less of a big deal.

Take XMPP for example. It is a specification, and there are many implementations to choose from to run a Jabber server. Different languages, platforms, and features are up to the user to choose.

A well documented API, supplemented by buggy code, would be best. If you don't want to hack Ruby, implement the spec in your language of choice.

If you think XMPP is only about instant messaging, you haven't looked into the protocol at all. I'm actually on facebook, so I know very well what's required for a direct competitor.

Here, let me help you with the spec on pubsub via XMPP.

In other words: Maybe you should brush up on just what this XMPP is all about before you comment.

So true. Here are some other (more mature) projects that DO put focus on protocols.

http://ostatus.org/
http://opensource.appleseedproject.org/
http://techcrunch.com/2010/05/13/onesocialweb-were-ahead-of-diaspora-in-the-creation-of-an-open-facebook/

See also:
http://xmpp.org/xmpp-protocols/xmpp-core/

So, do Jabber servers all talk to each other like email servers?

They do actually.

I thought that was the last bit of the equation that didn't take off....I know all ISPs run email servers, but few-to-none run XMPP servers...

There's a bunch. And GTalk is Jabber.
And there's Facebook chat, but it doesn't talk to other servers .. yet.

And you can run your own if you want. Which I do, and I can can talk to people on MSN (and other networks if I had contacts on those).

Currently there's only a OSW-plugin for one of the server implementations, but that will probably come.

So, do Jabber servers all talk to each other like email servers?

They do actually.

I thought that was the last bit of the equation that didn't take off....I know all ISPs run email servers, but few-to-none run XMPP servers...

There's a bunch. And GTalk is Jabber.
And there's Facebook chat, but it doesn't talk to other servers .. yet.

And you can run your own if you want. Which I do, and I can can talk to people on MSN (and other networks if I had contacts on those).

Currently there's only a OSW-plugin for one of the server implementations, but that will probably come.

What we need is a standard. Look at the social@xmpp.org email list for a discussion. Using XMPP, OpenID, and OAuth, you could pretty much solve this problem. Look, someone has!

The GP's link is to the website for PSYC, which, among other things, is a replacement server-to-server protocol for XMPP, which fixes many of the problems they list. Also a sibling points out that XMPP apparently has its own fix in XEP-33 (XEP=XMPP-specific RFC, basically).

Telepathy/Empathy also supports Jingle. Coccinella (two "c"s) supports Jingle, but uses IAX as the transport, so you won't be able to chat with most other people.

By the way, the base Jingle spec is XEP-0166, and was just recently advanced to "Draft" status.

It has been a while since I posted on slashdot, but I could not resist because this is WHAT I DO (but WHITEHAT)

Here are some references: (Please be careful with MODS - these are NOT links to my sites]
http://www.linux.com/archive/feature/140576
http://digg.com/tech_news/The_Drupal_com_domain_has_been_donated_to_Dries_Buytaert
http://xmpp.org/xsf/press/2005-12-30.shtml

Here is my simple advice:
You are screwed.

The squatters won long ago - THEY know the rules:
1) Register a domain
2) Be careful!
      a) Do not put up infringing content
      b) Put up a 'search' page to generate some profit
      c) Do not offer to sell, just wait
      d) Hide in another country with nicer rules for scammers if possible
3) Profit!

Here are my suggestions
1) Choose a different domain
      a) Choose another Top Level Domain , may I suggest .TV ? (I may be biased as I bought the first premium dot TV domain)
      b) I can offer some for FREE for Open Source communities (Notice: No link to me - just google for OpenDomain )
      c) Try different variations of the brand
2) Suck it up and pay.
  a) Lease the domain
  b) Negotiate - a lawyer may help if you DO have IP

Good luck!

Ekiga (http://www.gnomemeeting.org/) does video chat for Linux under Gnome. I'm sure KDE has a similar application. In addition, the Jingle protocol has been developed to allow voice and video chat over XMPP. It works now, and is usable with a number of clients on Windows, Mac, or Linux, which you can find on that page.

Since we are talking XMPP/Jabber, I would be interested to see the User Gaming specification implemented by XMPP messengers. This would make a nice open cross-platform alternative to XFire and the likes.

I noticed someone elsewhere suggested implementing this and then grafting a XFire compatibility layer around it, so that people could migrate to the open platform.

Is this something that would interest any /.ers?

Okay:

MediaWiki
WordPress
Jabber
Zimbra ...

Get it?

This is about using open source software for internal, noncommercial, nonprofit purposes.

http://xmpp.org/extensions/inbox/microblogging.html

Yeah because you can't talk with people using MSN, ICQ, so on so on as long as they have an MSN, ICQ-compatible client and an account for that ..

An account for that... on MSN. Accounts on those networks are tied to the operator of the network. XMPP is decentralised, like email, so ISPs can provide their own servers, or you can use your own server.

I'd like to try to convince people to use XMPP but as long as it don't support voice and webcam there is no reason to even try.

XMPP supports voice and video through the Jingle extension, which originally came from and is supported by GTalk, if I recall correctly.

I've worked with XMPP, and despite having it's own organization devoted to developing the standard, it suffers from a lot of issues regarding actual standardization. Most of these issues are in the form of deprecated extensions. I think that will be the biggest hurdle for XMPP - yay standardization and open source and all that, but when old clients do things in a deprecated way and new clients do things the right way and don't bother with the deprecated features (because they're deprecated) then you start having some issues. Just look at all the extensions and tell me that this is a viable protocol for interoperability: http://www.xmpp.org/extensions/

So much of AJAX is making a polling protocol (HTTP) look like a push protocol. What really needs to happen is that browsers and the "web" need to adopt a push protocol like XMPP Publish-Subscribe http://www.xmpp.org/extensions/xep-0060.html to augment HTTP.

Your best bet is Jabber (XMPP). You'll be familiar with it as Google Talk, but it's a standard protocol that's been around a lot longer than Google's service.

Jabber doesn't seek client-to-client connections. This is a nightmare to achieve with "modern" IPv4 networks, which are full of flakey firewalls, NAT setups of varying levels of insanity, etc. What it does do is let you control your own server or use one you trust.

There actually is a
direct client to client facility for Jabber, but I don't know how widely the extension is implemented.

Jabber/XMPP also supports encryption - both at the transport level using SSL (for if you trust the server but not the network) and at the message level using various public key schemes.

XMPP gets you everything you've just asked for. In fact, with XMPP you can do offline message storage, and nothing special even needs to be done in the client.

XEP-0013

In Jabber, you can used both Off-The-Record encryption, and GPG, depending on what the client supports. There's also a much newer standard for encrypted sessions, but I don't know if it has any support yet. http://www.xmpp.org/extensions/ XEP-0116 and XEP-0200 are related to the new one.

There's one hosting provider here in the US in a similar kind of ex-military facility: http://usshc.com/
They host the jabber.org project: http://www.xmpp.org/xsf/sponsors/

But anyway, the biggest thing the "X" buys you is a lot of extensions. I'd say it's actually delivering on what it promises.

the only problem beeing, that those are pseudo extensions which were simply written down in an specification but never implemented..

(give me one client/server combo which supports pub sub ?) ... (i love xmpp, i'm using jabber as my main IM (with a couple of gateways), have written a jabber client, a jabber bot and a jabber <-> xfire gateway .. but i'm either too dump or too impatient to implement pub sub (and.. i once tried to implement it on my client .. but i couldn't find a server properly supporting it)) .. i'm pretty sure that 95% of all those "extensions" were never proved to work anyway ..

Documentation: http://www.xmpp.org/

As far as implementations, there are 3 major Open Source servers: ejabberd (Erlang), OpenFire (aka WildFire, written in Java) and jabberd2 (C), not to mention djabberd, LiveJournal's Perl-based jabber server framework.

Yes, because RFC 822 header fields are the pinnacle of parser research. Have you ever tried to write your own mail client? Have you ever tried to write your own mail server? By comparison, I'm pretty sure I could knock out a minimal compliant XMPP server in an afternoon, and it would support Unicode for free.

But anyway, the biggest thing the "X" buys you is a lot of extensions. I'd say it's actually delivering on what it promises.

Didn't understand how to use the library? The problem is, there are a ton of XMPP libraries out there for every language (the one you used is for javascript) and there must be an unwritten agreement that it's no use for each library to re-explain the workings of XMPP...

The best way, I'm afraid, is to read the RFCs (mostly 3920 and 3921. There are updated, clearer drafts, 3920bis and 3921bis, a link away from that page) and XEPs (XMPP Extension Proposal). There's also a book, but I heard that it's a bit outdated.

Didn't understand how to use the library? The problem is, there are a ton of XMPP libraries out there for every language (the one you used is for javascript) and there must be an unwritten agreement that it's no use for each library to re-explain the workings of XMPP...

The best way, I'm afraid, is to read the RFCs (mostly 3920 and 3921. There are updated, clearer drafts, 3920bis and 3921bis, a link away from that page) and XEPs (XMPP Extension Proposal). There's also a book, but I heard that it's a bit outdated.

with pubsub in place, an implementation of e.g. XEP-0154 [1] could easily be used to make privacy-enabled decentralized online social networking possible. the privacy fetishists could have all data on their own server and for the uninformed masses, well some web 2.0 crackpot could surely provide a web frontend ...

[1] http://www.xmpp.org/extensions/xep-0154.html

OpenPGP and OTR encryption are offered in many clients, and only have to be supported on the client. Clients supporting OpenPGP can also used signed presence. http://www.xmpp.org/extensions/xep-0027.html, although historical, is used by a few of the more popular clients, although, certainly not universally. OTR also has a strong following - I'm not sure if it's as broad as OpenPGP support. Finally, S/MIME support over XMPP apparently exists in RFC form, but I'm not aware of any widespread implementation.

This is in addition to TLS/SSL being used whenever available between client-server and server-server (which, still lets the server inspect messages, but at least protects from casual eavesdropping on the wire).

The problem really remains getting people to use encryption properly on their clients, and as email has shown, despite OpenPGP and S/MIME being available for more than a decade, they aren't widely used outside certain communities, because the average end user values convenience above security.

All of the features you request are part of the XMPP standard, although client support varies. Most support message archiving (it was one of the first things I implemented in mine; I hate not being able to search a conversation history, I wish I could with telephones and IRL discussions) and there are components available for server-side logging (which you may be required to run by law if you are using IM for business correspondence). Forwarding, multiple recipients and BCC are supported by XEP-0033.