Dancing through life

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. ;)

I have never seen notifications work on Amethyst as a graphineos user without google play services. Yes I use ntfy, but I don't host my own listener.

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

is this compatible with 0xchat or is it just an amethyst thing?

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?

It works on molly because I host my own listener.

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

Send me a PM. Maybe that's why? I understand that ntfy receives the notification, but nothing shows up in my Android notifications.

molly.im

Yes I am just curious how this is actually going to work for people who don't host their own unified push system.

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.

Other than having Amethyst running in the background or self hosted?

I have it working with my chatbot pretty reliability, and I built it from a simple vibecoding session with no experience vibecoding. I am an ex software dev. I find that hard to believe.

This is in white noise with two users and one chatbot

i've already written a full marmot MLS implementation. why i agree with it is that it eliminates the distinction between group and two party conversations. the implementation is tested side by side against the rust crate. i'm not familiar with the vulnerabilities but it all seems a bit moot to me when you can subscribe to the 443 and 445 and 1059 types on an open relay and see the traffic in real time, the obfuscated timestamps just complicate the fetching filters. that's the whole point - you can't prevent metadata leakage without auth. idk how to put it any more clearly. as for vulnerabilities outside of that key and primary one, can you point me to discussions about these vulnerabilities in MLs that don't include metadata leaking because that is irrelevant. MLS is not about metadata security, it's about post compromise security and forward privacy, and the flexibility to have one single protocol implementation that covers all cases, DM and group.

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.

It wouldn't work unless White Noise supported adding users to an existing group. Pika supports this today, White Noise tomorrow. That isn't a problem with the protocol. The issue is with nuance between implementation details.

... and see the same chat history. So you are calling the feature a bug. In marmot MLS this is a feature.

> MLS vulnerabilities AI is finding No? What's this? Vulnerabilities in the protocol itself or in some of the implementations?

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.

Which explains why it doesn't exist in Amethyst. Marmot is an upgrade from Signal to make it decentralized. Signal has a feature (perfect forward secrecy). The way they work around that is linking a device from the main account, and offering to copy historical messages to the linked device. If the feature you want doesn't exist in Signal, it probably will never exist in marmot. Of course don't quote me on anything. I am barely a spectator in this space. I have just been burned by Signal's centralization so I prefer marmot.

haha, that audit was rammed through like the federal reserve act.

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.

I assume it copies it directly from what exists in storage on my phone. If true then your statement assumes the implemented solution assumes actual perfect forward secrecy. I mean, if it was truly perfect forward secrecy than I couldn't write the messages down on paper as I get them and share with a friend.

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

Yes and I use disappearing messages too. So whatever...

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.

Except my key point: if I loose my nsec. Almost nobody in the bitcoin community fully trusts their nsec / seed phrase except in hardware wallets. We are constantly told to keep our seeds offline. Marmot solves this for PMs.

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

I have a hardware signer. I never use it. I have Amber, yet my nsec somehow leaked. I blamed Amber, but who knows with these things.

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

I am not 100% sure if it leaked. All I know is something 'liked' a post in Amethyst that I did not recognize doing myself. And Amber was acting super buggy on my phone. It would pop up every time I try to use it. It was a huge pain just to post that my nsec got leaked. Then I wiped my phone for good measure. Amber is asynchronous so everything is a callback. I still use it, but I also swap out my nsec for fresh for privacy too. So at this point, I don't care if I loose my nsec. The PM messages would be nice to use but I don't use PMs for obvious reasons. I only use marmot or signal.

Why not use Amber to store my bitcoin? If it is so secure? Well, because maybe at some point the device itself isn't secure. I don't care because I use Signal with disappearing messages. If/When my device gets hacked, hopefully the hack left some trace or strange behavior that I pick up on. If it doesn't then it was probability very sophisticated. Most zero days leave traces.

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.

Except the messages that are already deleted in Signal. I have a system. It works. Moving on.

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.

Yes and hopefully it takes awhile before malware makes it onto my system too.

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.