skype main.db - difference between Chats and Conversations

Question

I've been dissecting Skype database main.db for a couple of days, and this is something which I haven't yet figured out. Naturally, this question will be very specifically for Skype main.db structure.(disclaimer)

It seems that all the necessary information that I need are in tables Conversations, Messages, Participants.

Message table contains actual log that has been said, the recipient(s), timestamp, and the convo_id foreign key(although not enforced) to connect to a Conversation which the message belongs to.

Conversation exists to hold the aggregates of Message and the Contacts that participate in.

Participants table works to a many-to-many connector table between the Conversations table and Contacts table.

What gets me are Chats and Chatmembers table. Chatmembers works to Chats what Participants table works to Conversations table; connecting Contacts and the conversations-or 'chats'.

What's in Chats is similar to Conversations except that it does not have any aggregate to Message table. It is impossible to map from Messages table to Chats table to which the message log(row of Messages table) belongs.

Chats and Conversations share a foreign key, Conversations table has a column named chat_dbid which joins to the Chats table. But there are rows in Conversations table which have a null chat_dbid field, and not all rows in Chats have id field which corresponds to chat_dbid field in Chats table.

The Chats table is still being updated and I recognize some of the chats-or conversations- I've had recently based on the timestamp and the members in it.

Does anyone know exactly what Chats table does? Or rather, what's the difference and justification for Chats table and Conversations table?

When I looked frantically for this I could find only one like that talked about main.db structure, and it wasn't very helpful.

According to the link Chats

Provides the chats in which the user participated.

and Conversations

Provides a list of the conversations in which the user participated.

What's their terminology about Chats and Conversations? How are they different?

It's been driving me crazy.

Dhiren

Answer 1

Yesterday I was also going through main.db table in skype. Below are my findings.

Conversations table uniquely identifies conversation with a particular contact(or a group contact you have created). Conversation entails all communication: chat messages, voice message, file transfers, calls that you do with a particular contact. Most of the tables have references to the entry in this table. Messages table has convo__id, Chats table has conv_dbid, Transfers has convo_id and likewise.

Messages table: messages entry are not always chats. If an entry is chat then its chatname field is populated. It seems that chats and messages has one to many relations. chat is a collection of messages maintained per some identifier(most probably day not sure.). "type=61" seems to be normal message: message typed by user. Other types seem to be auto generated messages for eg. msg you get if a call is disconnected.

Hope this helps.

Moniz

Answer 2

It looks like Chats are redundant. Messages are grouped into chats as an after-thought, you can have several Chats inside one Conversation and then some messages outside any Chat. The rules for grouping are unclear, perhaps by time.

Grouping is done by setting chatname field of a bunch of messages to the same value. Chat names look like #SenderId/$TargetId;ChatId or #SenderId/ChatId for Chats over groupchat.

ChatIds don't seem to hold any particular meaning and can be different on different PCs.

Not every Chat gets an entry in Chats table: SELECT DISTINCT(chatname) FROM Messages gives a great many more entries than SELECT * FROM Chats. Not everything that goes into chatname is a name of chat from Chats. Sometimes it's a conversation id (== groupchat id or skypename).

Different Skype instances also group the same synchronized messages into Chats differently.

So basically Chats are not important, they group messages arbitrarily, they don't contain any key data about who sent what to whom.

This is how I understand other tables work:

Contacts - this is everyone whose skypename is mentioned in the database, even people you never knew about (which said something in the groupchat you were listening to at the time). is_permanent marks those in your contact list.

Conversations - this is a union of your actual contacts and groupchats you have ever had joined. This is what one should see as "contact list". If you need contacts you've never messages, add Contacts WHERE is_permanent=1. If you only want present contacts, filter by is_bookmarked or something like that.

There seems to be no duplicates and splits. One contact = one conversation, one groupchat = one conversation. If you're talking with a contact one on one and you add another party, previous messages remain in that contact's Conversation, and the following ones get their own Conversation.

Messages - this is all messages and events ever sent or received:

• convo_id - always set, always references a conversation. This is how you identify to what contact / groupchat the messages was sent.

• chatname - always set, sometimes references a chat from Chats, sometimes a chat which is not in Chats, sometimes a groupchat id or skypename from Conversations. Mostly this can be ignored, or you can group messages by this field visually.

• author, from_name - who sent this message and their nick at the time, always set properly.

• dialog_partner - very unreliable, different values for the same message on different PCs

• participant_count - sometimes set, sometimes not, same as with dialog_partner: unreliable.

• identities - mentions all skypenames related to the event, or sometimes doesn't. Rules are unclear, unreliable.

Huskamp