39 lines
2.3 KiB
Markdown
39 lines
2.3 KiB
Markdown
# Contact/group display-name source precheck
|
|
|
|
Date: 2026-07-10
|
|
|
|
## Question
|
|
|
|
Can the current N12-pre evidence safely enrich `isphere_search_contacts` and `isphere_search_groups` beyond JID-derived display names?
|
|
|
|
## Evidence checked
|
|
|
|
- `docs/source-discovery/2026-07-09-n12-pre-zyl-index.md`
|
|
- `docs/source-discovery/2026-07-09-n12-pre-zyl-schema-notes.md`
|
|
- Ignored metadata summaries under `runs/offline-evidence-intake/zyl-qqfile-20260709/metadata/`
|
|
|
|
No raw DB/log content or decrypted personal values are committed in this note.
|
|
|
|
## Findings
|
|
|
|
1. The committed index identifies `MsgLib.db` as the strongest candidate for messages, contacts, groups, and attachment references, but it leaves display-name storage as an open question.
|
|
2. The schema summary for the extracted `MsgLib.db` candidates reports `file is not a database` for the inspected copies, so there is no validated SQLite table/column source for contact names, group names, department, title, or member count yet.
|
|
3. `PacketReader.ProcessPacket` gives reliable JIDs and `chat`/`groupchat` routing data, but the current committed field mapping only proves message id, conversation id/type, sender/receiver JIDs, timestamp, content body, subject, and receipt/status fields.
|
|
4. `LoginInfo` has sensitive local account/user/dept/contact metadata, but the available summary only proves local account context. It does not prove a full roster or group display-name mapping for arbitrary contacts/groups.
|
|
5. `SaveToDB` summaries show message-arrival shapes and `from`/`body` presence, but not a committed display-name/group-title mapping.
|
|
|
|
## Decision
|
|
|
|
Do not implement display-name enrichment in the current loop.
|
|
|
|
Keep `isphere_search_contacts` and `isphere_search_groups` honest as JID-derived local-readonly candidates until one of these sources is validated:
|
|
|
|
- readable/decrypted `MsgLib.db` tables with contact/group display columns;
|
|
- decrypted roster/contact/group stanzas with stable JID-to-name mapping;
|
|
- bridge/API/local-service evidence exposing roster/group metadata;
|
|
- internal-sandbox UIA or live capture evidence that safely maps visible display names to stable JIDs.
|
|
|
|
## Next slice
|
|
|
|
Use C24 to precheck `MsgLib.db` format/readability or identify the correct wrapper/decryption path, because that is the most likely route to contact/group display names and richer message metadata.
|