Open
Bug 802133
Opened 13 years ago
Updated 3 years ago
Support invisible mode in XMPP
Categories
(Thunderbird :: Instant Messaging, enhancement)
Tracking
(Not tracked)
NEW
People
(Reporter: javajens, Unassigned)
Details
From what I see it is not possible to set your status to something else than Available, Not Available and Offline.
However most IM Systems allow users to either set custom status messages and especially mark them as invisible.
I would love to see Thunderbird support these custom messages and the invisible feature.
For XMPP I believe the adequate section is this: http://xmpp.org/extensions/xep-0186.html#invisible or a more complete approach in: http://xmpp.org/extensions/xep-0126.html
Comment 1•13 years ago
|
||
(In reply to javajens from comment #0)
> From what I see it is not possible to set your status to something else than
> Available, Not Available and Offline.
Supporting custom status messages is different than supporting more types of statuses. I'm fairly certain that Thunderbird supports changing the status message (isn't there a textbox right next to where you can change the status?)
> However most IM Systems allow users to either set custom status messages and
> especially mark them as invisible.
I wouldn't really agree with that. /Some/ IM systems support more statuses, but they differ per protocol, which makes it really hard to find a set supported by all protocols. (E.g. some are just Available/Offline, some have Do Not Disturb or On the Phone, others have Invisible, etc.)
> I would love to see Thunderbird support these custom messages and the
> invisible feature.
For what it is worth, the chat backend can handle the "Invisible" status (although I doubt if the XMPP code does anything with it). [1]
Anyway, this bug seems to contain a bunch of different goals, can you please identify exactly what you expect out of this? (To make it an actionable bug.)
[1] http://lxr.instantbird.org/instantbird/source/chat/components/public/imIUserStatusInfo.idl#20
Ok, thanks for the reply.
I didn't notice the text box for custom messages, kinda tricky, but cool, UI ;)
I guess my goal is to get Invisible status supported for XMPP.
However I don't completely understand your concern about this being a problem with multiple protocols, as for example twitter (nor Facebook I believe) has no "not available" and Thunderbirds is able to manage with that, or am I mistaken here?
I'm not familiar with the background running there, is it based on Instantbird?
If so, it should be possible to implement per Account status information, if dealing with the various protocols is impossible.
Please comment if sth. is still unclear, I'd be happy to provide more information.
Comment 3•13 years ago
|
||
(In reply to javajens from comment #2)
> Ok, thanks for the reply.
> I didn't notice the text box for custom messages, kinda tricky, but cool, UI
> ;)
>
> I guess my goal is to get Invisible status supported for XMPP.
>
> However I don't completely understand your concern about this being a
> problem with multiple protocols, as for example twitter (nor Facebook I
> believe) has no "not available" and Thunderbirds is able to manage with
> that, or am I mistaken here?
Twitter is irrelevant here as it has no notion of presence.
Facebook contacts can be away/unavailable/idle(whatever you want to call that status that means they are connected but not available).
> I'm not familiar with the background running there, is it based on
> Instantbird?
Yes.
> If so, it should be possible to implement per Account status information,
In an add-on yes, it's possible.
We don't want an UI for that by default, as it's unnecessarily confusing to select a status for each account.
Comment 4•13 years ago
|
||
(In reply to javajens from comment #2)
> I guess my goal is to get Invisible status supported for XMPP.
Excellent, I've updated the bug title. :)
> However I don't completely understand your concern about this being a
> problem with multiple protocols, as for example twitter (nor Facebook I
> believe) has no "not available" and Thunderbirds is able to manage with
> that, or am I mistaken here?
If I mark myself as Invisible and I'm on IRC, Facebook and XMPP. IRC doesn't support this...how do I show the user that they're still visible on IRC, but not visible on XMPP (and I have no idea if Facebook supports this...but say it doesn't).
If we just show the status as "Invisible" we're lying to the user. They'd be very surprised when they receive an IM from that person they're trying to avoid.
Twitter doesn't have any concept of presence so is irrelevant in this conversation.
> I'm not familiar with the background running there, is it based on
> Instantbird?
The chat code is all originally from Instantbird. Thunderbird and Instantbird share the chat backend. (Note that this means there are MORE protocols than just XMPP/Facebook/GTalk, IRC and Twitter. Instantbird supports AIM/ICQ, MSN, Yahoo, etc.)
> If so, it should be possible to implement per Account status information, if
> dealing with the various protocols is impossible.
Currently you can set different statuses per account in the backend, but any UI built around this would be overly complicated for most users. An extension could be created to have the complicated UI for choosing different statuses per account.
(Note also that theoretically an extension could add the Invisible status to the UI, but the XMPP backend still doesn't support it...)
Summary: Custom chat/IM status → Support invisible mode in XMPP
> If we just show the status as "Invisible" we're lying to the user.
So, I guess I would need to write an extension that supports status for each account.
> (Note also that theoretically an extension could add the Invisible status to
> the UI, but the XMPP backend still doesn't support it...)
Would it be possible for an extension to send XMPP stanzas? Then the extension could follow http://xmpp.org/extensions/xep-0126.html
>Currently you can set different statuses per account in the backend, but any UI built around >this would be overly complicated for most users. An extension could be created to have the >complicated UI for choosing different statuses per account.
Could you point me in the right direction on how an extension could do this?
I guess I can close this request?
Thanks for your input!
Comment 6•13 years ago
|
||
(In reply to javajens from comment #5)
> > If we just show the status as "Invisible" we're lying to the user.
> So, I guess I would need to write an extension that supports status for each
> account.
Well just the UI for it! The backend supports it.
> > (Note also that theoretically an extension could add the Invisible status to
> > the UI, but the XMPP backend still doesn't support it...)
>
> Would it be possible for an extension to send XMPP stanzas? Then the
> extension could follow http://xmpp.org/extensions/xep-0126.html
We would support this in core (so an extension wouldn't need to worry about this). (And Florian suggests to me that there might be some code for GTalk around that could be used, it supports a different method of invisible.)
> >Currently you can set different statuses per account in the backend, but any UI built around >this would be overly complicated for most users. An extension could be created to have the >complicated UI for choosing different statuses per account.
> Could you point me in the right direction on how an extension could do this?
Each account implements
Each account has an imIStatusInfo [1][2] object, which lets something change it's status. There's also a global instance of this object which you can play with to change all accounts.
Note that there's probably a bug right now with setting a status to invisible: the auto-reconnect and idle timers might not obey the user being invisible.
> I guess I can close this request?
Well wanting XMPP to support invisible is a reasonable request! (And we can certainly help get it implemented...)
[1] http://lxr.instantbird.org/instantbird/source/chat/components/public/imIStatusInfo.idl
[2] http://lxr.instantbird.org/instantbird/source/chat/components/public/imIAccount.idl#250
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•