How to handle conversations

[CodedOre]

So, I have tried to work on conversations in the last few days, but haven't made any significant process. The problem I have is that there are a few points where I am not certain about the best approach, and since I tend to run around overthinking it over and over, I thought it would be best to discuss this with others first so I can make a good plan to implement this.

When we display a conversation, I want to use the following idea for display:
Display the "main post" (the one selected by the user), and:

• All posts that precede the "main post"
• All replies to the "main post"
• Any reply chain where the author is the same as the "main post"
• Any reply chain that only has one reply for each post
  , with an reply chain defined as an reply on reply to up to 2 levels down the tree.

About those uncertain points:

Point 1: Object or just Methods
In my original draft for the structure of the backend, I intended to use a Conversation class which keeps an record of all posts in one conversation and loads additional ones when needed. A reference to this object would have been store in the post object for access.
This has a few problems. For once, if each post would be holding a reference to an object, we would need to have a system to make sure to avoid duplicates of the same conversation. This is also something we should consider with other data structures as well, especially users. Another problem is that we would need to implement a data structure to hold a tree of posts and what is whose parent etc.
So the alternative idea from me was to simply implement a method that retrieves the wanted replies and parents and displays them. Problem here could be that it might load posts double since it does not know which was already loaded before.

Point 2: How to load replies
The other point where I got stuck with overthinking was which API's to use for retrieving the required posts.
We could use the search to search for replies to id x and repeat this search until we have anything we need. However, with how I want to display all of this, we need to make at least 3 searches for one display call.
We could also use the conversation_id on Twitter (allowing to search for all posts in an conversation), or the Mastodon API to retrieve the context of an post (all parents and replies to an post). However, this may call more posts than we intent to load.

To summarize this all:
I have two ways to load the posts wanted, two ways to (maybe) store them and since I haven't a clear favourite I just got stuck by not being able to decide what I now want to implement. So, I just wrote this down to get some input from others, especially from @IBBoard.

[IBBoard]

Sorry - been moving house and settling in, so just getting to read this.

Cawbird currently shows the main post and all posts that precede it by looking up the "in reply to" until we don't get another tweet in the chain.

We then look up replies based on "from:author to:author" (hopefully with the date of the "main post" - but if not then I missed an optimisation!) and check the reply-to to see if it's in this thread. Chronological order lets us build the thread correctly.

We also look up replies based on "-from:author to:author" to find everyone else's messages to the post author and then check the "reply-to". That only gets us one level deep, because it's too complicated to do anything any deeper, and our widgets are limited to lists. That fails when it's a popular account that gets @-mentioned a lot, though, because lots of those messages will be random mentions rather than the thread.

On point 1: Avoiding loading a tweet twice isn't absolutely essential, but it would be good if we can be efficient.

Are you going to be using any tree widgets? If so then I'd definitely go for the class and storing a tree, so that you've got something to easily map to the GTK objects.

In Cawbird 1 we'd probably just have a static method with a cache, but that's a bit ugly. You could make it a UI feature and cache it within a UI class rather than the API, but that mostly moves the problem.

Does it need to be a separate Conversation class? What's stopping the tweets having "parent" and "children" tweets? As long as the getter methods request tweets from something else that can cache the objects (which would be good separation of concerns - the objects should be models holding data, not doing network actions as well) then you'll get the tree structure automatically and no duplicate tweets.

On point 2: I think the conversation ID is a big improvement in Twitter 2.0, so I'd definitely use that where possible. But it might only be useful for replies, since it's a search attribute and so subject to the time limits (whereas reply-to is an ID to fetch with a high request cap and can go back any length of time).

You could do two searches to get all of the replies reasonably efficiently if you specialise Any reply chain that only has one reply for each post further as Any reply chain that only has one reply for each post *where the main post's author is the replier* (i.e. Main Post → Other Person Reply → OP Reply) by using conversation_id:### from:author and in_reply_to_tweet_id:### -from:author in the searches. The first one will get the self-reply thread and any replies to replies - some will be too deep into sub-threads, but I think that's unavoidable. The second one will get the other direct replies from other people. You might be able to combine them into a single OR query if you want to reduce query requests.

[CodedOre]

I now have finished up my work from weeks long ago, which implements it as follows:
I have a sub-class of Collection named Thread which is responsible for showing replies around a specific post. On Mastodon, the context function is called, on Twitter we iterate until we have all parents and have one search for children. Not what I originally intended to implement, but it should work for now.

Does it need to be a separate Conversation class? What's stopping the tweets having "parent" and "children" tweets?

That might actually be a good idea for storing parent and child posts. But even if we handle reply loading as methods in Post, I think there is a case for keeping Thread. As it is a sub-class of Collection, I can reuse the same ListView, sorting, etc. from the other post collections.