Forward secrecy means that compromise of a long-term key doesn't reveal past messages. Signal does provide that. It's a different category of attack if someone gets access to your device and sees your chat history, or tricks you to link an untrusted device.
Export is possible in any client, at the very least with screenshots or by writing the message history on a piece of paper, but that's not related to forward secrecy. Disappearing messages is the solution when you don't want your message history potentially seen by anyone later.
You can use a VPN to hide your geolocation from Signal (which you should do on Nostr as well if you need privacy), but it's true that they can connect your messages to your phone number, see when and probably with whom you're chatting. Not surprised if intelligence agencies are mining that data.
With Nostr we're at least over the phone number part, there's no single service that sees all traffic and there are different ways to fix the metadata issue — and do forward & backward secrecy when desired.
There's nothing preventing users from moving to another DM client. You can always go back to the old client or export or copy paste message histories if you need them.
It's not comparable to Twitter or Facebook, because you own your identity key and can always change the client or relays.
There's always a tradeoff between availability and security of messages, and maybe there are different use cases for both kinds of messaging. On Nostr, we are free to choose.
They can only see message history as far as the linked device allows and can't see future messages if the device unlinks. I don't know the exact details how Signal does this, but I don't think its forward and backward secrecy is broken because of the feature.
They can only see message history as far as the linked device allows and can't see future messages if the device unlinks. I don't know the exact details how Signal does this, but I don't think its forward and backward secrecy is broken because of the feature.
I guess cryptographic forward & backward secrecy would be the most important addition, along with hiding the recipient metadata. I see Jeff started double ratchet at https://github.com/nostr-protocol/nips/pull/1206 and moved on to MLS. I'll take a look.
What attack does the symmetric ratchet protect from? If your device is compromised, your message history will be revealed anyway.
Maybe it would help in the case when you locally delete earlier messages in a chain ("disappearing messages" or otherwise) but they're still on relays.
Maybe I answered my own question, but is there something else besides this?
Why not more difficult? Implementing DH + symmetric ratchet is more complexity than just DH.
Deriving a single-use public key for signing each Nostr event would have the advantage of messages not being linked to any other message or user, though.
What attack does the symmetric ratchet protect from? If your device is compromised, your message history will be revealed anyway.
Maybe it would help in the case when you locally delete earlier messages in a chain ("disappearing messages" or otherwise) but they're still on relays.
Maybe I answered my own question, but is there something else besides this?
Why not more difficult? Implementing DH + symmetric ratchet is more complexity than just DH.
Halp me understand double ratchet. What's the advantage over just periodically generating new keys and doing DH between them? Would be fairly simple to do on Nostr. Even if your main private key was stolen, your message history would be safe.
In addition to DH keys, double ratchet also has individual "message keys" and "sending/receiving chain keys". In what real-life scenario would they be compromised without also compromising all past messages on device?
https://signal.org/docs/specifications/doubleratchet/https://image.nostr.build/c66a4b601a146bbd7bdb93122fa7b1d778355f75801deaa1298be7a09444f465.png
Social graph is not just the people you follow (1st degree), but also people they follow (2nd degree) and so on.
Currently Iris loads up to 2nd degree by default. There's also a tool for crawling up to 3rd degree, but it consumes a lot of bandwidth and cpu. 2nd degree was 20K users and 3rd degree 160K users in my graph, so there's plenty of diverse voices.
Optionally we could show posts from unknown users who have a nip05 (e.g. username@iris.to) from a bot-resistant provider. In a permissionless system like Nostr, we will always need to limit write access somehow or it will be filled with spam.
https://image.nostr.build/1407ad9d130088eceff4a8f1d73dc4f546237b47db170c8f48313d38839695eb.png
It sets npub.cash address only when you create a new user on Iris. Maybe it could suggest npub.cash address for existing users who don't have a LN address yet.
Rolled out new https://iris.to version:
* Zero-configuration zaps for new users: comes with a [npub]@npub.cash lightning address and an integrated Cashu wallet (cashu.me)
* ReplyGuy-free experience: automatically hides content by users not in your social graph
* "Unseen" feed. Click "home" or switch tabs to refresh.
* "Adventure" feed. Shows content from everyone in your social graph.
* Social graph based fast user search
* Better scroll position retention on back navigation
"Add to home screen" for better mobile use experience & push notifications.
This new version is based on NDK. I think it's a good idea for web devs to work together on shared core libraries.
Not perfect, but I'll keep working on it! If you preferred the previous Iris version, you should use https://snort.social which is basically it.
https://image.nostr.build/2f997643856deed77cbb27eb68549fe5def27b3464f1d88d716c80badac0d354.png
Apparently cashu.me is not nip-60 yet — is there some other wallet I should use on iris.to instead?
Is nip-60 on public relays a privacy tradeoff? I imagine it reveals when there's been activity in your wallet.
On the relay side, maybe allow nip-42 authenticated users to push gift wraps (where event.pubkey is not the authenticated user).
On the client side you need to process all incoming gift wraps and only check WoT after unwrapping. That adds some spam processing overhead unless you only connect to WoT relays.
Gift wraps don't hide recipient metadata, and you can guess who are talking to each other by timestamp correlation 👀
Creating a new shared keypair for each secret chat doesn't have this problem, but it can be tricky to keep track of all the keypairs between sessions.
On the relay side, maybe allow nip-42 authenticated users to push gift wraps (where event.pubkey is not the authenticated user).
On the client side you need to process all incoming gift wraps and only check WoT after unwrapping. That adds some spam processing overhead unless you only connect to WoT relays.
How would you derive the address? Something like event.pubkey = publicKey(KDF(messageKey))? I imagine "mailbox address" would need to be the signer's public key so others can't spam the mailbox.
Social graph filtering works great and doesn't require domain names or other trusted parties, but nip05 (maybe limited to trusted providers) can be one way to complement it for newbies who are not yet in the graph.
I was thinking about bitcoin mining style PoW which some have suggested, but actually I'm concerned it might hinder normal users more than spammers. There was a PoW-based anonymous reddit once, but it was filled with spam. https://github.com/notabugio/notabug
It's best if they can be introduced by someone, or get noticed by zapping.
Secondarily, messages from users who have a nip05 from a bot-resistant provider like iris.to, or provided a sufficient proof-of-work, could be scored higher, at least within the "messages from unknown users" pool.
Yes. It actually limits to 5th degree so basically everyone who's somehow connected. It only initially downloads up to 2nd degree follows though, and then further when you visit their profiles. I could make these parameters configurable.
If your client doesn't support WoT yet, at least you can use WoT relays.
nostr:nevent1qqsqqqqqz6p6am89g4586w2wfkr29vzvd680k9xmwmrzzh4x4u4dt7qpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtczyr3vea70ypqr70e2ff2mx28smca78p2c5l2lxd3jlk4wl3exc8ywkw9clk8
It's just embedded as a /cashu subdirectory & iframe in the user interface. I'd like to make it more seamlessly integrated, so you could quick zap, show the balance and automatically redeem incoming zaps from npub.cash without the wallet page being open.
Yes. Purple for yourself and followed users. Orange for users that are followed by users who are followed by at least 10 users you follow, and gray for at least 1.
Yes. Purple for yourself and followed users. Orange for users that are followed by users who are followed by at least 10 users you follow, and gray for at least 1.
As clients implement WoT filtering based on follow lists, the meaning of "follow" might become more like "endorsement", whether we like it or not. Your followers might complain / unfollow if your follows bring unwanted content to their feed. Other lists would be used when you just want to follow without endorsing.
I'm hosting it myself, so it can access the nsec stored on the same domain and works without configuration. Enabled npub.cash and Coinbase exchange rate by default.
Oddbean new post about login | logout
Notes by Martti Malmi | export
What attack does the symmetric ratchet protect from? If your device is compromised, your message history will be revealed anyway. Maybe it would help in the case when you locally delete earlier messages in a chain ("disappearing messages" or otherwise) but they're still on relays. Maybe I answered my own question, but is there something else besides this? Why not more difficult? Implementing DH + symmetric ratchet is more complexity than just DH.What attack does the symmetric ratchet protect from? If your device is compromised, your message history will be revealed anyway. Maybe it would help in the case when you locally delete earlier messages in a chain ("disappearing messages" or otherwise) but they're still on relays. Maybe I answered my own question, but is there something else besides this? Why not more difficult? Implementing DH + symmetric ratchet is more complexity than just DH.