Can we do a version of Nostr where you follow somebody's xpub instead of the pub key?
In that way, every new post, likes, zaps uses a new public key, which is derived from my seed words. Only people that have my xpub will be able to know my next npub and follow me. đ¤
NO NYGGA ENOUGH WITH THE FOLLOWERS MAN SEND FOOD MONEY FUCK
Whatâs the goal of this? What is the use case?
Also, does the person sending events have to select a new npub every now and then, or will events be fired out randomly using different npubs?
Randomly. So every post looks anonymous until you get the person's xpub. It's similar to using a new Bitcoin address for every transaction.
At first I thought you are somehow linking X id with #nostr npub .. xpub :-)
What happens if someone ( without my xpub) follows me ? ..
They can't. That's the point. :)
Thatâs how you keep the boomers out
Boomers as well as anyone you don't want to know who you are .. privacy in open ..
This is a wonderful idea - as a facebook or email replacement ..
Unlike Twitter , on Facebook we want only close family and friends to follow us .. we can share our xpub with them .. for the rest, our notes would be anonymous..
On email - a message may be open to everyone.. but the identity is associated only by those who got xpub ..
At client level - users may toggle between notes from known people ( xpub) or anonymous notes -
Anonymous notes can be bold free speech ( without fear or persecution) - but still limited by reputation of their xpubs .. which is a good thing ..
Where would I store my copy of your xpub?
so a version where... nobody can truly follow you unless they've managed to know your xpub?
Yep
xpub would be good for cross-protocol identities đŚđ
Are you saying xpub can be linked to X :-)
The computational load would be crazy. Imagine checking each note to see if the author key *is derived* from one of your follows' xpub...
We could make a filter by xpub instead of the pubkey :)
Doesn't that mean relays would have to index events by xpub and thus they can deanonymize any note author?
critical flaw:
xpub derivation works by putting the chain code C and index I through a hash function to get a modifier private key m
using the base private key b, you can calculate the derived key as b + m
for public part, m can still be calculated (chain code and index are public), but you only get base public key B
you convert m to a public key M, and calculate B + M, and that is the public key for b + m
now if b + m, the derived key, gets leaked, and the base xpub is public, m can be calculated and subtracted from b + m, to get b
you can from there calculate any other derivation path
the solution is hardened derivation but hardened derivation can only be calculated via xprv, not xpub
Yeah indexing will be harder, unless the client breaks it down and queries by a set of pubkeys directly. But for that to happen, relays must abandon the filter limits they have today.
Essentially, they will have to go develop a function in say SQL that assesses if a pubkey is inside the set of an xpub or not. Key derivation is heavy, so maybe there must be a new xpub crypto scheme that makes it easier for indexing.
Yeah, key derivation is hard. Wallets that went through a lot of whirlpool mixes are very deep in their address derivations which causes most electrum server implementations to be very slow in those cases.
That's why Fulcrum was recomended, or even Samourai built another backend (the dojo) which was just a wrapper sql DB for fast lookups from an xpub.
Imagine having several sub feeds per seed by simply exposing followers to separate key derivation paths. You can build your specialized feeds in a folder structure.
That was the core idea of my nip41 proposal
Thatâs the way. Following should not be easy. We should âdo the workâ to get our friends notes. Frequently asking them their signed pubkeys list thru p2p.
The issue with exposing your xpub is that xpub + any child priv = xpriv
But priv keys will be used only once. There is no need to expose the private keys.
I was thinking in the context of nips 41 and 109, and around how to improve key safety. Imo master key should never touch a mobile device - if you donât let the master key touch a mobile device or other low trust environment, but you do let a child key, then if you expose your xpub, it undermines the whole security model of having a well protected master key.
A more clumsy but functional option is to list child keys signed by the master key
yeah no, my suggestion was for regular anonymous posts, not for DMs or identity management. The point was to have a seed that you can expose your xpub to friends and colleagues, but not to the whole web. It can leak, so it is never actually private.
I see. It still reduces the key security overall but I understand what youâre going for.
Might solve the exposed social graph problem by confuscating it more
