Twitter - Recieve DMs

[anonymous]

Bitlbee does not recieve direct messages on Twitter. Sending works just fine.

Unsure if it's broken or simply not yet implemented.

[lkraav <leho@…>]

i have also noticed more than once that i've not received a direct message that a google alert has later brought to my attention.

[wilmer]

Hm. So.

​http://www.marco.org/2011/05/19/twitter-dm-oauth-requirement

I wonder if this is ever going to happen at all. DMs are going to be available just for webapps, and only if your app is shiny enough, as judged by a random Twitter employee?

[litui@…]

How is it that TTYtter can deal with DMs but bitlbee cannot?

[Wilmer van der Gaast <wilmer@…>]

Because TTYtter has code for it and BitlBee has not.

[litui@…]

Good explanation, thanks. Bump on the feature request then. =)

[walter+bitlbee@…]

basic direct message support

[walter+bitlbee@…]

The added patch basically hacks the direct message reading support in. It doesn't tell private messages apart from public ones, but it's a start.

Own direct messages are read at login only. Others' are read every 60 secs, like the statuses.

irssi alias:
/ALIAS TWITDM /msg -bitlbee -channel #twitter_SCREENNAME d
/TWITDM SomeOne hi!

Regards,
wdoekes

[kris@…]

Hello there walter! Unfortunately, I wasn't able to get your path to compile in 3.0.3.. Did you forget to include something that should've come along with the patch?

twitter_lib.c: In function 'twitter_get_direct_messages':
twitter_lib.c:578: error: 'struct twitter_data' has no member named 'direct_message_id'
twitter_lib.c:580: error: 'struct twitter_data' has no member named 'direct_message_id'
twitter_lib.c:588: error: 'struct twitter_data' has no member named 'direct_message_id'
twitter_lib.c:591: error: 'struct twitter_data' has no member named 'direct_message_id'
twitter_lib.c: In function 'twitter_get_direct_messages_sent':
twitter_lib.c:609: error: 'struct twitter_data' has no member named 'direct_message_sent_id'
twitter_lib.c:612: error: 'struct twitter_data' has no member named 'direct_message_sent_id'
twitter_lib.c:620: error: 'struct twitter_data' has no member named 'direct_message_sent_id'
twitter_lib.c:623: error: 'struct twitter_data' has no member named 'direct_message_sent_id'
twitter_lib.c: In function 'twitter_groupchat':
twitter_lib.c:724: error: 'struct twitter_data' has no member named 'direct_message_id'
twitter_lib.c:724: error: 'struct twitter_data' has no member named 'direct_message_id'
twitter_lib.c:724: error: 'struct twitter_data' has no member named 'direct_message_id'
twitter_lib.c:726: error: 'struct twitter_data' has no member named 'direct_message_sent_id'
twitter_lib.c:726: error: 'struct twitter_data' has no member named 'direct_message_sent_id'
twitter_lib.c:726: error: 'struct twitter_data' has no member named 'direct_message_sent_id'
twitter_lib.c: In function 'twitter_private_message_chat':
twitter_lib.c:772: error: 'struct twitter_data' has no member named 'direct_message_id'
twitter_lib.c:772: error: 'struct twitter_data' has no member named 'direct_message_id'
twitter_lib.c:772: error: 'struct twitter_data' has no member named 'direct_message_id'
twitter_lib.c:774: error: 'struct twitter_data' has no member named 'direct_message_sent_id'
twitter_lib.c:774: error: 'struct twitter_data' has no member named 'direct_message_sent_id'
twitter_lib.c:774: error: 'struct twitter_data' has no member named 'direct_message_sent_id'

Cheers, Kris

[walter+bitlbee@…]

added the missing .h diffs

[walter+bitlbee@…]

Indeed. I forgot the .h files, it seems. Added now.

[Kris Fremen <me@…>]

Replying to walter+bitlbee@…:

Indeed. I forgot the .h files, it seems. Added now.

Thanks for the quick response. I got it working with 3.0.3.

I tried to get it working with the current bzr tip, but it just hanged on the function twitter_flush_timeline..

It's probably something that I missed due to lack of sleep and I did have to modify some functions too...

Would it be too much to ask of you to update your patch to work against the bzr tip?

​twitter.c
​twitter_lib.c

Here is my try at patching the tip with your patch, maybe it'll save you some time :)
Maybe I'm missing something very simple and I just don't see it...

Thank you for the patch!

Cheers,
Kris

[walter+bitlbee@…]

patch against bzr tip

[walter+bitlbee@…]

Ok.. I see some work has been done to sort the output. The direct messages could make use of that as well, but I didn't mess with that right now. The patched version simply outputs the messages directly (unsorted) like in 3.0.3.

N.B.: only tested that it compiles N.B.2.: it looks like they broke/removed the next_cursor functionality by including get_mentions in get_timeline => the whole next_cursor argument should probably be removed now. but that is of no relevance to this patch.

[Kris Fremen <me@…>]

Replying to walter+bitlbee@…:

Ok.. I see some work has been done to sort the output. The direct messages could make use of that as well, but I didn't mess with that right now. The patched version simply outputs the messages directly (unsorted) like in 3.0.3.

N.B.: only tested that it compiles N.B.2.: it looks like they broke/removed the next_cursor functionality by including get_mentions in get_timeline => the whole next_cursor argument should probably be removed now. but that is of no relevance to this patch.

Hi there, quick response again :)

It does compile, yes, but doesn't fetch the direct messages at all as far as I could see..

Cheers,
Kris

[walter+bitlbee@…]

Ok ok.. I missed a semi-colon, causing the DM's to get re-fetched every minute. But otherwise it works just like the 3.0.3 patch: shitty, but usable ;)

[walter+bitlbee@…]

add missing semi-colon

[wilmer]

Going over the patch a bit now - I'm not yet ready to merge but just curious. :-)

Your idea of halfing the fetch interval and doing one fetch at a time is interesting. I myself actually hoped to have different intervals for DMs (and ideally also mentions), since IMHO it should be enough to do those only once ever five minutes, for example. It's good to avoid upsetting Twitter's rate limiting.

Does that sound reasonable to you? Of course we can make the intervals configurable.

[walter+bitlbee@…]

I'm not yet ready to merge

Haha, I can agree with you there. In the bzr head it became even more of a hack =)

since IMHO it should be enough to do those only once ever five minutes

Well.. I don't do any twitter myself, but I was hoping I could communicate with the Mrs. with something she *does* have installed on her smartphone. And then twitter DM sprung to mind.

Lowering the DM rate here would be the inverse of my needs. Although I do understand that the apps on her phone aren't that quick in refreshing DMs either.

[Wilmer van der Gaast <wilmer@…>]

Lowering the DM rate here would be the inverse of my needs. Although I do
understand that the apps on her phone aren't that quick in refreshing DMs
either.

Some apps use the streaming API and are pretty quick though. Anyway,
maybe I forgot to mention that it should also be configurable and 5m
would just be the default.

[sergiosdj@…]

Hi,

Is this patch going to be checked in?

Thanks.

[andre@…]

Hello,

+1 for this feature. Is it still planned for an upcoming release?

Thank you!

[wilmer]

Ergh, I lost track of this patch entirely. :-( Will take a look soonish.

[ilf@…]

Will the received DMs be displayed according to $handle_unknown, in plain english: in query windows?

[Wilmer van der Gaast <wilmer@…>]

Unknown? You get DMs from people you don't follow?

[ilf]

You're right. What ever is the "normal" way of 1to1 communication in BitlBee. I forgot if there's an even an option, since I only use it in query windows.

[Wilmer van der Gaast <wilmer@…>]

"set private" probably. :-)

[wilmer]

changeset:json,972 now does this with the streaming API instead. Which is very nice because there's pretty much no delay in receiving them. (And no empty polls 99.9% of the time.)

And again I forgot there was a patch for this already, which by now I don't even need anymore. Very sorry, Walter. :-(

[walter+bitlbee@…]

Haha! No worries :) Thanks for fixing.

[wilmer]

Closing this one in favour of #996. This bug has been fixed in the JSON branch (streaming mode only), which will be merged and release fairly soon.