Oddbean new post about login | logout Hum.. how hard would it be for Amethyst to create an onion address for the npub and then expose it to DM contacts to allow P2P messaging/voice calls without exposing your IP to your peer? 🤔
Porque não expor IP dos pares ?
Para não precisar confiar na pessoa quando enviar DMs. Falar com qualquer pessoa nas internet sem risco é importante.
Or what about auto generating a new npub for the DM, then destroying when DM chat deleted. 1) new npub spun up 2) only each others personal relay (self-hosted, Citrine) is shared with new npub with friend, or immediately be in DM with friend, who also has a new npub [messaging "connected"] 3) "connected" message could be signature from original npub; verifible confirmation it's them 4) chat encrypted and pseudonymously 5) when chat is deleted, auto delete npub and contents on relay (be cool to spin up and destroy relays quickly)
That was our initial idea, but we realized most of the time you don't really know the person you are DMing with. Trusting them (and their relays) with the new npub (and the possibility of linking all your keys together) seems like a non starter. https://github.com/nostr-protocol/nips/pull/1306
Doesn't nostr:nprofile1qqs9ajjs5p904ml92evlkayppdpx2n3zdrq6ejnw2wqphxrzmd62swspzemhxue69uhhyetvv9ujuvrcvd5xzapwvdhk6qgdwaehxw309aukzcn49ekk2qghwaehxw309aex2mrp0yh8x6tpd4ehgu3wvdhk6ynf30t use this? How do they get past these problems
They don't... To the best of my knowledge.
They do use this https://github.com/water783/nips/blob/nip101/101.md
Yep, but secret chats run into the same issue that you have to trust your peer and their relays to not identify you.
Give me the TLDR on 'MLS based messaging lands.'?
Very complicated but it's the only option for large (100+ppl) encrypted private groups. In theory, it requires two centralized services, which we don't have in Nostr. But I think nostr:nprofile1qqspwwwexlwgcrrnwz4zwkze8rq3ncjug8mvgsd96dxx6wzs8ccndmcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszrnhwden5te0dehhxtnvdakz7qg3waehxw309ajhjetn9enrw73wd9hsqwhj0h found a way around these restrictions. It would be great if it worked. I am still unsure what relays, the public and users can track from one another over time. But it will likely require a Tor-like IP hiding system to make sure relays can identify keys when the app is doing REQs with multiple filters.
What do you mean by “the relays the public and users can track from one another”? Re: IPs, yes. Relays could triangulate to some degree but usually only for short periods because all the visible group ids change regularly. Tor and some trust in relays is inevitable.
Some relays are collecting and selling information about users, like their interests and so on. Its likely that they will want to collect any info at their disposal to associate accounts/keys/secrets and sell them to the highest bidder. Picture Chainanalysis, but on nostr. If that breaks the privacy of MLS, then there might not be a reason to do MLS at all.
It doesn't break the privacy of MLS at all. All messages that are sent to relays are done so under ephemeral identities. All REQs that clients do to relays are for arbitrary group IDs that can (and must) change over time; or, in the case of welcome messages, they're REQing for NIP-17 style DMs. The creator of the group also sets the relays that the group will use for these messages so ideally, clients will only allow users to select relays that support privacy features like the "-" tag to stop event rebroadcasting, etc.
Can the chosen relay link IP-emphemeral identities and start putting a sequence of messages together? Can't they just see when the group id has changed and link the two? I am not doubting MLS, but I have seen too many people claim privacy until I run their server and start logging down everything every connection does to locate, track and identify each participant. If the relay can do it. They can either sell that info for profit OR be required by court order to track and identify users. If they can do it, they will do it. That's why I am using Tor when connecting to DM relays. Every app session is a new Tor exit node. Relays can't know where each message is coming from. It's the only way I found to keep things private.
MLS is certainly not a panacea and it doesn't have any opinions on the transport protocol. This is what I've spent a lot of time trying to come up with. Yes, you're right, if you use just the MLS encryption aspect of the spec, you're leaving too much available to the relay and that could potentially lead to timing or triangulation/association attacks. Clients that implement MLS based messaging and care about privacy will need to use Tor (or VPNs or proxy relays at a minimum). I'm implementing all this now and finding lots of little details that have to be managed by the client to do this correctly. Things like rotating your key material as soon as you're added to a group (for PCS), rotating group IDs, potentially using multiple group IDs concurrently, securely storing conversation data on the client, etc. The reality, I believe, is that these are going to be pretty specialized clients. I'll have library code at the end of this that will make it easier but it's always going to be a significant lift to have strong privacy guarantees.
😳
To get rid of IP addresses, take a look at Reticulum Network. Unfortunately, it's not widely used, so we have to build it first. https://reticulum.network/ #reticulum #reticulumnetwork
Genius idea. Maybe do something more generally. Have a NIP to define a particular TOR onion address to a given #nostr public key. That way, each person has their own TOR address defined and available if they decide to use it. If Vitor has a defined Onion address, then I can be assured when I visit services at that address that it is you.
You can already do this
Silence, Vitor is cooking... https://image.nostr.build/d0191881985e8cd032e9ba2f1e824adc9a5ee88c96e82bb4861808cc1e1d7b33.jpg nostr:nevent1qqs9mrj77xnu7q6wzmdellj8wlz058znrk836mhm2x6hn02tgvjy9xqpzemhxue69uhhyetvv9ujumt0wd68ytnsw43z7q3qgcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqxpqqqqqqzl9asgj
