Nostr Web Client

If i get some time I'm going to stump for NIP-102 some more

The DM/notification thing is tricky. It can become very complicated with subkeys. And we hate complications... :)

Are notifications tricky? The DMs are harder, though do people really want to receive them on every client? And KISS, but maybe subkeys don't need to be hard? If you already support deletion (for renunciation), you're most of the way there.

Imagine the mess that is a revocation record that exists in one relay but not on another. Half of your friends see your main account as active and the other half misses it and fall for an attacker's scheme.

Then sum that with the fact that you can delete the revocation record itself (or put an expiration date) and revert the position you had before in the app. Users confused everywhere.

Now imagine that with users having to migrate relays from time to time because of censorship. Some records can stay in the old state because paid relays don't allow you to update them.

Now imagine that mess when an attacker gets hold of your nsec and starts publishing events in the past. Keys that were supposed to be part of yours are not there anymore and vice versa. Old content disappears and new content comes up to all your followers, but depending on which relays they are subscribing to, the changes are different.

It's a mess.

Same as deletion. Same as anything really. We could put revocations in your profile, and then you'd have to argue that people won't realize this random npub isn't YOUR random npub because they couldn't load your profile 🤣

It's not the same. Yeah, you can make a mess with deletions today, but adding key revocations adds an order of magnitude of additional mess. It's way more complex. The attack space and thus app complexity grows.

I guess I'm missing something then. If you support deletion, my proposal allows revocation using the same mechanism. The only difference is that it's deletion of all events by a pubkey, instead of one specific event.

Yeah, that's the problem. It's a semantical difference. Instead of clients just needing to worry about one key for each follow, they now need to wipe and re-download large event sets when sub keys move. I can even imagine a DDoS attack purely based on revocations status changes.

My 102 proposal uses a single identity key, and the ability for any key to sign on behalf of the identity if it has an attestation. When you get an event, you immediately know whether it's authorized to impersonate the identity key, so you just treat it as the identity pubkey. If it's revoked, you delete the event, just as you would with a deletion request. So, everything operates as it did before (following one pubkey), except you can issue new keys without telling anyone, events signed by them look like you, and if you get burned, you delete all those events.

That's exactly the problem I described. I think you are underestimating your proposal's real impacts on clients.

For instance, what happens if a replaceable event has an attestation that keeps changing to different identities every second? If you add those attestations to NIP-51 lists, now apps are immediately reacting when the list options change, all relay filters change, the whole web of trust ranking keeps switching.

That's an interesting case. I don't think this will happen in correct implementations because either the replaceable event will be treated as the identity key (having implemented 102), or the signing pubkey (having not). Either way the identity of the "current" event won't change, even if the signing key uses rotating attestations.

Key management is definitely a big deal, and in distributed systems rather intimidating. But having worked on SSO in the past, the current situation is risky and holding nostr back. Fixing it won't be easy, but doesn't need to be complicated if we work out the details.

کیهان 1y ago

i love the one key model.

me too 💜

Orthodoxtr 1y ago

One key to rule them all

it feels like one of the main value propositions of #nostr is the fact that “a single key can open all” and that you have everything everywhere all at once.

it doesn’t bother me yet that some clients identify some follows and other others, or that notifications are not always the same. makes me actually wonder why and visit many clients depending on the info I’m interested in.

however, if we go to multiple keys and clients, it feels like it goes back to the fractionalized model that people already have in the current siloed models of insta, twitter, etc…

am I missing something?

cheers!

Yep. The issue is that separating Notifications and maybe even DM conversations between apps can get quite complicated. Imagine talking shit about life with your gaming friends and then load all those DMs in your work app later on. Same for family chats and tiktok chats.. It feels very off. There is a different level of trust/security in the user's mindset when using separate apps.

In that sense, I’m inclined to think people may opt to have different “subkeys” if possible for different usecases.

Right now in my case, I have different npubs for DoShitters than for my personal npub where I post and follow different kind of stuff, but I love that with both of my “identities” I can surf in all the clients I wish.

FLASH 1y ago

It's a complete mess if I have to make a key every time. I'm in favor of centralizing everything under a single key because the ones I follow here, I would like to follow elsewhere as well, and vice versa.

finity 1y ago

single pub

Jordan S 1y ago

Perhaps have a primary key, and then sub keys which allow you access across platform but not revealing your primary key.

A fine medium, protects your NSEC while allowing multiple sign in.

Sub keys could be revocable, or have read/write privileges enabled/disabled, and just be made to copy, or mirror content relayed from the primary key.

Might be helpful to multiple platform interaction for those who use multiple instances.

Key revocation is one of the most complicated schemes one can build. It opens the door to attacks that don't exist today and now suddenly every client needs to worry about multiple keys. Nostr is suddenly not simple anymore.

Liberty Farmer 1y ago

So you'll have it done by mid month?

No, I don't think I like any idea that involves key revocations.

Liberty Farmer 1y ago

😂😂😂

Let's not forget that attaching everything to ONE key means that when that key is lost, everything goes with it. There is no "I lost my tiktok key" with out also losing your "family chat key"

can a model like subkeys be implemented to minimize these risks?

or in case your one key is compromised?

FLASH 1y ago

Even with this argument I prefer a single key

Eric FJ 🪬⚡️ 1y ago

People can have multiple pubkeys if they want for different *self-directed* purposes, but there’s no question these should all be usable across Nostr apps. That’s the killer feature of this protocol: a social network with identity/reputation that transcends application boundaries. Single app pubkeys would make this whole endeavor largely pointless.

Key based identity is inherently single key, just need to not be retarded with access control

auth.shock.network

You should do a Signer app. There is no need to self-host a signer. :)

Signer apps miss the point entirely, its team members and external services need an access controller... Large companies and brands can't bring their value to nostr otherwise

Ohhh ok, yeah that makes sense for companies but not really for regular users.

Dual use, regular users just want email/passkey auth and it can do that too

Not really. In 2 years and 200K installs no one has ever asked me for user+password logins.

Bias selection, How many didn't use it at all? or simply lose their keys eventually? not return? not use nostr cross-device?

Nostr is still irrelevant, the status quo is nothing to celebrate

How many users do you have?

Keneci Network 1y ago

Single key is always better

What's a user? A unique key? An "install"? Visitor? Payment?

The only correct answer is not enough.

The only KPI is revenue

Sure... But I am trying to understand what is making you think that users want email+password sign up. It would be nice if you have users (not companies) that are using the service with user and password to make your point.

Otherwise, it's just wishful thinking.

If I was you, I would focus entirely on corporate accounts. Those are the only people that must keep their nsecs online.

I'm focused on people that have no idea what nostr is and/or don't care, that's the 99.9% of people/companies on the internet not using it.

They don't necessarily want email/passkeys, but they expect it. They can't benefit from Nostr until they're met where they are.

The expectation makes sense and I think the product for companies also makes sense. I think it makes way less sense for single users.

But I look forward to seeing how well your thesis does with real users.

Sacred Peak 1y ago

can we not have our own main follows and have apps have their own too?

4th option? anyone thought about it?

asking 😇🫂

🇵🇸 whoever loves Digit 1y ago

I've been thinking a separate key with the nevent files backed up regularly is a good way to track shitty behavior by npubs.

A list of npubs used for a mute list or label doesn't currently tell you how each npub got on the list. If you instead had a mute list of every npub tagged, reposted, or quote posted by a certain other npub, then reposting a genocidal Zionist post from an npub that only reposts genocidal Zionist posts would allow that post to go in a mute list of genocidal Zionist posters while having the specific example immediately available.

This won't be allowed to work at the network level for a while, because devs want malware that enables abuses of power and this undermines mute list manipulators or whatever. In the mean time, it's a good method at the individual level, as long as you keep backing up the posts so later you have your list ready when the network has tools available to make it more useful.

Thought about this for a second but haven’t worked out the UX.

- You have a main key 1234 and a secondary one generated 5678 separately (non derived from main key)

- your main npub has a kind 0 profile that has information that says that your “subkey” is 5678

- your subkey has a kind 0 profile event that just says “parent” 1234

- you use key 5678 and post a message

- clients that understand this will look up key 5678 kind 0 eventand see that it points to a parent key 1234.

- clients will check kind 0 event for 1234 and also see that it confirms the subkey.

If parent npub is compromised the subkey can disassociate.

If the sub key is compromised the parent key can disassociate.

Not sure of the UX because of having to manage multiple distinct keys to manage.

I might think more about this. Thoughts?

Also the clients that understood this arrangement would have the subkey inherit the parent keys profile info and overlay it.

Garbage nsec 1y ago

Nice. Earlier I was thinking along these lines for DMs to deal with the metadata issue without requiring gift-wrapping.

-Bob creates a secondary npub, this npub has no profile

-Bob messages Alice from the secondary npub with a special event called an 'It's me message' (IMM) or some such thing. This templated message contains Bob's actual npub

-Alice's client receives the IMM and sends back an IMM return (also an event type, contains a code valid for a period of time)

-Bob's client adds this code to Bob's profile, similar to adding a TXT record for DNS verification

-Bob's client sends a "go check" message to Alice

-Alice's client sees the code on Bob's profile and marks the DM chat as as being with Bob. Code is no longer needed.

The idea being this would all run over a few seconds, and Alice would not have to know anything about it if the verification failed.

That’s interesting.

I had something similar for email on Nostr and paired contacts for high trust senders. Instead of using kind 0 it was more of using an addressable kind, sort of like an MX.

I have a backlog on the stuff I want to build…lol

Garbage nsec 1y ago

Lol yeah, ideas wizzing around here. Also the issue of maintaining all those npubs with a sign-in extension or whatnot.