The initial proposal considers a straightforward approach where a payment from one user to another, say Alice to Bob, could include an optional text field indicating the sender's identity (from: Alice). This method draws comparison to existing mechanisms like those employed by Ocean in Bolt12 methods, which facilitate payouts with descriptive tags to prevent spam and verify payer identity without complex verification processes. Ocean's system allows for identification of the payer through an invoice_payer_id, distinguishing genuine transactions from others.

The conversation also touches upon privacy and security considerations, suggesting that users might have the option to reveal their identities selectively using a contact_key only to recipients who are within their trusted contact list. This ensures that the recipient, such as Bob in this example, only learns about the sender's identity if there is a mutual trust established by having each other on their contact lists. This concept raises questions about the necessity and implementation of a per-contact invreq_payer_id, hinting at potential privacy benefits but also complexities in managing these identifiers on a per-contact basis.

Furthermore, there's a critique of bLIP-31, suggesting it might be too intricate for the intended simplicity of this feature. The speaker expresses a preference for the simpler first option that aligns with their design principles and biases but remains open to understanding the specific use cases that might necessitate a more complicated solution like the one outlined in Option 2 or the protocol discussed in bLIP-31. The consideration here leans towards balancing between ease of use, privacy, and the technical feasibility of implementing such features within the existing frameworks.