This is a comment left during a code review.
Path: app/src/main/java/com/lxmf/messenger/service/MessageCollector.kt
Line: 86-96

Comment:
**Pre-seeding bypasses the unread-notification check**

Pre-seeding `processedMessageIds` with every DB-persisted received message causes the early `return@collect` at line 103 to fire for all of them, completely skipping the `existingMessage.isRead` notification branch (lines 108–173).

Consider this scenario:
1. `ServicePersistenceManager` (running in the separate `:reticulum` process) saves a message to the DB.
2. The app process crashes before `MessageCollector` reaches the `notifyMessageReceived` call.
3. On the next restart, this pre-seeding loads that message's ID into `processedMessageIds`.
4. When the message is replayed via the SharedFlow / `drainPendingMessages`, it hits the `in processedMessageIds` guard and returns immediately — the user never sees a notification.

Before this patch the replay would fall through to the `existingMessage != null` branch, check `!existingMessage.isRead`, and correctly fire the notification. The fix trades away that recovery path entirely.

A safer approach is to only pre-seed IDs for messages that have already been **read** (or for which a notification has already been shown), so that unread-but-persisted messages can still bubble up through the existing `existingMessage.isRead` gate.

```suggestion
                try {
                    val existingIds = conversationRepository.getReadReceivedMessageIds()
                    processedMessageIds.addAll(existingIds)
                    Log.i(TAG, "Pre-seeded ${existingIds.size} read message IDs for notification dedup")
                } catch (e: Exception) {
                    Log.w(TAG, "Failed to pre-seed message IDs - duplicate notifications may occur", e)
                }
```
(This would require a new DAO query that adds `AND isRead = 1` to the existing `getReceivedMessageIds` query.)

How can I resolve this? If you propose a fix, please make it concise.

This is a comment left during a code review.
Path: data/src/main/java/com/lxmf/messenger/data/db/dao/MessageDao.kt
Line: 169-170

Comment:
**No LIMIT on startup ID load**

`getReceivedMessageIds` returns every received message for the identity with no upper bound. For a long-lived account this could be tens of thousands of string IDs, all held in memory inside `processedMessageIds` for the entire session.

Consider adding a `LIMIT` clause (e.g. the most recent N messages), since messages older than some threshold are extremely unlikely to be replayed:

```suggestion
    @Query("SELECT id FROM messages WHERE identityHash = :identityHash AND isFromMe = 0 ORDER BY COALESCE(receivedAt, timestamp) DESC LIMIT 5000")
    suspend fun getReceivedMessageIds(identityHash: String): List<String>
```

Alternatively, filter by a recency window (e.g. `AND COALESCE(receivedAt, timestamp) > :cutoff`) to cap memory usage proportionally to message volume.

How can I resolve this? If you propose a fix, please make it concise.

This is a comment left during a code review.
Path: python/reticulum_wrapper.py
Line: 3336-3339

Comment:
**O(n) list scan on every successful delivery**

`pending_inbound` is a plain Python `list`. Both the membership test (`lxmf_message in self.router.pending_inbound`) and the subsequent `.remove()` call scan the entire list linearly. Although the goal of this change is to keep the queue small, under high message rates or after a burst delivery there could be a transient performance penalty.

If `pending_inbound` is owned by the wrapper (or can be replaced), changing it to a `list` backed by an `OrderedDict`/`set` for O(1) lookup would be more robust. If it is a third-party LXMF router attribute that must stay a `list`, the current approach is acceptable but worth a note.

No code change is strictly required — just something to be aware of if performance issues arise in high-throughput environments.

How can I resolve this? If you propose a fix, please make it concise.