Nostr Web Client

awesome thanks! I had a similar idea to this, a marketplace for models and users. Brilliant. Glad someone else made it first haha.

All requests go through the proxy right? And the proxy communicates with the OpenAI-API-compatible model endpoint?

So, correct me if I'm wrong:

1) if the model endpoint is on a different network/host, the port will need to be exposed

2) the proxy address is the address that we advertise on nostr and the one that clients will connect to

3) the proxy therefore needs to also expose ports on the network

4) If you're running this at home, you'd need to port-forward at the router AND your public IP would be exposed, unless using Tor hidden services.

rewolf 5mo ago

And one more question.

I see on the github README that the proxy "validates and redeems the token" .

What is meant be "redeem"? I assume it doesn't mean melting and reminting to prevent double spending? That would need to be done as a follow-up?

Reply to this note

Please Login to reply.

Discussion

redshift 5mo ago

Yes. It melts and remints to prevent double spending. Users get a response online after this process.

redshift 5mo ago

only after this process*

rewolf 5mo ago

Fantastic! Nice work.

And thanks for all the help/responses!

rewolf 5mo ago

And I see the .env requires an NSEC, which I would rather not provide. But it looks like it's used in the cashu.py (haven't dug into it) maybe for creating the cashu wallet/identity (whatever the term is) and for validation etc.

Do I need to use the same nsec for announcements as the cashu wallet?

rewolf 5mo ago

I would assume so.. that the npub of the announcement is used by routstr client for sending the cashu tokens, and then the cashu wallet uses the same nsec to redeem/validate the tokens.

redshift 5mo ago

No. Not actually. The nsec is used to store your Cashu balances in Nostr relays using Nip60. You publishing an event on Nostr is only for discoverability.

rewolf 5mo ago

Thanks for clarifying!