Generate Features subpacket on the new keys
This is how it is done in rpgpie for v6 keys: https://codeberg.org/heiko/rpgpie/src/commit/f1cc0d8c634a4d8af363d1500b187449e791bd49/src/tsk.rs#L283
We currently generate v4 keys, but RFC 4880 already defined features subpacket: https://www.rfc-editor.org/rfc/rfc4880#section-5.2.3.24
This will allow other clients, including new versions of Delta Chat, to detect that contacts support SEIPDv2 and send SEIPDv2 packets.
Regenerating existing signatures is out of scope for the issue, we should make sure new keys have Features subpacket first.
With rsop using rpgpie new generated v6 keys have Features subpacket, rsop generate-key --profile rfc9580 | rpacket dump /dev/stdin shows:
Signature(
Signature {
packet_version: New,
config: SignatureConfig {
typ: Key,
pub_alg: Ed25519,
hash_alg: SHA2_512,
unhashed_subpackets: [],
hashed_subpackets: [
Subpacket {
is_critical: false,
data: SignatureCreationTime(
2025-03-17T12:39:42Z,
),
},
Subpacket {
is_critical: false,
data: KeyFlags(
03,
),
},
Subpacket {
is_critical: false,
data: Features(
09,
),
},
...
Right, the "features" subpacket itself is old and established. All software should be able to tolerate it, including if it has bits set that the software doesn't know about.
Like the SEIPDv2 support "features" bit, which is defined in RFC 9580: https://www.rfc-editor.org/rfc/rfc9580.html#features-subpacket
Setting this flag for new users at first seems like a good starting point to me as well!