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.
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?
Yes. It melts and remints to prevent double spending. Users get a response online after this process.
Fantastic! Nice work.
And thanks for all the help/responses!
Thread collapsed
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?
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.
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.
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed
You’re right on all of that.
And of course you don’t need port forwarding if you’re hosting via Tor.
Thread collapsed