Alex Gleason

I haven't had time to review thoroughly yet. But my first gut reaction is that adding a dependency just for zaps should be avoided.

Doesn't Alby already emit some kind of event when the user switches accounts? @bumi

I thought so. I remembered seeing it in the Alby code while digging around. But I think extending `window.nostr` with an extra property (`.on`) isn't the best way to do...

It's possible to bridge nip-04 messages with ChatMessage activities on AP, but I'll probably never do it. I'm mostly happy with things being "broken" at the moment. What if someone...

It's an incorrect usage of the semantics. And if clients do that, they'll never change it. Do you realize how hard it is to just coordinate lunch with 5+ people?

@jb55 If you were to add a warning, I would suggest something like this: > This user is bridged from an external network. Your message may not be seen, and...

@rikmeijer I think Nostr can still be integrated with shared hosting. It just can't be a relay. But it can be a client. That's still powerful. Most relays are public,...

I think most of the desire for HTTP is actually a misdirection of a feeling that Nostr is already extremely hard and it's bullshit this WebSocket thing adds another layer...

I managed to publish JSX, eg: https://jsr.io/@nostrify/react/0.0.1-alpha.6/login/NostrLoginProvider.tsx But when using the package in a vite project (also with Deno), I get an error: `Uncaught TypeError: jsx is not a function`...

@dsherret Check out the pragmas at the start of this file on JSR: ```tsx /** @jsxRuntime automatic *//** @jsxImportSource npm:react@^19.1.0 *//** @jsxImportSourceTypes npm:@types/react@^19.1.0 *//** @jsxFactory React.createElement *//** @jsxFragmentFactory React.Fragment */import...