it's good to start, but it should cost 21 sats or less to call someone, I don't know why you always think like a socialist

hey!! that means that anyone of people I follow can call me?? 👀

a starter

pups wrote you from wisp. Now back to amethyst 😁

Traitor!!

ugh, then we'll be using shit apps that charge the least. or paying for "pro" versions to control spam calls... where does it end? but, yeah, 21 sats is nothing... now. ;)

Yep, nfty sucks. I could get it to work, but just for a while then they start charging...

It won't be for now...

Just tested, the server is sending a push to your NTFY address

So the relays somehow connect to the call function on the phone?? I hope this works on graphene phones too, but i dont want google play svc on my phone, so there's that.

No, the relays don't do anything besides relaying the call request event. Everything else happens via WebRTC. The two phones connect directly.

How can I request that relays block incoming voice messages. It's not even a few months since nostr doxxed everybody's DM's.

Oh, thats very interesting👀👀. So it will work on graphene phones?

What do you mean nostr doxxed everybody's DM?

In theory, yes..

What's molly? But you can host any unified push system with Amethyst too

Yes, that is the old DMs using Nip04. We have moved away from them about 3 years ago. Nobody should be using Nip04 anymore. Both DMs and calls on Amethyst use nip17, which nobody can see anything.

Well, all Unified Push solutions that I know are paid. So, unless they pay, there is no viable option...

in actual fact, none of the chat protocols have solved any problems. the biggest reason to update to marmot MLS is it's a unified DM/group chat. at all times, forever, and from the beginning, AUTH has always been the thing that provides metadata security. you only have to read the architecture of matrix, signal, and the rest, to understand this. but even today, we here this "we don't go to ravenholm" meme about nostr DMs and you are not thinking bro. not thinking Auth is what makes privacy metadata security possible. you can get an answer to that question in 5 seconds with any LLM. do yourself a favor and stop making yourself sound like a stupid person to anyone who understands distributed systems and security

NIP 17 still leaks IP address, has no forward secrecy, no deniability, and no post compromise security.

We do nip-17 via Tor. So no IP leakage. Nothing else has solved the other 3, not even Marmot, but I can use whatever does solve.

Have you seen the latest papers on all the MLS vulnerabilities AI is finding? The thing is too big. So difficult that many folks outside Nostr are giving up on it and starting new protocols. I don't mind using Marmot, but it has been under development for over 2 years and it's still not stable or even usable.

Pubky Noise looks like a good solution. I concluded about 6-months ago that Nostr is fubr'd on a protocol level. Pubky meanwhile is both decentralised and anti-fragile due to its use of PKARR and Kademlia. Probably a pipe dream but I would love for Amethyst to be the first Android Pubky client.

Now open this chat on another Marmot based client to see what happens.

Pubky is a platform whose company behind it holds all the cards. I did a few tests with them but was never able to build pubky from scratch because the information is not out there.

It's ok, hit me up when Marmot gets audited like nip17 and has at least 2 implementations users can log in and see the same chat history.

Could you be more specific? I get that John is the architecture and design authority, but I estimate that to be a significant advantage over Nostr. It is necessarily funded by Tether (although not exclusively) because devs need to meet their living expenses.

That's a deal breaker for me. Either offer interoperability or GFO. Otherwise this is just another vendor-lock in scheme to block people from moving away from a company's products. MLS is mostly a corporate play, so I am not surprised they have successfully brainwashed folks to think that is a feature.

Reference Implementations.. they are way too big.. the original idea of hatcheting in tree branches is good. The implementation of the things that idea needs to have in place to run correctly is where all the problems and attacking possibilities lie. I don't think they are new problems, it's just that AI can be more effective in finding and exploring them inside codebases.

Forward secrecy in signal is a lie exactly because you can export/import stuff or connect with a desktop app. I don't need your keys, I just need to connect my desktop to your signal app. Then puf.. all the "perfect forward secrecy" turns into theoretical BS.

the forward secrecy is in the encrypted form not the message it contains.

Because its not the best protocol. It's not that I have not tried...

Sure.. I find the use of "forward secrecy" terms just marketing bullshit most actual engineers know it only exist in theory. So, to me, that is not a good sales point for Marmot. I do like the scaling of group sizes, though... But I wouldn't use it because of "forward secrecy"...

Good thing that I was able to implement it from scratch on Amethyst (including ChaCha20 itself) so, the audit + my own knowledge was enough to make me very confident in the approach. Also, in 3 years, nobody has found any flaw in it to breach.

That's why we have signers. We don't move our nsecs around just like you wouldn't move your Marmot keys around.

How did it leak? Amber is super small, we can review the entire code in a couple hours if the problem was there.

If your device gets hacked, nothing can protect your messages... No matter how advanced their encryption is. If that is your thread model, you don't even need to encrypt anything because it is all irrelevant at that point.

Sure, but malwares are not detected right away, it takes a long time. So while you are running the malware can see your messages before you delete them.

Pubky (and Nostr) are not consensus enforced systems, if people dont like how we build they can fork and build. Everything we make is modular anyway.

it's not just theory. each message has a particular secret. that secret is derived from other secrets including your nsec. forward secrecy means that an attacker can't find the next secret from the previous. post compromise security means that an attacker can't unravel the backwards path either.

i wonder how many of the leaked nsecs were used with amber.

lol. so you do know that when you send a message you have to send two messages to the relay right? one for you, one for the other person. in theory you can send each one to a different relay, which decouples this. but if both relays you sent it to have no auth, someone can be sitting there with a few clients already sitting there waiting for this kind of message. it's called a timing attack, and it doesn't change anything about the metadata security versus nip-01 if: a) more than one of the relays that was used has no auth, attacker can listen and find both messages and correlate them to a conversation b) even if they do get to separate relays, if they were sent to several, and one of each has no auth. done. and the other thing is the claims about chacha20/poly1305 being superior in any kind of reasonable term over the AES encryption that nip-04 uses are highly specious and deceptive. in actual fact, the big advantage of chacha20/poly1305 is performance. its bits of security are around the same. the only difference is aes uses rijndael in the place of chacha20. most of the internet is still running on AES encryption and at scale a compromise would have to have happened in some way by now. if there was reason to really move to another one with a smaller amount of study of its vulnerabilities and field actual usage. the vulnerabilities that reputable cryptographic algorithms have are considered to be so small as to be negligable, so called "infeasible" attacks. the bigger problems with these have come from "side channels" and a famous one was the use of bad quality random generators, and in the case of nip-17, as i just outlined, the *protocol* itself has a vulnerability that IS NOT HANDLED. two, in fact. one, to protect against metadata leaks you need these two conditions: 1. relay uses auth, so that a snoop can't just subscribe to catch everyone's messages 2. clients enforce sending each half of the message to separate relays (that have auth) so that the signal would have to be intercepted to catch the ip address timing and that would be the final boss, and for which somethiing like Tor might help a little. the protocol is weak on these two points and the first point i just don't know how long it's going to be until you all understand that you are sidestepping the real main vulnerability, with this superstitious distrust of relay operators who you... don't demand they use auth, sitting there everyone smiling happily while strfry still doesn't have any kind of system of nip-42 auth usage and half the clients still don't implement it.

also, amethyst is the common factor in this too. both are very commonly used and there was a big leak of nsecs not long ago i was seeing. tracing the root cause of the leak would definitely require checking amethyst, amber and primal apps because they have hte biggest userbase and probably you can also track the association between the leaked nsecs and the nip-05 and the chatter of the users who were using them saying which client they used.

stfu

you should hear white noise in white noise

what interests me is the protocol how you migrate a chat from 2 to 3 parties. it's obviously some kind of rollover process where last step forms the foundation of the state transition. i'm trying to think of where i have seen this pattern before. oh yes, pBFT validator lists. that problem is already architecturally solved in the Cosmos protocol.