We will only introduce private messages when we can end to end encrypt them - so they are truly private. We have plans to do this but it'll at least be a few months until we get to it.
How are you thinking of doing it? We're exploring combining e2ee / private key management stuff with secure enclaves to add verifiably private and secure use cases to existing applications via JWT / normal user login / oauth.
Could be a cool proof of concept here if you're open to that approach.
reply
76 sats \ 2 replies \ @k00b 20 Aug
We would probably use signal’s protocol with clientside key management. We aren’t actively working on it so nothing is locked or anything.
reply
Might be able to help with at least the client side key management part. Expecting users to manage, sync, and secure private keys for normal applications (let alone wallets) may be a big limiting factor. Even if you still want to roll your own, would love to chat as you start thinking about it more.
reply
151 sats \ 0 replies \ @k00b 20 Aug
Cool we’ll reach out before we begin seriously working on it
reply
You have to talk to @ek and @k00b for that one. I will ring them up for you.
reply
20 sats \ 1 reply \ @k00b 20 Aug
He replied to me so I was notified. Thanks though
reply
oh right. Sometimes I forget those details.
reply
41 sats \ 2 replies \ @Wumbo 20 Aug
Might I suggest adding a feature the lets SN receiving users to set minimum sat amount (in their settings) that is require for them to receive the message.
If SN sending user really wants to send Wumbo a messages they will have to pony up some sats.
For example : 100,000 Sats per message
This hopefully will take care of spam messages.
reply
30 sats \ 0 replies \ @k00b 20 Aug
Yep that’s what we plan
reply
Interesting. k00b will have to consider it.
reply
That will be cool. I would like to have some private conversations with some of the stackers.
reply