I'm learning about spaces and was discussing the idea of requiring a pubkey's consent to getting named. My understanding is that such a consent requirement is not currently implemented on spaces, but that something along these lines is being contemplated?
If so, consider an implementation which accepts signatures by delegatee keys as satisfying the consent requirement for their delegator / master key. This will enable cold storage identities which don't sign anything themselves to get names.
See this thread for more discussion of this👇
quotingAs for the spaces protocol trying to implement cross verification (i.e. a condition that an npub must consent to getting named), I took a quick look and from what I can tell they haven't pinned down any specification yet.
nevent1q…rcqr
So then the question is what shape that consent check will take on spaces. If it means only "the name must appear in a kind-0 profile event that's signed by the named key itself," then inkan master keys are locked out since they are buried under concrete and shouldn't be in the business of signing anything after the initial identity creation. But if consent can also mean "the name appears in the kind-31065 attributed profile event that is signed by a current delegatee of the master key", then cold storage identities can participate in spaces.
Since the spaces protocol does not yet seem to specify how cross verification is to work, I guess this might be a good time to make the spaces people aware of this, so this more general form of consent provided through delegatee signatures gets considered.