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.

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.

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.

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.

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"...

you should hear white noise in white noise