Add support for Jabber transports

[mmassonnet@…]

As in the title, add support for Jabber transports.

Sometimes transports gets disconnected from Jabber accounts, and I need to open a graphical Jabber client (e.g. Gajim) to reconnect it. It would be great to be able to connect/disconnect from bitlbee.

Regards, Mike

[aaronmgriffin@…]

This feature is the only real reason I stopped using bitlbee and started using mcabber.

I know a lot of people say "just connect to AIM through bitlbee, why use jabber to do it?" and I will explain the reasoning.

Jabber is superior when it comes to figuring out which client gets the message. AIM, on the other hand, gets goofy, yells at you about multiple connections to the same account, and things of that nature.

Me, I maintain a stable IM connection at home, and also connect from work. Without using Jabber transports this gives me somewhere in the realm of 1000 different issues.

So now I am "forced" to use mcabber at home in order to properly work with transports.

[flux at Source Mage org]

This has been a bug for some time, and I'm interested in having support for this. I love bitlbee, and use it for all of my chatting. One of the reasons I use it is because it enables me to do all of my chatting without ever using a graphical chat program (except for rare occasions when I really have to, I run console-only, and would prefer to keep it that way). I'd love to try out different jabber transports, but this is currently impossible for me without making use of another client/gateway.

Additionally, having jabber transport support may ease the pressure on releasing bitlbee whenever one of the protocols gets changed (Yahoo! for example), as there may be a backup solution via the transports, giving you a little more time to concentrate your efforts on other bugs/features/issues.

[ruskie-bitlbee at codemages.net]

I agree proper transport support would really make bitlbee the be-all for the lot... Much more usable than file transfer...

[anonymous]

So how hard would it be? My main concern is that I don't want to support features that are specific to only one IM protocol. If there's a way to do this without cluttering the UI too much with something most users wouldn't care about, I'd probably be happy to implement this (given enough time, etc).

[wilmer]

(Oops, forgot to log in. :-/)

[anonymous]

Replying to anonymous:

So how hard would it be? My main concern is that I don't want to support features that are specific to only one IM protocol. If there's a way to do this without cluttering the UI too much with something most users wouldn't care about, I'd probably be happy to implement this (given enough time, etc).

Wouldn't this at least in part depend on how you choose to implement it? However, as to whether bitlbee supports features specific to only some protocols, it already does. For example, account settings and even account adding can vary depending on which protocol is being used (account add jabber ... can take a specific server as an argument according to the help info, for example).

[ruskie-bitlbee at codemages.net]

well from what I understand the jabber transport sends an xml file describing all the possible options and passes that on to the client. The client then renders that as it wants to for itself.

The way I see it.

Bitlbee needs to have a setting to enable to show transports(usually they show up as protocol$domain but all aren't displayed always)

As for reducing UI clutter...

I'm thinking the best bet would be to have transports configured by querying the transport then setting everything in there that way UI clutter isn't really an issue as everything is set there. The only thing added to the UI is adding a service discovery system that would allow to register with such services and to get an initial query going with a service(since it wouldn't be shown yet).

​http://xmpp.org/protocols/disco/

[Wilmer van der Gaast <wilmer@…>]

However, as to whether bitlbee supports features specific to only some
protocols, it already does. For example, account settings and even account
adding [...]

Account settings are indeed the one place right now where
protocol-specific things can be implemented without too much clutter.
There are no extra API hooks required or anything like that, an IM
module can just add an additional variable to its setting list.

The server argument to "account add" is somewhat there for historical
reasons (and used to be used by OSCAR as well). Now that there is
"account set", I'm actually thinking of killing the server argument.

[wilmer]

BTW, ruskie, with the new version of Trac you're actually better off posting with your full e-mail address here. Trac will recognize it and hide the @ to everyone except its internals and admins. I don't know how effective replacing an @ with "at" is these days, some people say spammers are "smart" enough to understand that for some time already. :-/

Anyway, yes, I kind-of knew the main thing in BitlBee missing for supporting transports is showing a dialog box based on some XML data. Which is quite a hard thing to do in BitlBee, obviously because it doesn't have a GUI, and also because it's hard to do stateful user interaction.

[ruskie-bitlbee@…]

Well I can easily block stuff coming through that alias so no big issue ;) That's why I have it setup like that... instant aliases ;)

As for the dialog... why not just read it in as set params to the transports handle?

So if one has msn$domain transport nick in the chan they would be able to query it and do: set and get a list of all the settings...

:)

[MentalFS <bitlbee-bugs@…>]

I don't know if this is new, but transports seem to work for me. I just had to set them up with a different client (in my case it was possible with a web client).

The only thing I miss is setting myself to "offline" for one specific Jabber contact (the one representing the transport) to disable it temporarily. And the vcards, but that seems to work elsewhere so I deem the admins of nimbuzz responsible.

[flux sourcemage org]

I have an idea for how to implement this in a clean way that would fit with the bitlbee UI. Why not make a command slist or similar (services list) which presents a tree of services (or at least a non-hierarchical dump) similar to blist? It could be allowed to take server arguments to present the services for the server(s) specified, or otherwise default to the connected server(s).

This may not be 100% optimal, since it would obviously only be immediately useful for XMPP. However, at least at one point other IM protocols (in particular ICQ) include support for other "services" like playing games and whatnot. I haven't really used these other protocols in quite some time, so I'm not what the present state with them is. I'll base the present discussion on what I know from older times. The server argument could be used to point to individual users/accounts to query what they are capable of participating in. Other clients already had this functionality, as they would disable (grey out) options if the other side of the connection didn't support the function. This also applies to XMPP, as any XMPP entity (client or server) is supposed to be able to respond to service discovery (even if it's a simple rejection) as far as I know. Then there could be a service command which would interact with the service, though obviously that would have to be protocol specific, even if the different protocols could really be abstracted to all have "services".

If you would rather keep such functionality separate, then why not implement it as an actual IRC command (/list comes to mind). Since all the other bitlbee UI functionality is implemented specifically as not IRC commands, anyone not specifically looking for XMPP functionality would likely never know about this. For XMPP users, it might be less intuitive and therefore harder for them to find out about, but considering the present situation (no functionality at all), I'd rather have something implemented and have some people not know it's there than not have the possibility for it at all.

If you like any of these ideas and you give me pointers on where to start, I'll code it (though I won't be able to finish doing so immediately, as I am about to relocate).

This bug is now 3 years old. I have never moved away from bitlbee, but the ability to use transports effectively without having to rely on an additional client is starting to be more of a core factor for me. Personally I'd rather have an IRC interface to everything else, but if it can't get done then I'll switch to having an XMPP interface to everything (including IRC) and use another client. :(

[gunnar_thielebein@…]

Hi I just had the issue that on deleting and (re-)adding a jabber account the subscribed icq gateway within that jabber account went away. Is this belonging to the issue described here?

[anonymous]

Bumping this ticket... Is there really still no way for jabber users to talk to YM users, from Bitlbee?

Bummer! I refuse to sign up for a Yahoo account.

[ruskie]

This won't make it possible to chat without a yahoo account. Just makes it possible to use Jabber transports to do so instead of using separate accounts.

[anonymous]

This won't make it possible to chat without a yahoo account. Just makes it possible to use Jabber transports to do so instead of using separate accounts.

This seems contradictory. You start by saying both a yahoo and a jabber account would be required, then you say a transport makes it possible to avoid separate accounts.

The whole point in a transport is to only need one account, which interfaces with a gateway to other networks. There are some web-based services that do this now. You get one account, and without creating a yahoo account you can still IM YM users.

[ruskie]

Badly put. A transport wil provide a client interface to another network through jabber.

Jabber client -> transport -> altIM network you still need an account on altIM network for it. Unless altIM network is also xmpp compatible.

[ccx@…]

The relevant XEP for this is XEP-100: ​http://xmpp.org/extensions/xep-0100.html

There are two issues here, the first one is managing the registration which is one-time task and can be well done from other clients. The second one is managing the transport's presence.

On some servers/transports the transport goes down when the client that told it to go up disconnects, so it's necessary to be able to set online state from bitlbee itself. If I'm reading the spec right it should be as easy as:

<presence to="icq.example.com" id=...>
  <show>away</show>
  <status>message</status>
</presence>