Not being able to quickly and safely sign into another client or device is such a friction with Nostr. I really think it’s the most important problem to solve in the short and medium term. And I do ...
> I’ve thought for years we just need a key signing delegation. It’s the equivalent of session cookies online. The problem simply requires a robust and decentralized way to sync and share active “session keys” that can be safely and quickly revoked when needed.
This is an important distinction though. "Session cookie" concept is a widely different architecture that rely on a central authority that determines authentication. Provide a common credential in exchange an authorization material.
There is no authority here, which makes distribution of authorization material difficult and requires absolute consensus across the entire work - ish. We have some proposals, but even with my design with backward compatibility, it only works if _every_ client implements it.
Let me brake down your statement. As if it was simple, we would have just done it.
1) sync and share active “session keys”. Just any event just just be signed and published. Cool so you sign a "session" or "delegation" event with your "root" identity. Your identity has been delegated iff this event is respected by clients, and relays... relay the event. How does a client know that the delegated event signed by your "session" key is "real" or can be trusted. Discovery becomes difficult but solvable but again must achieve total consensus for it to work at all.
2) safely and quickly revoked when needed.
This cannot happen efficiently, and most proposals don't respect the idea of revocation. What happens in the absense of the revocation? Nostr does NOT guarantee consistency with respect to time. So if the session is revoked, what if the revocation hasn't made it to the user yet?
3) These session keys must be treated as nearly ephemeral data, for security reasons, otherwise stale links to session tokens could cause a split. Requiring _every_ client churn it's cache all the time waiting for a possible revocation.
> I don’t see anyway we get the “web experience” but also the security of signed messages and not needing to trust the host or relay without it. I’d love to hear other ideas for it though. I’m working on what I described above right now though.
Correct. We simply cannot _have_ the web experience in a decentralized way. That's due to architecture, the web experience is only available now because all data is stored by the central authority on their servers, you have absolutely no responsibility to store anything yourself, you assume the server's got it.
The server owners bear
1) Managing your identity and other site information on their literal hard drives
2 Guarding your identity from your own mistakes.
Nostr _cannot_ do either of those things. Bitcoin cannot do either of those things.
This is an important distinction though. "Session cookie" concept is a widely different architecture that rely on a central authority that determines authentication. Provide a common credential in exchange an authorization material.
There is no authority here, which makes distribution of authorization material difficult and requires absolute consensus across the entire work - ish. We have some proposals, but even with my design with backward compatibility, it only works if _every_ client implements it.
Let me brake down your statement. As if it was simple, we would have just done it.
1) sync and share active “session keys”. Just any event just just be signed and published. Cool so you sign a "session" or "delegation" event with your "root" identity. Your identity has been delegated iff this event is respected by clients, and relays... relay the event. How does a client know that the delegated event signed by your "session" key is "real" or can be trusted. Discovery becomes difficult but solvable but again must achieve total consensus for it to work at all.
2) safely and quickly revoked when needed.
This cannot happen efficiently, and most proposals don't respect the idea of revocation. What happens in the absense of the revocation? Nostr does NOT guarantee consistency with respect to time. So if the session is revoked, what if the revocation hasn't made it to the user yet?
3) These session keys must be treated as nearly ephemeral data, for security reasons, otherwise stale links to session tokens could cause a split. Requiring _every_ client churn it's cache all the time waiting for a possible revocation.
> I don’t see anyway we get the “web experience” but also the security of signed messages and not needing to trust the host or relay without it. I’d love to hear other ideas for it though. I’m working on what I described above right now though.
Correct. We simply cannot _have_ the web experience in a decentralized way. That's due to architecture, the web experience is only available now because all data is stored by the central authority on their servers, you have absolutely no responsibility to store anything yourself, you assume the server's got it.
The server owners bear
1) Managing your identity and other site information on their literal hard drives
2 Guarding your identity from your own mistakes.
Nostr _cannot_ do either of those things. Bitcoin cannot do either of those things.
2
