Opened 7 years ago

Closed 7 years ago

Last modified 3 years ago

#14785 closed enhancement (cantfix)

facebook jabber detaches contact from already setup metacontacts

Reported by: tanim_s_islam Owned by: deryni
Milestone: Component: XMPP
Version: 2.10.0 Keywords: facebook,
Cc: McNetic, EionRobb

Description

Currently, I find that facebook jabber contacts detach from their associated metacontacts that i have organized. They are all placed in a group called "Facebook Friends." I have noticed this behavior for the past few hours now, on 6 December 2011.

Change History (27)

comment:1 Changed 7 years ago by thijsputman

Same observation here.

It was fine yesterday when I switched off Pidgin (6-12 around 19:00 CET). This morning when I started Pidgin (09:00 CET) my buddy-list was completely messed up. Tried to group some Facebook contacts into meta-contacts again, but after a while they simply split up and show as separate contact in the "Facebook Friends" group again. Custom aliases also appear to be reset at that time.

Another observation: Pidgin used to add new Facebook contacts to the "Buddies" group (or something along those lines, I'm guessing the default group?). Right now they go into the "Facebook Friends" group.

comment:2 Changed 7 years ago by novasource

Me, too.

comment:3 Changed 7 years ago by cobalt

I don't know about you guys, but that's always been the case with Facebook. It's an issue with Facebook updating their server roster whenever you connect to them, placing their contacts in the groups that you have over there with them in Pidgin. I think from what the devs told me ages ago, that that takes priority (remote) over metacontacts (local).

comment:4 Changed 7 years ago by thijsputman

Doesn't that (remote gets priority over local) largely defeat the purpose of having a multi-protocol client that tries to "abstract away" from the different protocols (c.q. Pidgin)?

comment:5 Changed 7 years ago by projekt21

Cobalt, FB used to put all contacts into the remote groups, but metacontacts worked fine. Now FB puts all contacts into the group "Facebook Friends" and metacontacts don't work anymore. So this is an issue.

comment:6 Changed 7 years ago by Robby

Ticket #14787 has been marked as a duplicate of this ticket.

comment:7 in reply to: ↑ description Changed 7 years ago by gianop

This happens to me too, probably to all Pidgin users, of course. It's so annoying, messes up the entire contact list, the messages histories, the custom names... A really pain in the ass... A workaround is welcome.

comment:8 Changed 7 years ago by im-yes

Same happening to me. Suddenly this AM. Even after I "rename" Facebook Friends" list and merge it with Buddies, it reverts back to separate Facebook friends group. this defeats the whole purpose of this client for me. is there a fix in the works??

comment:9 Changed 7 years ago by Robby

I'm not a Pidgin developer but I think you'd have to ask Facebook.

comment:10 Changed 7 years ago by rekkanoryo

Ticket #14791 has been marked as a duplicate of this ticket.

comment:11 Changed 7 years ago by rekkanoryo

  • Resolution set to cantfix
  • Status changed from new to closed

Facebook enforces the structure of the roster/buddy list. There's nothing we can do about this. As Robby suggested, the best course of action is to complain to Facebook about their XMPP server's limitations.

comment:12 Changed 7 years ago by j.martin657

So you're telling me its IMPOSSIBLE for pidgin to save what groups I want the contacts in and to resort the contacts AFTER facebook has forced them all back into the facebook group

comment:13 Changed 7 years ago by thijsputman

For someone not intimately familiar with the inner-workings of either XMPP or Pidgin this indeed seems a bit hard to believe. Wouldn't it be possible to write a plugin for Pidgin that enforces the client-side roster preference over anything else?

By the way (and for future reference ;) here is a bug report at Facebook which seems to indicate the change on their end is intentional: https://developers.facebook.com/bugs/285769454799737.

comment:14 Changed 7 years ago by rekkanoryo

Technically, it is possible for us to be heavy-handed, break with the XMPP specification's intended behavior, and forcibly override the server-side list, but it's not something we are willing to do.

comment:15 Changed 7 years ago by thijsputman

sort of like what Facebook is doing on their end..? :)

Anyway, thanks for the update and your effort in making Pidgin a great IM-client (irrespective of this issue).

comment:16 Changed 7 years ago by rekkanoryo

What Facebook has done on their end is perfectly valid XMPP behavior. The server may, at its sole option, enforce a roster structure. Overriding this server-enforced behavior would be breaking with the intention of the specification.

comment:17 Changed 6 years ago by McNetic

A took a glance at the RFC (6121) defining the handling of rosters. I don't see any hint that the server should enforce a roster structure upon the user. Technically, I also don't see it explicitly forbidden, although the overall intention of the RFC seems to be, that the server complies with the clients requests on any possible changes to the roster or it's structure, which in my opinion indicates that the server should not mess with this at all.

On the other hand, in the case of facebook, a) no force on earth can bring them to behave in a sane way, and b) it is obviously a required to change the roster on the server side, for example when friends are added or removed within facebook.

However, the RFC explicitly says that there is not 'the roster', but there can be more than one roster, even hosted on other servers or whatever. I do not see why Pidgin should restrict itself to obey the obviously ill-conceived and user-unfriendly roster structure facebook tries to impose, especially when the contact list maintained by pidgin can not be mapped to every protocols server-side contact list anyways.

So please rethink this decision and perhaps add an option to store the roster for a xmpp account within pidgin, or on another server.

comment:18 Changed 6 years ago by novasource

McNetic? has an excellent point. The RFC is a tool, not a straightjacket. If Facebook wants to be a putz, we shouldn't use a literalistic, possibly misinterpreted view of the RFC get in the way of providing an excellent user experience.

The RFC probably should not dictate UI concerns. In the end, this request is really about a UI concern.

comment:19 follow-up: Changed 6 years ago by rekkanoryo

Facebook is not the only XMPP server that enforces a roster structure. Openfire, at least, can be configured to enforce a roster structure, and is in fact so configured in a number of corporate environments. Any roster modification requests are outright rejected in this configuration, just as on Facebook's XMPP server.

I guarantee that if we were to ignore the server-side roster structure, we'd have people whining that when they sign into Facebook Chat with a different XMPP client the groupings they configured in Pidgin don't carry over and Pidgin is "obviously broken" because of that. We're damned if we do and damned if we don't. As a Pidgin developer, it's my opinion that we should leave things as they are. It really isn't that much of an inconvenience. If it bothers anyone that much, there is the web interface for Facebook Chat.

comment:20 Changed 6 years ago by McNetic

I would say pidgin developers should care most about pidgin users, not users of other xmpp clients.

And not being able to group facebook contacts into metacontacts is a major pita for using a multi-protocol client.

I don't want to use the facebook interface; in fact, I don't want to know and care if which client the contact I chat with uses, I just want to click on my friends names in my contact list and chat away, regardless of what client or protocol they are using. Currently, I have to search for the contact to be online in two places; in the group I placed it in, and in the facebook group (where it may have a different name I have no influence on).

comment:21 Changed 6 years ago by EionRobb

The xmpp-ignore-groups plugin at http://code.google.com/p/pidgin-xmpp-ignore-groups/ helps prevent this happening by (optionally) ignoring the server-side groups list.

comment:22 Changed 6 years ago by McNetic

This plugin is exactly what I wanted. This is so great, thank you very much!

comment:23 Changed 6 years ago by novasource

I created #15409 as a feature request to add an option way for users to tell Pidgin to ignore XMPP groups. That is not a request to change the basic behavior, as this ticket requested, but to add a way for users to override default behavior.

Last edited 6 years ago by novasource (previous) (diff)

comment:24 Changed 5 years ago by Kyudan

This is still an issue for me. Since Pidgin developers seem unable to fix this, is there a plugin available to download for Linux-Ubuntu?

comment:25 in reply to: ↑ 19 ; follow-up: Changed 3 years ago by jhardin

Replying to rekkanoryo:

I guarantee that if we were to ignore the server-side roster structure, we'd have people whining that when they sign into Facebook Chat with a different XMPP client the groupings they configured in Pidgin don't carry over and Pidgin is "obviously broken" because of that.

So don't make it a default behavior. Make it a per-server option that the user controls, as suggested in ticket #15409, and label it clearly so that the user knows that local changes may not affect the groupings stored on the server and thus used by other clients.

This doesn't affect only Facebook. Try setting up a Slack account for a company with 500 users, of which you only regularly chat with ten.

comment:26 in reply to: ↑ 25 ; follow-up: Changed 3 years ago by EionRobb

Replying to jhardin:

So don't make it a default behavior. Make it a per-server option that the user controls, as suggested in ticket #15409, and label it clearly so that the user knows that local changes may not affect the groupings stored on the server and thus used by other clients.

That's exactly what the xmpp-ignore-groups plugin does and it works great with Slack (even though it was originally made for Facebook)

comment:27 in reply to: ↑ 26 Changed 3 years ago by jhardin

Replying to EionRobb:

Replying to jhardin:

So don't make it a default behavior. Make it a per-server option that the user controls, as suggested in ticket #15409, and label it clearly so that the user knows that local changes may not affect the groupings stored on the server and thus used by other clients.

That's exactly what the xmpp-ignore-groups plugin does and it works great with Slack (even though it was originally made for Facebook)

Do you know if there is a compiled version of that plugin available? I don't really want to have to try to set up a windows dev environment with all the build requirements that compiling a Pidgin plugin probably requires.

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!