Names of chat participants lost after upgrade to "New Groups"

[yringot]

I noticed that in a 3-person group, all the names of people other than me are displayed as "No-Sender" right after the group was upgraded to the new group format:

Upgrade notification inside Signal:

Output in HTML:

After that, all the other participants' messages look like this:

I confirmed this in other groups with multiple participants. All of them are listed as No-Sender

@-mentions (which were introduced with the new group functionality afaik) don't work either. (See issue #45)

[yringot]

A little update: Apparently, the above behavior is not consistent. Here is a recent multi-user chat that is mixed: both "no-Sender" and actual names:

[carderne]

Finally got some time to look into this. A lot of this was caused by a bug when filtering with e.g. --chats=group-name. That's fixed now.

But the new-style groups also store the sender ID in a different way and I haven't figured out how to match these up with contacts/names...

[carderne]

If you have the time/capability to dig into the database and see if you can find IDs that match up then Godspeed! I might not get to this for a bit...

[kittenbytes]

Hello @carderne - This problem has returned. I did an export today (having never done one before) and in my group chats it switches to "no-sender" anytime between late February and early March. Thanks for your hard work!

[carderne]

As before, nothing really I can do here unfortunately as I don't have access to your data to see why these changes are happning.

[BirgitVeraSchmidt]

Hi,

I tried to dig a little bit into this. It appears that my database no longer contains the source entry in the messages table.

I'm not very well-versed in Python, so I needed to dabble around a bit with the existing code to find out a tad more. In data.py after

query = "SELECT json, conversationId FROM messages ORDER BY sent_at"

when I output the entire res, I get this (where GUIDs are changed to random values to protect my privacy):

'timestamp': 1724669993522,
'attachments': [],
'id': 'd3fa5912-af49-478c-b299-936288250b72',
'conversationId': '4fdd3742-e6ef-46ae-a3ad-1c74d9de2a8d',
'readStatus': 0,
'received_at': 1716974551437,
'received_at_ms': 1724669994011,
'seenStatus': 2,
'sent_at': 1724669993522,
'serverGuid': '9881f87e-8f7c-4e9f-a30a-0c580d47bab9',
'serverTimestamp': 1724669993797,
'sourceDevice': 1,
'sourceServiceId': 'db703cd4-bf91-45c6-8f1c-c4225d219f07',
'type': 'incoming',
'unidentifiedDeliveryReceived': True,
'schemaVersion': 12,
'body': 'Here be some message text',
'bodyRanges': [],
'contact': [],
'decrypted_at': 1724669994099,
'errors': [],
'flags': 0,
'hasAttachments': 0,
'isViewOnce': False,
'mentionsMe': False,
'preview': [],
'requiredProtocolVersion': 0,
'supportedVersionAtReceive': 7

The sourceServiceId in turn shows up in conversations, e.g. the result of

    query = "SELECT type, id, serviceId, e164, name, profileName, members FROM conversations"

(where I added serviceId).

I managed to cobble together a fix that works for me locally:
0001-Fix-46-Names-of-chat-participants-lost-after-upgrade.patch.zip
(I attempted to upload it as a new branch, but have no permissions, therefore I exported a format-patch instead.)

As I said I'm not working much with Python, and I also don't know the Signal database format too well, so please double and triple check before you trust me on this! But hopefully it can fix the issue.

[carderne]

@BirgitVeraSchmidt are you open to trying to open a PR again?

What you need to do is fork my repo, push your changes there, and then open a PR from your main to mine. I'll have a look at your patch in a week or two if I don't see a PR.

[BirgitVeraSchmidt]

Certainly! I was not aware that forking a repository was a normal thing to do on GitHub.

If I did everything right, here should be the pull request:
#141