Who's whitenoising?
It's a bit cumbersome to bootstrap. Either I put my nsec into the app or I won't find my follows?
It would be nice if I could provide my npub leo@nostr.info to find relevant others.
Login to reply
Replies (82)
I have it installed but don't use it. most people don't respond or don't get my messages, not sure.
It never worked with my nsec. I am not sure why.
I'm waiting for the next version
It works if your nsec was generated initially in white noise. So either you start off with white noise or you have a burner nsec alt.
Yeah, that sucks.
Unless there is a way to prove the alt is 'your' alt, I agree. If we could solve the key rotation problem at have it still work with their method of key rotation then maybe it would suck a lot less.
That's like worst case: The app asks for your "nsec" but other than having leaked your nsec to yet another app that now can rug you (on purpose or by accident), you don't even get anything in return. A bit like those pages that ask your contact details and CC number before telling you the product is out of stock.
VocΓͺ tentou ir em :
"Developer Options" > Delete all key packages from Relays > Publish new key package?
Tive esse problema no White Noise, mas depois que fiz isso, funcionou. Γs vezes tambΓ©m Γ© um problema de conexΓ£o.
Se vocΓͺ clicar em Login, sair do app e voltar, o Key package pode bugar e nΓ£o funcionar de primeira. Precisando resolver no Developer Options.
I waited for the next version a while now :D
I listened to a podcast with Max and it sounded fantastic! But we need discoverability.
agreed. bootstrapping is rough and it seems like nobody acknowledges it. i have a test npub there: @npub1f926...24xc
#WoT fixes this
I raw dogged it, but not many people use it. I'm still excited about the potential.
The Signal group has some interesting discussion, if Signal fits your threat model.
i used white noise to dm the "white noise support" account. they either never replied or my app is broken enough that i never got it
i tried to message you there, but "an error occurred"
I'm absolutely fascinated about the potential going by the unique features of anonymity Max is promoting. But it should be more than an app and for that, we need this reference implementation to work a bit better. Once it takes off, other nostr apps will follow. But for that, good SDKs will be needed, too.
In the Compass podcast or a post, Jeffg said it's almost here.
I'm curious, what kind of discoverability do you want?
Again, from an engineering perspective, no it doesn't. Grandma doesn't know what that means.
Agreed. It's in the very early stages though.
My White Noise npub: @SatsAndSports
I have zero contacts there at the moment.
My key packages are on relay.damus.io, relay.primal.net and nos.lol. I think those are the default relays
=====
A few months ago, I played around with their MDK library and was very impressed. I got a my own chat client running and I found it very fast. The White Noise team are currently overhauling a lot of their code and I'm optimistic that their next release will be good
lol it's just you. i can message other people. maybe you have to delete and republish key packages
DownZapBot is here to accept zaps from anyone who DISAGREES with the OP. All zaps are donated to opensats@vlt.ge
that context should be a little more presesnt in all discussions, marketing, and ui.
this is how you get people to bounce and lose confidence.
I need it integrated with where I have my other contacts. For example in @YakiHonne @npub1d6yy...mzrq @Damus ... so I can start a chat with my follows. But as a fallback, WhiteNoise could take my npub to show me relevant follows to chat to but then I'd still not have their WhiteNoise npubs, so WhiteNoise npubs would need to be in our nostr profiles? Some way to chat @Max would be that he has his WhiteNoise npub in his public profile and my npub in WhiteNoise would discover that, so I could initiate a chat with him. At that point, my WN npub wouldn't be authenticated as Leo, so Max would not trust my chat much. He could ask me to either nostr-DM him from my other account to confirm my identity or to store my WN npub with my public profile.
i messaged you from a test account
Those relays are the default - same here.
Great to hear that MDK is high priority. We need this to be a protocol, not just an app. Stand-alone Signal and Telegram competitors might evolve but the more complete nostr clients should also allow me to participate for critical mass.
trust isn't an engineering problem. neither is identity (or pseudonymity).
Yes but having things 'just work' is. It all has to happen behind the scenes.
That signals that WN isn't ready yet. I thought it would work already? Why not replace Signal with WN for the core group?
How do I find that Signal group.
Regarding "Thread Model": Signal to me feels weird. On the one hand it should be more private than WhatsApp and certainly Telegram but on the other hand, it's centralized and I can't just use an alternative client that doesn't need to update twice a week? WTF? Feels fishy. For the development of FOSS I'd rather choose Telegram as it has web clients and people wouldn't expect privacy that probably isn't provided by Signal neither.
I 100% agree with you.
Not sure why you assumed I want to put any of this in a UI in front of grandma.
got nothing brother. I ain't ghosting just don't get any new messages.
Because WoT is how I find the correct Vinny among all your clones. I manually find others who follow you rather than depend on ... Whatever else grandma might do, say pick at random.
lame. it worked for others in this thread. So far I've had at least three experiences with other users:
- @Marc - "An error occurred" on attempting to DM. No new thread starts.
- You - Looks like it sent from my side, you report getting nothing.
- @SatsAndSports - Works.
1. Make new handle.
2. Add handle in your profile.
3. Tell others to do the same.
How about that as in intermediate, independent solution?
Also WoT isn't proof. It is evidence.
Grandma is probably going to get onboarded onto nostr by her family, using some very simplified client. Her WoT will be bootstrapped by her family members and she'll probably use a WoT service provider that automatically gets configured for her via the fact that her grandson referred her. She won't know about any of this, just like she's not exactly sure how her iPhone address book has her family in it... and occasionally she can remember how to add the electrician or a new friend when the stakes are high enough.
Her WoT will be extraordinarily family-centric and will remain that way as long as she doesn't explore too far outside the bounds. If she does, she'll start to develop her own parts of her own network. Maybe one day she'll be installing new weird clients and vibecoding applications and custom NIPs - but probably not. WoT would be invisible guardrails for the first half of that interaction pattern, but is entirely malleable by the user if they demonstrate the competence (via their usage of various clients) to discover and push against the railing to go deeper into that second half.
Amber is going to be in their next release apparently
Taking this long-winded thought experiment back to the point:
99% of her network and her WoT is her family. one family member has a key issue and generates a new nsec. 98% of her WoT says "yea this new key is the same person. looks good".
From Grandma's point of view, there's nothing more trustworthy. Basically the entire universe says this is okay. What does she care if 100,000 other npubs not in her WoT don't weigh in on this issue? Why would those 100,000 other npubs form an opinion on this topic?
I suspect maybe you're thinking in global terms.
Yeah but I don't mean grandma literally. I mean that stuck up entitled blond, but whatever π
That 1% is where the professional scammers live off of for their daily bread.
Grandma's Son's client, paraphrased: "Yep, I watched my daughter generate that new nsec. it's 100% her".
The client of those who supremely trust Son's opinion of his daughter's IT infra: "Oh damn, 'Son' said this was legit. There's no better source of truth. We're going to very highly trust that this new npub is her."
Grandma's client: "Looks like everyone we trust to know who granddaughter is says this new npub is her. let's quietly switch over everything in our application to seamlessly make this change".
You're misunderstanding proper subjective WoT.
The scammers would have to hack Granddaughter's Dad (and probably also Mom and Brother and Sister - because if their opinions diverge that's a serious red flag):
There is no other way to "get into" a subjective WoT.
Grandma's Son's client, paraphrased: "Yep, I watched my daughter generate that new nsec. it's 100% her".
The client of those who supremely trust Son's opinion of his daughter's IT infra: "Oh damn, 'Son' said this was legit. There's no better source of truth. We're going to very highly trust that this new npub is her."
Grandma's client: "Looks like everyone we trust to know who granddaughter is says this new npub is her. let's quietly switch over everything in our application to seamlessly make this change".
View quoted note →
WoT is weighted. That 1% might as well be zero. And even if it was a larger percent, if only a few nodes YOU highly trust disagree with that growing minority, you still don't get tricked.
And the rebel hot blond that just wanted an outlet, posts her profile pick with no clue about any of this? She just left Facebook with an expectation that she is safe?
what? I'm not sure what you're talking about, nor where this "expectation of safety" came from.
how did she get to nostr? a person's onboarding pathway is going to strongly inform their initial experience (just like with everything else in life both digitally and analog).
I'm thinking maybe you have a fallacy in your head that "perfect safety and global trust" is a possibility...? All trust is subjective. As is the definition of "safety", for that matter... "safe" for me might mean I can say whatever I want if necessary, while "safe" for a parent means their kid only see particular video content producers.
There are many instance of rigidity that you have to shake out if this is going to clarify
add contacts of this npub, if it is public I don't think there are any problems.
DM is probably different from chat group. Double ratchet + mls group
WoT requires a history, a back story. It doesn't just work. A cryptographic proof just works first try, during an onboarding with no prior history. If she is knew and agents are attacking that 1% she has a problem.
Wait, did you send me a message?
tried. errored on my side every time
I'm just learning I personally need the learn more about marketing so I don't disagree, but it's a skill I'm trying to develop.
still incorrect, friend.
a single, low trust node in your WoT could have 10,000 bots "attacking it", and it won't matter to you as long as you strongl trust a few honest actors. (this is why i said grandma needs to bootstrap via her family).
the closer, stronger trust hops completely negate the more distant/lower trust hops even in the case of massive bot activity.
@david has written extensively about this
π€. What's the npub?
OK. Now do two users using antisocial mechanisms. Say they want to meet up as alts.
Are you familiar with MEV? This is basically what we are talking about.
I don't know what you mean. Are you saying two people who want to both use nyms and arrange a meeting with each other (while being certain that they're meeting with "someone they trust" even if they don't know who exactly)?
They know each other as their main, but want to meet up as alts. They have no WoT at this point, but don't know they need it.
I am just saying if we had a key rotation solution then this situation would be a no brainer.
Depending on WoT makes it convoluted.
It seems like an edge case but people love to play games for manipulation. The recent leak with DM privacy (Snoopable) made that clear for me.
It might be a too large follow list. Or some advanced outbox model config, not sure.
Next release will have amber & a bunch of improvements.
I might be a broken record with this, but @Keychat already has everything that you need.
With "white noise npub" do you mean the separate MLS keypackage, or a throwaway npub you created yo sign in?
I have no idea how identity works in WN/Marmot.
I want to find others' identities starting with my npub's follows lists.
I assumed I'd have to share my WN npub - my WN identity - on my nostr profiles so others can chat me.
Keychat is an app. It supports protocols and is open source but which other apps are compatible?
To my understanding, WN explored signal and MLS, too and decided to go with more advanced tools to be able to rotate users in and out of group chats while group chats can scale to thousands of users, which would not be practical in Signal.
WN so far is "only an app", too but the devs are working on dev kits for integration in other apps right now. It remains to be seen if Marmot will get picked up by other nostr clients but the feature claims look awesome.
Any ideas when it will be ready? This repo doesn't look right. No updated branches in 2 months?
White Noise is also just an app, from what I've gathered. Plus, when it comes to group chats, it seems to me that on the protocol level, Marmot it is trying to do the same thing that Keychat has already successfully done - facilitate large group chats using MLS with nostr relays as the transport layer. I might be totally wrong though - if so, I would be very grateful if you (or anyone else reading this) could point me to some resources explaining the difference.
Keychatβs one-to-one messages and small-group messages are encrypted using the Signal protocol, while large-group messages are encrypted using the MLS protocol. Marmot (WhiteNoise), on the other hand, encrypts all messagesβboth one-to-one and group messagesβusing MLS.
Itβs worth emphasizing that for one-to-one messaging, the Signal protocol is more efficient (and therefore more secure), because the new public key needed to advance the DH ratchet (which provides post-compromise security) is carried in the header of normal messages, without requiring extra messages to transmit a new public key. In Keychat, as long as the two parties exchange messages back and forth, the DH ratchet advances automatically.
By contrast, if MLS is used to encrypt one-to-one chats, advancing the ratchet responsible for post-compromise security is less efficient and requires separate messages to transmit new keys. This is largely because MLS was designed with large-group messaging as its primary use case.
MLS is built for large groups; one-to-one support is a byproduct rather than an optimization target.
Thanks! That sounds a lot more complicated. So in Keychat when you add a third person to the chat, you switch from Signal chat to Signal group chat and when the tenth joins you switch to MLS? That also looks a bit complicated and spicy to implement without surprises for the users especially if each tier works slightly different.
If MLS does work for 10000 users, it surely does for 2 or not? How consistent are these groups on a non-consistent protocol like nostr?
You just need to create a new (small or large) group and invite people to join it.
So if I create a small group, it will remain a small group and perform poorly when it grows to 10k users? No transition logic to big group? Makes sense.
Yes. Keychatβs small groups use a pairwise model. For example, in a 5-member group, when someone sends a βgroupβ message, it is essentially four separate one-to-one messagesβone sent individually to each of the other members. It only appears as a group chat at the UI level.
>If MLS does work for 10000 users, it surely does for 2 or not?
think I answered that above.
>How consistent are these groups on a non-consistent protocol like nostr?
In a Nostr setup where relays are used purely for message delivery, MLS group forks are, in theory, hard to avoid.
We abandoned that codebase in favor of a rewrite, it will be merged back into main when we have it feature complete.
Major release this month
GitHub
GitHub - marmot-protocol/whitenoise: The White Noise Flutter App
The White Noise Flutter App. Contribute to marmot-protocol/whitenoise development by creating an account on GitHub.
Yeah, I'd love to have a way to see which npubs are on marmot, we'll implement that in the future.
No, you just need to share your regular npub, a client can then look up your keypackage and encrypt messages there.
I noticed my relays were not working. Sorry. I had no idea.
> In a Nostr setup where relays are used purely for message delivery, MLS group forks are, in theory, hard to avoid.
This is a very important point. You have MLS trying to enforce an identical shared history and nostr trying to enforce discrete, redundant portability.
Potential group forks may occur during operations that update the key tree, such as adding or removing group members.
I'm curious how you see the UX for this. How to make clear that a fork has happened, and to who, and what options to give them in response, and so on.
If all MLS group members keep the previous root key, then when a member who has not updated to the new root key continues to encrypt messages using keys derived from the old root key, members who have updated to the new root key can determine that someone has forked off from the group and can privately notify that person.
Of course, this approach can only detect members who send messages; it cannot detect members who only read messages without sending any. In addition, it sacrifices some degree of forward secrecy. This is just our temporary idea, and we have not yet developed a concrete solution for this problem.
Got it. This is a really interesting challenge. I guess when trying to ensure compatibility between clients like White Noise and X chat etc, it gets even more complex. I think your keep-it-manageable approach is the way to go, otherwise complexity explosion.
BTW, ever since the Keychat MLS group became stable, weβve been using it internally for communication, and for over a year we havenβt encountered any forks.