NIP-XX - Nostr Token Login

[arthurfranca]

The token (NIP-19 ntoken) will usually be created by the client trusted to store the user's private key.

The idea is that other clients should support user pasting their ntoken to login (creating a temporary session) instead of pasting their nsec.

I know NIP-26 was not intended for this because clients not supporting NIP-26 will be full of faceless users publishing stuff
but this is probably better than users pasting their nsec at every client they want to test.

Read here

[pablof7z]

Concept NACK + NACK at making NIP-26 even more complex (negative filter)

This proposal, as it happens with everything NIP-26 related, would make users think that scoping the session will mean that the delegation can't be abused, which is utterly incorrect, at the cost of a much more complex relay implementation and more complex client implementations.

[arthurfranca]

@pablof7z thx for the feedback. Regarding delegation abuse, yes this is similar to an unrevokable JWT. But don't you think handling the nsec is worse?

Hard to imagine the majority of users using browser extensions or signer apps.

I will think of way of revoking the token.

[arthurfranca]

I've edited NIP-26 to make it "kinda" revocable.
It works if relays follow this:

Delegated events with `created_at` in the past MUST be rejected by relays. Such delegations are considered expired.
An exception is made if the past event comes from a trusted bulk event importing feature.

Relays receiving the delegated event with `rr` delegation string param MUST check at the revocation relay(s)
if the delegation has been revoked, before saving the event.
If a `kind: 1026` from the delegator with an `s` tag with a corresponding delegation string is present
at the revocation relay(s), the received delegated event MUST NOT be saved.

So the more NIP-26 supporting relays, the better.

Can't think of a better way.

[pablof7z]

this is incredibly complex, imposes a brutal tax on relays (and clients) and forces relays to query other relays for state; keep in mind delegation tokens are not "created" at any relay; they are bearer tokens; is the relay supposed to check all the rr relays every time it sees a NIP-26 token come in? keep a cache and risk accepting revoked events?

this is why NIP-26 is terribly bad; it's radically incomplete and every attempt to fix it increases its complexity and centralization forces exponentially

[arthurfranca]

is the relay supposed to check all the rr relays every time it sees a NIP-26 token come in?

Well noticed, it is a burden. I could limit it to one rr param but I will think of a better way.

[arthurfranca]

Closing this as NIP-26 is really a pain to implement right on clients. Also nostream has already dropped support for considering the delegator the event author when requesting events.