PABLO has best config !

What a view man, holy sh!t. Happy for you 💜

Amazing

Great climbing sticker.

It is a lot. I am floored. I will do my best to make all proud 💜

#newbie moment for me 😂

ZapLife.lol compliments of the great dev #[3]

#[0]

I found a bug in #zaplife, or is it a feature request?

There is a comma at the 6th place from the right to mark the millions. This is good.

Similarly we need a comma at the 3rd place to mark the thousands, like we do in the western numbering system.

Noticed it during today's #zapathon

str8 facts bruh

Así es :)

Best birthday cake ever from best novia ever! Pura Vida 🤙

Best birthday cake ever from best novia ever! Pura Vida 🤙

How did you type that? Do you understand the characters?

the yield is the friends we made along the way

#[0]

What a fantastic reading experience this site offers

Your NDK may solve it. I haven’t taken a look yet.

I guess things like relay management, where it reconnects as needed. Or, maybe it has a relay pool of 5, and only connects as-hoc to publish or request a single event. Then WS close.

Somehow tracking per event per relay, if a publish was successful, relay said it was a dupe, timed out, errored or relay never connected.

Even using the window.nostr is great - but you can’t use it at first because it hasn’t loaded. So you need a way to test if it has loaded yet. UI can depend on it being found/loaded - and obviously calling functions too soon fails.

Maybe simple stuff too like remembering loaded relays for a user. If I refresh the page, why do I need to load from extension or kind 10002 so soon.

Things like maybe using shared state across tabs. We can share the relay connections, instead of new ones per tab - fairly sure this is possible.

And even things like if I provide a addr with relay suggestions, try query them first, then fallback to others. Or when I query for an event by id, can I kill/ignore all the other results that were too slow.

Maybe optional event signature verification for relay responses. Sometimes you want it sooner and sometimes perhaps delayed for performance for different processing.

Perhaps some optional pubkey cache.

That’s a start of some ideas anyway.

Your NDK may solve it. I haven’t taken a look yet.

I guess things like relay management, where it reconnects as needed. Or, maybe it has a relay pool of 5, and only connects as-hoc to publish or request a single event. Then WS close.

Somehow tracking per event per relay, if a publish was successful, relay said it was a dupe, timed out, errored or relay never connected.

Even using the window.nostr is great - but you can’t use it at first because it hasn’t loaded. So you need a way to test if it has loaded yet. UI can depend on it being found/loaded - and obviously calling functions too soon fails.

Maybe simple stuff too like remembering loaded relays for a user. If I refresh the page, why do I need to load from extension or kind 10002 so soon.

Things like maybe using shared state across tabs. We can share the relay connections, instead of new ones per tab - fairly sure this is possible.

And even things like if I provide a addr with relay suggestions, try query them first, then fallback to others. Or when I query for an event by id, can I kill/ignore all the other results that were too slow.

Maybe optional event signature verification for relay responses. Sometimes you want it sooner and sometimes perhaps delayed for performance for different processing.

Perhaps some optional pubkey cache.

That’s a start of some ideas anyway.

what do you mean?

I was playing around with this prototype a few days ago. The JSON editor is simple, but nice to use.

I think this prototype is in hibernation for now… but I haven’t found any Nostr JS libraries that really solve the key repetitive utility functions I use often. Either too high or low level - I think there may be an opportunity for the gap.

Proud to represent sandwiched between #[2] and #[3]

Amazing. This is all super helpful. One thing to note, some of what’s there isn’t quite implemented yet. 😅 buffered queries are in that list I believe.

Eventually, I’m planning on building a docs microsite for NDK to show more examples of usage and full documentation of the types and objects.

you send me a little bit of energy, i send you a little bit of energy.

sounds hot.