provide a way to view an entire conversation in twitter

[bitlbee@…]

Sometimes, people I'm following will be having a conversation with someone I'm not following, but occasionally make a public reply (starting the reply message with '.' or something), or they will reply to someone I am following who replied to them. It'd be nice if there was a command I could use to see the entire conversation at that point, so I can see what's actually going on without having to go to the twitter website.

[dx]

How should we do this in the "UI"? How should be handle the fact that twitter conversations can branch and extend indefinitely?

[bitlbee@…]

Well, when you view a tweet in the web UI, it gives a linear view of one single thread of conversation, which would probably be sufficient. I don't think it really needs to handle branching. Really, all I typically want here is some context, it doesn't have to be an entire conversation browser or anything like that.

[william@…]

It's me again (rawreply guy). I'm also looking at this option, for me personally. Here's my current thinking.

Use the command "thread [tid]" to bring up the thread. Only go back in history, at most 10 (configurable) tweets. That is, pretend the conversation is actually linear and contains at most 10 tweets. The conversation won't necessarily be linear, but I feel that's the best we can do given the UI. Anything non-linear will involve crazy character-art graphs which I feel will be terrible.

At this point, I see a few options.

1. Show this thread as a new msg from root (so it opens in a new window)
2. Show it in the current window, but with some prefix to point out that it's a threaded conversation view.

I'm a fan of the 2nd one. Something like the following, where "User" is the user, who follows Amy but not Jane, Joe, James or Jane. The "t" denotes a threaded reply.

Amy   | [36] Hey this is a good conversation
@User | thread 36
Joe   | [37 t] Start of conversation
Jim   | [38->37 t] Reply to 37
James | [39->38 t] Reply to 38
Jane  | [40->39 t] Reply to 39
Amy   | [41->40 t] Hey this is a good conversation

There are a few problems. Firstly, we see the tweet 36/41 twice. I would actually prefer this (easier to follow if there's more space between the original tweet and the request for the thread), but I also see that some others might not want it. Configurable? This "may" cause issues with implementation (see below) but I don't think it'll break anything.

Secondly, maybe people want to keep their timeline "clean"? That is, in most clients people can "remove" the conversation once they've viewed it. Bitlbee itself obviously cannot. However, I think this can be done client side as long as we have a "threaded" marker, the t in my example. Just get your IRC client to remove any lines of the form "^[\h\h->\h\h t]" where \h = [0-9a-f].

Thirdly, times. Should we also post the date/time the original messages were sent? I feel like "yes" is the right answer here, which will happen automatically in twitter_msg_add_id.

For the first solution (new messages from root), I'm not really sure. I mean, it'll work in displaying the tweets but now all these messages will be from "root", so we'll have to treat messages to "root" as messages typed into the main channel. This already is getting complicated, so I probably won't implement this (unless someone gives me good reason to).

Ok, so that's how I see the UI working, please comment and point out any changes that might be worth making.

As for implementation, that's not too bad it seems. Getting the tweets isn't too complicated (use the REST API, pull statuses until "in_reply_to_status_id_str" is NULL). Will probably have to modify twitter_status_show and/or twitter_msg_add_id to add the threaded indicator.

This will result in duplicate tweets in the log. However, they should have different log_id values. The alternate solution to this problem is to, inside _msg_add_id, check to see if the tweet already exists in td->log, and if it does we don't store it a second time, but still print it a second time using this original reference.

I probably won't even start coding for at least a day or two, so just looking for general comments for now.

[dx]

Replying to william@…:

Only go back in history, at most 10 (configurable) tweets. That is, pretend the conversation is actually linear and contains at most 10 tweets.

Actually, recently I realized that this is exactly the way the web UI goes *back* in conversations - it just follows the parents. (Going forward is a bit weirder but usually contains uninteresting stuff)

The "t" denotes a threaded reply.

The position of the thread indicator could be something else, but the idea in general sounds good.

Just get your IRC client to remove any lines of the form [...]

Meh. I do want to keep my timeline clean (ignoring that it's a mess already from all those failed tweet attempts), but I'd rather avoid script based approaches where possible, and this doesn't fix the fact that they get logged to disk.

But not a huge concern for now.

Thirdly, times. Should we also post the date/time the original messages were sent? I feel like "yes" is the right answer here, which will happen automatically in twitter_msg_add_id.

I don't see why not.

[...] we'll have to treat messages to "root" as messages typed into the main channel. This already is getting complicated, so I probably won't implement this (unless someone gives me good reason to).

Could use the 'fake' user, 'twitter_username', which is used for other twitter modes, I believe. But yes, if you don't care a lot about this, feel free to leave it out, it's not essential.

[...] pull statuses until "in_reply_to_status_id_str" is NULL [...]

Doing 10 http requests for a single thread is kinda meh, but i don't think they will mind if they didn't provide a better method. Just watch out for rate limits and obviously don't block the main loop.

The alternate solution to this problem is to, inside _msg_add_id, check to see if the tweet already exists in td->log, and if it does we don't store it a second time, but still print it a second time using this original reference.

Yes please! Having different log_id will probably not work, since deduplication will kick in... i think.

I probably won't even start coding for at least a day or two, so just looking for general comments for now.

Looks solid to me!

[william@…]

The position of the thread indicator could be something else, but the idea in general sounds good.

Any ideas here are welcome. My thoughts basically qwew that it should be inside the []s, and short. I'm now considering your idea of a message from twitter_username though, in which case maybe it's not even needed?

Meh. I do want to keep my timeline clean (ignoring that it's a mess already from all those failed tweet attempts), but I'd rather avoid script based approaches where possible, and this doesn't fix the fact that they get logged to disk.

Yeah the logging I didn't consider. As mentioned above, I probably will do the separate chat from twitter_username idea instead.

Doing 10 http requests for a single thread is kinda meh, but i don't think they will mind if they didn't provide a better method. Just watch out for rate limits and obviously don't block the main loop.

Yeah I can't see any other option though. I did check a bit, and couldn't find any sort of "also get the conversation" type API points. If someone knows of one/finds one, let me know.

Yes please! Having different log_id will probably not work, since deduplication will kick in... i think.

Ok, will do. It shouldn't be too hard, just edit twitter_msg_add_id to re-use existing log entries.

[william@…]

Ok, had a decent work through but something has come up. Currently the im_connection is passed from the function which makes a HTTP request to the callback function which handles the request.

I want to pass along two more variables. One of these will be an integer representing the "number of tweets currently retrieved" or similar. The other will be a list of the currently-retrieved tweets. Without this list, the conversation will be printed in "reverse" order (newest reply will get sent first since it will be the first requested and hence first returned).

Some options include:

• Sending a struct containing the im_connection as well as my variables (This means my function is slightly different to every other function, which seems bad)
• Adding my variables to im_connection (Even worse)

Neither seem that good. In fact, both seem bad. But I can't figure out a better way, so I'm looking for tips.

On an unrelated note, I edit with vim and different tab settings. Do you guys mind appropriate vim magic lines at the end of source files so vim inserts proper tab characters and displays them 4 characters wide? The line will be

# vim: sw=4:ts=4:noexpandtab

I don't mind removing them (slash not submitting them in patches) but wanted an opinion.

[william@…]

Patch to add threaded support via PMs

[william@…]

Added a patch for this. As it says, it applies to 3.2.1 (with probable line-number change warnings since I run a number of patches). It also does take the dirty way out, using the

• Sending a struct containing the im_connection as well as my variables (This means my function is slightly different to every other function, which seems bad)

approach. I did come up with a third option, which is to modify all twitter_http functions so that http->req is a struct containing *ic and one other pointer to data relevant to whatever function is being called. However, so far only one twitter_http function even requires any data, so still not ideal.