There's a small model configuration issue that's tripping up llama.cpp, so I haven't been able to use goose with it yet. I've run DeepSeek r1 at a similar rate... This new Qwen model is much better than DeepSeek, though this feels like inspecting the gift horse's teeth.
Overall, this configuration is a hedge: $4k for slow inference of 1000B models. It's also a beast of a conventional server – by running proxmox as the base, you can cut things up into hundreds of useful containers.
But you need to have the patience to get into quasi BIOS hacking, hardware tuning, numa layouts, Linux administration, kernel modules, performance tuning, etc. Not everyone has an appetite for this.
Most people are going to want to buy the $10k Mac Studio with 512 GB of Unified Memory and make things work from there. But, $20k is a lot more than $4k, and you could scale down the EPYC build even farther. This guy has tested many: https://digitalspaceport.com
Thanks for the context and gist. Unable to zap.
I know... I'm testing the nostr-tor experience, and there's no way to receive self-custodial zaps when your node is behind tor! We probably need a way to request the invoice over NWC instead of LNURL
why not?
just the lightning address needs to be public.
but with NWC nothing of your node should be exposed.
LNURL needs to point to a public IP that's queried for the invoice. If you're operating entirely behind tor you can't serve this. OTOH, an unpaired npub can't ask an NWC wallet for an invoice either. There could be a standard for this that clients would have to implement. A good deal of work, but it would provide bi-directional anonymous zaps
but you don’t need to run the LNURL server. you can use a service or a privacy preserving public hoster.
NWC does not expose details about your node.
would be -> lnurl hoster -> nwc (relay through tor) -> your node.
what am I missing? (maybe not perfect but possible)
I doubt clients will adopt a NWC only or similar flow anytime soon
That works if you can trust the LNURL provider. But if someone can lean on them, or interfere with DNS, you'll lose the ability to receive zaps.
I registered my domain 24 years ago. I run whatever I want to run on the net. I'm only thinly pseudonymous.
But not everyone is so lucky. We should strive to build systems that meet people where they are, wherever they are.
"Cypherpunks write code. We know that someone has to write software to defend privacy, and since we can’t get privacy unless we all do, we’re going to write it." - Eric Hughes
very true.
need to balance what’s practical and doable.
Is an "invoice DVM" impractical?
not currently widely adopted, is it?
It needs to exist before people can use it
nostr:note1x02lvqc4uuprxxs6zjh3kmce3mylxa03vekz96u2tl26ey67fdgstlfapt
Add a mechanism to AlbyHub where anyone can ask an npub for an invoice. People can add this npub to their profile next to / instead of an LNURL, and clients can fetch invoices from this instead of using LNURL
that’s basically NWC (without a secret), why is NWC not OK?
It's exactly NWC without a secret - but that's not how NWC implementations work. I don't think this is a huge lift, though you might need rate limiting, amount limits, etc.
I'm bullish on NWC
what’s the problem with the secret?
Do you mean attaching the full connection string to your profile? I guess this could technically work if the connection was limited to make_invoice, but it's needlessly dangerous. It would be better to have a different path that could never lose all of your funds. It could be as simple as making a connection with an empty secret, and all such connections would only be authorized for make_invoice. Clients could enforce an empty secret, and warn if a profile has a connection string that contains one. These UX improvements would round out otherwise dangerous edges
it’s both just an implementation detail on the wallet side, isn’t it?
the public messages also must be processed and the wallet must make sure it only accepts make_invoice calls?
I understand the thinking, NWC would just be already there and can be used
It depends on what you're calling the "wallet". AlbyGo appears to be a wallet, but isn't from this perspective. AlbyHub is what controls the funds and makes invoices.
Ultimately, NWC code that responds to "make_invoice" should be updated to make public connections that can only make invoices. Then zap capable apps would need to look for a field next to LNURL and use this to make the no-secret make_invoice call
yep,
I just wonder if it is really worth to have this special case.
why not have a NWC connection string in there (wouldn’t that also increase privacy actually?)
clients can easily validate the connection before adding it.
any current SDK would work and clients have NWC code anyway.
If something goes wrong and even one person loses their entire wallet by posting a real NWC string to their profile, saving a few lines of code will have been foolish. NWC strings themselves are already dangerous because they're a bearer token - everything should be using NWA anyway, and that wouldn't work for receiving zaps
I just don’t really see a difference that big actually.
it’s either way some lines of code somewhere that processes a nostr message.
but yea, people do crazy things… people loose sats by posting their seed phrases everywhere.
either way the nostr client could easily protect them.
It's a few lines at the wallet, or more lines in every nostr client
why more lines?
the wallet would implement a completely new way for the messages.
I'd rather open that PR myself than have anyone lose funds
which PR?
anyway let’s see if it happens.
still need to convince more wallets to implement NWC.
I think that I'm on to something with https://deposits.ynniv.com. If it works out, the next billion wallets will be NWC. So... I'm not worried about adoption
This is also why I'm interested in LNURL functionality natively available from NWC
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed
but for sure an interesting idea I think.
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed
