Who wants to write a cool post about all Nostr apps new Android users should explore? I need a cool post to send to newish users.
Emphasis on the "other stuff".
Reminder that if you are using DM relays like inbox.nostr.wine or auth.nostr1.com and no other relay for DMs, you are so private that our own Push Notification system can't see your DMs to send you those notifications :)
We haven't figured out a way to allow push systems into that level of privacy yet.
We basically have to options:
- Auth with a key used by the Push Server itself. Everybody would have to white list that key to download their own DMs.
- Change the relay spec to allow a REQ, authed in the past by the user, like on https://github.com/nostr-protocol/nips/pull/1148/
Or maybe DM relays should have their own Push system and each user must set it up in a way that it sends to their NTFY handler when they receive a new one.
Not as easy as Google Play notifications, but it can work.
I wish this was for private/encrypted, but collaborative, notes. Like a Google doc, but with markdown.
nostr:nevent1qqsqqqrdnaus8g2mdx675jn5q6z27u88njuu09ncnxv6wa494aejwcgpzdmhxue69uhhwmm59e6hg7r09ehkuef0qgsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8grqsqqqqqpzgy6sj
That being said, if you keep your client small and specialized, JavaScript is fine.
nostr:nevent1qqswrmtyljpztwas99sxklre5ss0rrgpne48js5r242fmgnh8lttz6spz3mhxw309akx7cmpd35x7um58g6rsd3e9upzq3svyhng9ld8sv44950j957j9vchdktj7cxumsep9mvvjthc2pjuqvzqqqqqqyg07exz
I think nostr:nprofile1qqsflmrj64um42nh9tu7w8nr3dffy9tjrt8xururype9ajle7alctvgpzpmhxue69uhk2tnwdaejumr0dshszrnhwden5te0dehhxtnvdakz7qg3waehxw309ahx7um5wghxcctwvshsj9rlg4 has been playing with that.
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? 🤔
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
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.
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.
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.
Hum.. did it happen just once or all the time for you? It seems to be rendering fine over here. I wonder if there was a coincidence with something else running at the same time 🤔
Make sure to check if the money went out or not when that happens. Usually it goes out but the zapper service is not online or your public inbox relays are too busy.
You can't mix the two. Nip-65 sections exist to tell your followers where they should get your posts and where to send notifications back to you.
The General section on Amethyst include the relays the app is using to download posts for you. It has nothing to do with your followers.
I would never connect to any relay that hasnt been authorized by the user. It's just a huge privacy leak. With Tor, I can make a route just for random relays.
We have other settings in other events, like search relays use kind 10007 and so on.
You can add that back on the app settings, by choosing the Complete UI mode. :)
Global will change. We will have custom feeds where people can choose a filter (or global) and then pick a collection of relays to use for that feed alone. It will extend the top bar options to have relay choices as swell.
Maybe... I haven't yet seen the need for additional options but it could be one.
Besides IP leaks, the issue is colluding all filters together in the same req, avoiding auth, etc and doing all of that for all accounts that are logged into the phone at the same time. So it depends on how we assemble these queries to random relays. Since many relays limit one connection per IP, the use of Tor routes can keep users and subs separate from each other.
nostr:nprofile1qqsfnw64j8y3zesqlpz3qlf3lx6eutmu0cy6rluq96z0r4pa54tu5eqpz9mhxue69uhkummnw3ezuamfdejj7qgswaehxw309ahx7um5wghx6mmd9uq3kamnwvaz7tmjv4kxz7fwdehhxarjwpkx2cnn9e3k7mf0hkrkkr new DVM idea?
"Just the classics"?
Was it possible that you tried to zap before? I think this time didn't work because Amethyst canceled the transaction once your previous zap arrived in your phone.
Our relays should provide similar reports.
nostr:nevent1qqsqzfewxvvy7xwynjfdyqsttxty8m509sg4jmt3mpssx8pgxm7528spzdmhxue69uhhwmm59e6hg7r09ehkuef0qgsg7wgl657elz59677ua3ls4mcnmnx2cd6tf2xzw5rhqk9ca5f32xqrqsqqqqqp0nupg5
I can imagine an FDA auditor coming for a visit, asking for the Quality System documents, loading them up to an AI and simply asking: "what's wrong with these procedures?"
This is gonna happen.
Signal started by not allowing anyone to export it. That was forward secrecy. But when they added the import/export and desktop clients, forward secrecy became irrelevant because all an attacked needs to do is to attack the import feature. They don't need to decrypt individual messages anymore. It's just way easier to attack the "seed"
Also Signal is terrible because their servers know everything. It's not private at all. The server can pinpoint anyone, geolocate and uniquely identify all of a user's messages.
If a protocol doesn't operate with multiple servers chosen by the user, privacy is pretty much gone. Regardless of the quality of underlying protocol.
As long as you never let the ratchet state be exported from the main client, you should be fine.
But that blocks people from using multiple DM clients, which is a core motivation behind Nostr. You are blocking users into your client and locking them out of others. Same data silos Twitter and Facebook gave today.
As long as you never let the ratchet state be exported from the main client, you should be fine.
But that blocks people from using multiple DM clients, which is a core motivation behind Nostr. You are blocking users into your client and locking them out of others. Same data silos Twitter and Facebook gave today.
Yep, because the reality includes all these layers. And they break each other constantly. You can't truly claim any privacy without considering all these layers combined.
Sure, it's progress. But if you have progress in one, but doesn't solve the other layer, you can't claim being better. Sorry. I have seen too much of these BS with "private" comms in the last 20 years. people love to fool users into more complicated stacks and then leaving IP all there to be fully traced by servers.
Oddbean new post about login | logout
Notes by Vitor Pamplona | export