Custom Query (1098 matches)
Results (4 - 6 of 1098)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #235 | other | Report idle status or add 'Forward to Mobile' away state capability for AIM | ||
| Description |
AIM has a nifty feature where you can register your mobile phone number on the AIM web site to associate it with your AIM username, and then messages can be forwarded to you on your mobile via SMS when you are not on AIM. If you turn this forwarding on via the AIM web site, then logout of your AIM account on BitlBee, it works as expected, received AIM messages go via SMS to your mobile (and in many cases, you can reply via SMS and carry on a 2-way conversation). In the official AIM client though, there are other ways of starting the mobile forwarding rather than just logging out. Specifically (as described here): "After registering, IM Forwarding will automatically be turned
on and will show you as mobile to your Buddies when you:
- Sign off AOL® or AIM®
- Select 'Forward to Mobile' from the Away menu of your Buddy
List® feature
- Your personal computer becomes idle."
Since I'd guess that many people who use BitlBee tend to run text mode IRC clients that they leave running and connected all the time under screen (as I do), adding support for either the 'Forward to Mobile' away state or the reporting of "idle" status would be a very useful BitlBee enhancement to allow use of the AIM mobile IM forwarding. |
|||
| #1294 | other | fix crash when gcry_cipher_open fails | ||
| Description |
I analyzed the source code and found a potential bug that may cause crash. In bitlbee-3.5.1/lib/ssl_gnutls.c:480:7, if "gcry_cipher_open" failed to open, "gcry_cipher_setkey" would cause a crash since "gcr" is null. I think it's unsafe to assume that the library function would be correct. It would be better if we could handle the error properly. Attached please find the patch against version bitlbee-3.5.1. Hopefully, it can solve this potential bug. |
|||
| #909 | not-feasible | Add configurable timeout *before* messages are displayed as an anti-spam feature on twitter (possibly other protocols) | ||
| Description |
I often get bot-spam on twitter which gets deleted fairly quickly on the web interface, but bitlbee faithfully displays it. Example: 14:19 + nitamovfr [nitamovfr@twitter] joined #twitter_taupan 14:19 nitamovfr > [51] @HanJin500 @Oliviaaaas @GabiiFurtadool @TauPan @Ms_JessicaLee http://t.co/M6CwSyv1 <tinyurl.com/6rnzhc5/Jtlo> I think this could be helped if bitlbee gives new tweets/replies (from new users) a grace period, before displaying them, to give the twitter server a chance to react to block requests ;) Maybe some other protocols could also benefit from this, not sure. |
|||
