Replying to Avatar redshift

Simple.

1. Clone the repo: https://github.com/Routstr/proxy

2. Configure the .env file using .env.example. Set your upstream URL to localhost as you’re running a model locally. be sure to setup your nsec to store sats in a nip60 wallet.

3. Configure models.json similar to models.example.json (this is where you set your price)

4. Run docker-compose.

5. Finally, send a note tagging nostr:npub130mznv74rxs032peqym6g3wqavh472623mt3z5w73xq9r6qqdufs7ql29s with your URL endpoint to start stacking sats!

Hit us up if you’re facing any issues. Will write a more detailed guide soon.

1. Can providers advertise Onion addresses?

2. Your site gives contact@routstr.com as the support contact, but it doesn't seem to be delivering.

3. I find the configuration step confusing as it mentions both .env files and config.json. Is the .env file just a convenience for overriding parts of the complete configuration in config.json ?

Reply to this note

Please Login to reply.

Discussion

1. Yes they can. But only Tor users would be able to connect to your provider right now.

2. Sorry about that. We'll check that. You can contact me here on Nostr.

3. Sorry about the confusion, rn config.json isn’t being used. You can configure everything using .env.

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.

only after this process*

Fantastic! Nice work.

And thanks for all the help/responses!

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.

Thanks for clarifying!

You’re right on all of that.

And of course you don’t need port forwarding if you’re hosting via Tor.

On the note about onion addresses (#1) does this mean the website (chat) also will not use onion-based providers ?

Not configured to do that right now. But that’s a good idea. Thank you. Will configure it that way.