Just added to Amethyst's latest update. HUGE improvement!!
Also glad to hear that the Docker container worked as expected!
Awesome! I started working on a mini UI page with just the bare minimum required fields to send a delegated note.
Will make it a little easier to send real-world delegated events.
Amethyst needs that, too!
Quick demo of https://nostrtool.com
#nip26! Pretend that your newly generated Nostr key is your main identity key. Create a new NIP-26 delegation token to authorize a different key to sign your behalf.
Then... USE IT! Actually sign and publish a delegated event! It'll look like any other post from your main identity key, but it's actually signed by your delegatee.
NIP-26 means we could get our main identity keys offline and only keep disposable delegatee keys "hot" in Nostr apps and browser extensions!
BOOM! Thank you!
Just realized I denominated the goals in USD. Oof. Blew that one.
Yeah, I was thinking about that eventually. Would be a nice option. But this was already way more JS than I have any business writing! Hopefully people (mostly devs) will find this useful and will PR in improvements like this.
Amethyst is the best client I've used so far.
Did the best with rendering my long note:
@note1d7xf8edjgraas74z6lkcvr8288fvgdjt7w8ydf6t7dhpzyr4gg0sgegpsm
And seems to handle messy threads/replies the best, too.
Is there already an event pruning setting to limit storage size?
In the extreme case, doesn't that degrade to essentially having to connect to one extra relay per person that we follow?
Bitcoin nodes talk *to each other* and share data so that they're all ready to share that vital info with a client (i.e. your wallet app). But Nostr relays don't gossip w/each other afaik; they can only broadcast what people have directly published to them.
The only time notes get propagated out to further relays is when someone boosts it to all of their connected relays, right?
I couldn't quite finish off my #[4] demo showing off full NIP-26 support. But it's close. Just some last bugs to make sure it conforms to what relays are expecting.
#[0] + Nostr demo time!
Starting w/the simplest flow:
* Generate a new BIP-39 bitcoin seed totally offline
* Derive its Nostr `npub`/`nsec`
* Export to Nostr client via QR code
Part 1:
True. But already spending way too much time making this UI look nicer than it needs to!
And our UI widgets don't have any easy way to selectively color bits of text. I'd have to position a totally separate text widget just for the `npub`.
In working on these screens I just found it easier to read; kind of lets your eye just skip the prefix, BUT the prefix is still there to make it clear that these are `npub`s.
Without the colon it takes just an extra beat to find the starting point that matters.
Signed. Metadata is event `kind=0`.
Back and forth between your legit LN addr and a hacker's or changed to diff ones sequentially?
e.g.
yours, hacker's, yours, hacker's, etc.
or
yours, X, Y, Z
Amethyst displayed my LN Address field as blank, even though I'd set it previously in Damus. But it wasn't replaced with anything fishy. I set it again in Amethyst. Presumably it's good now. Snort is showing it as expected.
Testing out signing Nostr events in #[0]
Are there any Nostr clients that will let me paste in the event signature myself?
`nos2x` gets me halfway there since I can at least grab the raw event json and prep that for signing.
And, yes, I can broadcast my signed events manually from python, but itâs a little clunky.
NIP-26 is delegation, but that doesnât help if your main identity PK is already âdirtyâ from being stuffed in a browser.
Need an identity migration NIP, if one doesnât already exist.
Iâve been thinking of something like a pre-dated http 300 redirect:
* my current key X would say that new key Y will be my new key starting at timestamp (which can be in the future).
* Yâs metadata confirms: I came from X
Y points back to X to make it easy to follow the identity migration chain backwards. But that alone canât be authoritative because scammers could just claim to be your next key.
X has to point to Y to prevent the above identity migration hijacking.
If you change your mind and want to migrate back to key X, you can just clear the migration fields on key X and maybe for convenience set some kind of `reversion` flag on key Y to redirect back to X.
And why a future timestamp? Allows you to have a migration plan in place in case you ever lose key X. You donât necessarily plan on using key Y but itâs there to preserve your identity if you need it. Your client could regularly push the migration date for key Y off another 30 days or whatever.
Oof.