Can you imagine how much permission you would need to ask for, how many PMs to convince, to build https://nostri.chat on Twitter?
I didn’t have to ask for shit, I just built it.
We are all still not bullish enough on permissionless innovation
If you’re not counting me in, count me in 😅😅
nostri.chat on nostrica.com 🔥🔥🔥
#BUIDL
You can’t, it supports rendering but not writing. Write something from nip26.lol and publish it
this is one of the things I love about @worldschooling; my kid is growing up seeing all kinds of climates, landscapes and people.
Fostering a huge perception of abundance.
🧡
Would love to! I have some really cool stuff on the works that I’m hoping to push live in the next couple days related to relays too 😅
Packing for #nostrica
that's the crux of the problem
if you have never typed a note and lost it due to client fuck-up your are not nostring hard enough
#[0] shilled me this extension a long time ago
https://www.youtube.com/watch?v=t67Sn0RGK54&feature=youtu.be
it's probably the most useful extension I use outside of #[1]/nos2x
try it
PV
is your nsec safely backed up, anon?
Well, my point was that no one thought about this question a single minute. Everybody just read NIP-26 and assumed it was the solution. NIP-26 is not a solution for this, it was made for temporarily delegating to third-party services because of the https://minds.com/ integration. And it was meant to be the least disruptive possible.
I can think of multiple other methods for doing delegation/revocation that would be better if the goal is to protect keys.
the thing is that even for that use case, which is exactly the use case I had in mind when I started looking at it (https://nostrit.com could be done much more elegantly if NIP-26 was better).
I think having a proper key delegation where user of both keys are the same person definitely needs to be solved,
but NIP-26, or something like it, where you can give *some* permissions to a 3rd party without giving out the full reigns to the kingdom, would be valuable.
it can easily be argued that it should check the validity of the delegation token, what's different from validating a signature? an event with an invalid delegation key is pretending to be something it's not, just like an invalid signature
Nostr-rs-relay disables it by default, nostream doesn’t (yet?)
* Relays might need to keep an index so that query for Alice returns events from Alice+delegated events
* Relays might need to validate delegated token conditions
To be clear, some of these concerns *could* be pushed to the client, although that's probably not a good idea imo.
What can't be pushed to the client in the current form is finding delegated events for a pubkey
How would NIP-26 destroy nostr?
right, but that would be if the relay understands that it should follow that behavior, no?
what I'm saying is that either the relay returns on a query for authors: alice, alice+delegatees' or the client needs to query for alice and each delegatee individually.
I like that a lot.
I do think relays still have the burden of indexing; it's either that and returning the Bob's events when asked for { authors: [ 'Alice' ] } or getting n+1 subscriptions (where n is number of delegated tokens by Alice)
yeah, I think the use cases are so different that I don't see NIP-26 and NIP-46 as going after the same use case tbh.
I agree there's a lot to be solved in NIP-26 (I'm writing a NIP-23 post with the shortcomings I see atm.
But we need *something* for key delegation/revocation imo.