@mirrorwish Let's see if I understand your proposal correctly. It would allow a mobile client to download only a part of all the messages (let's call it headers for a better analogy) and then they can see which one is for them and which one isn't. They still need to perform a cryptographic operation to check whether the header is a part of a message for them or not, but it requires less computational resources than decrypting the whole message, and it also reduces the bandwidth they require. The recipient would be a little less anonymous, because the node will see it only requests some objects in full, but it wouldn't know his bitmessage address unless it compromised the sender as well (i.e. more-or-less same as it is now).

The node protocol could then be upgraded to v4 to add the getheaders command, or use a node bitfield to indicate this. We cannot easily determine dynamically whether getheaders is supported or not, because there is no error feedback implemented (if I send getheaders to a node now, it will ignore it, and this is difficult to interpret correctly).

As for the objects, the "encrypted" field of the encrypted payload would simply be prepended by these two variables. Due to how it's implemented in PyBitmessage, full nodes will think that the encrypted data also includes these two variables and graciously fail to decrypt it. This makes backwards compatibility very easy.

The sender would also not require any configuration options, because they would see in the pubkey object the bitfield flags, and can still use the old format when sending messages to people who run their client as a full node.

This sounds good. I'd then recommend to change the bitfield 30 from "include_destination" to "simple_recipient_verification" (SRV) and implement it like this.

To be nice, a SRV node could also indicate to the connected node that it's a SRV node and will not relay data, so that the connecting node can optimise (otherwise, a full node could end up only being connected to SRV nodes and cause a network split, while thinking all is ok). In the future, a full node could also offer delegated PoW services to SRV nodes.

In the GUI, we could have a global setting for SRV mode, and also a per-address flag (for example if you share private keys, it needs to send the same pubkey object from both devices and if one has the bitfield on and the other one off, it creates problems). SRV mode should be indicated, for example in the window title, and/or in the lightbulb color or next to it, and also in the desktop notifications (e.g. "Bitmessage connected in SRV mode").