[Feature Request] requestEncodeMessage with public key

[remirafun]

Currently requestEncodeMessage uses a hive username to find the public key to encode the message with. It first checks memo, key then first posting key. If this function also accepted a public key string, the user would have the option to encode a string with key of his choice. Additionally, encoding even with public keys not on chain would be possible. (use case would be eg.: to support encrypted message for lite/guest accounts)

[stoodkev]

Hi! At the time, users can only store one key per account and authority so I don't think this would add value unless we adopt a wallet with multiple keys/authority, which could complicate the UX.

…

On Wed, Jun 15, 2022, 20:04 remirafun ***@***.***> wrote: Currently requestEncodeMessage uses a hive username to find the public key to encode the message with. It first checks memo, key then first posting key. If this function also accepted a public key string, the user would have the option to encode a string with key of his choice. Additionally, encoding even with public keys not on chain would be possible. (use case would be eg.: to support encrypted message for lite/guest accounts) — Reply to this email directly, view it on GitHub <#233>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHXAF3L3DIT37NZ5HTJHHF3VPHBFLANCNFSM5Y3BQVNQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[remirafun]

Thank you for quick reply. The use case I'd be interested would be to encode a message with public keys. So that hive user would be able to encrypt a memo against guest/lite account's public key (which is not on hive).

[stoodkev]

Oh I see!
So basically instead of specifying the receiver as an account name, you'd specify the key directly.
Correct ?

[remirafun]

Yes. Sorry for the late reply.

[stoodkev]

I can add it to our backlog, is that sth you'd need urgently?

[remirafun]

Thank you, backlog is fine, it is not urgent.