I'm not sure if a proxy model is the best idea to explode the keys into user IDs. In particular, exploding the user IDs after filtering the keys sounds wrong because you would have to put another filter proxy on top to filter the user IDs. It might make more sense to have a proper model with all user IDs and then filter for primary user IDs if only those are needed.

On the other hand, for things like the completion model for encryption keys a user ID exploding proxy on top of the filter proxy may work. The filtering of the user IDs for completion is handled by Qt.

I just had a look at https://doc.qt.io/qt-5/qabstractproxymodel.html#mapFromSource. I think proxy models are not meant to expand a model because it is impossible to implement mapFromSource if a source index (key) belongs to multiple indexes (user IDs) in the proxy model.

If I understand you correctly we will then have the hirarchical keylist model, the flat keylist model and then as a new model the userid keylist model in libkleo/src/models/keylistmodel ? To be honest you probably know best how to implement this in the most useful way.

I would experiment with replacing the flat keylist model with a flat userid keylist model. For places where we only want to see the primary user IDs we could simply put a filter proxy on top. Obviously, that's a big architectural change so I'd expect some breakage. Maybe we start with adding a new model but keep in mind to replace the old model. Or we immediately replace the old model with a primary-user-ids-proxied new model.

In principle, we have to decide if, on the user level, we want to move away from the current certificate-centric model to a user ID-centric model. I think for most users a user ID-centric model is easier to understand because most users want to encrypt stuff for certain other people (who are identified by user IDs). They don't want to encrypt stuff to certain key IDs.

The Proxymodel approach seems to work; I can't find any fundamental problems due to having more rows in the proxy model than in the source model. Since this is the least invasive approach - with (almost) all changes being contained in the new model, I'm going to continue with this approach for now.

first draft is up at https://invent.kde.org/pim/libkleo/-/merge_requests/67

Let me know what you think / what you need