Open remirafun opened 2 years ago
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 https://github.com/hive-keychain/hive-keychain-extension/issues/233, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHXAF3L3DIT37NZ5HTJHHF3VPHBFLANCNFSM5Y3BQVNQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>
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).
Oh I see! So basically instead of specifying the receiver as an account name, you'd specify the key directly. Correct ?
Yes. Sorry for the late reply.
I can add it to our backlog, is that sth you'd need urgently?
Thank you, backlog is fine, it is not urgent.
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)