After ContactInfo is merged, it would be nice to detect the Facebook XMPP server, and on connections to that server, clear the SupportedFields and the Can_Set bit.
Ideally we'd also do the same for Aliasing and Avatars, but those interfaces don't have any concept of inability to set your own. For Avatars we could fake it with an empty set of supported MIME types, perhaps?
Xavier points out that this also affects ContactList channels, which are rather more important (on Facebook Chat, the roster is read-only via XMPP).
One potential problem with putting in a special case that forcibly suppresses UI for write operations (contact lists, vCards, etc.) is that if/when Facebook upgrade their server to allow write operations, Telepathy UIs will keep disallowing them (until Gabble is patched again).
Another one: we should claim to support room listing on Facebook connection as we can't use it anyway.
Note that profile could part of this job at least: http://telepathy.freedesktop.org/wiki/service-profile-v1. Those profiles lists unsuported channel classes for the account.
I think the right way to do this is to extend XMPP if needed and ask Facebook to properly advertise what they (don't) support.
So we have at least:
- Not being able to set our own vCard: bug #45403
- Not being able to set our own alias
- Not being able to set our own avatar
- Not being able to modify the roster
- Not being able to list rooms or even join a chat room.
- Only support available and away presence: bug #39252
Also, Aliasing.Connection_Alias_Flags should not have the User_Set flag as we actually can't assign an alias to our contacts.
Note that MSN-XMPP is the same as facebook regarding server caps.
-- GitLab Migration Automatic Message --
This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-gabble/issues/82.