Except that it wipes your custom Relay list
The most hated words at a concert:
"And now a song from the new album"...
So: user scans & pays the unique lnurl-p QR of a Charge Point ➡️ the LN backend issues a "start the charge" command through a OCPP bridge software ("Strom") ➡️ the CP returns the payable amount via the OCPP bridge to LN backend, which issues an invoice to the users LN wallet , right?
Can't you just build an OCPP plugin ("Strom") for LNbits, to do all that??
LNbits already has most of the components you need:
- Accounts. Each CP operator get its own LNbits wallet ("account") where the can and and maintain their own CPs, through the OCPP plugin
- Lnurl-p/w functionality
- supports already every LN backend
- Accounting and Reporting
- SaaS deployment possible
The OCPP plugin would be reponsible to establish the websocket to each CP when a charge is initiated, and translate Lightning (lnurl) <-> OCPP commands.
Or What say you, nostr:npub12rv5lskctqxxs2c8rf2zlzc7xx3qpvzs3w4etgemauy9thegr43sf485vg
I have no fucking clue what this BlueSky thing is everybody is fuzzing about, but this looks interesting so I'll re-boost this
I see. I just wonder if you truly run the whole "thing" (Websocket + Strom + LN node (presumably LDK/Greenlight/BreezSDK)
Strom is Typescript (I guess), and can run in AWS Serverless
https://aws.amazon.com/de/blogs/compute/building-typescript-projects-with-aws-sam-cli/
Websocket can natively be run via API Gateways
And I guess(!) also the Lightning part of the code can be run by one of the AWS services. Presumably also AWS Serverless, if just using Greenlight/BreezSDK (bit i might be wrong)
That would mean you can deploy the whole Strom-as-a-Service stack serverless, and when a new CP/CP operator comes along, you presumably just edit some config somewhere to register it, and provision its own Websocket
Oh, just saw this note too late.
Yeah, give it a shot. There's always a myriad of options to implement things in AWS: from do-it-yourself all in VMs, throught Containers, and using the fully managed services
Well, you *can* build pretty much everything yourself in EC2 (VMs) or Containers. But the recommended approach (more scalable, secure, cost effective) is to use the various managed services: API Gateway, Dynamo, Cognito, Compute engine (Lambda) and what not.
Don't really know your exact requirement though. The above is the "generic" advice.. 😉
Normally you'd deploy an AWS API Gateway service which exposes a websocket for external use. And you have you service (Lambda, ECS etc) behind that API Gateway.
https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-websocket-api-overview.html
nostr:npub1hcwcj72tlyk7thtyc8nq763vwrq5p2avnyeyrrlwxrzuvdl7j3usj4h9rq talk at 2023 Lightningcon Vietnam! 🧡
Is this like the first time these gotta give a public talk? Never seen before.
Thanks for sharing. Pretty interesting
Man, tweaking Nostr relay settings feels like fucking around with Nokia ringtones in the early 2000s
A question nostr:npub1ug84cfxczqukgt47u584208n84dcamgctmxdylg5nd0gl3en43uqm5274c: who had more (dirty) tricks up their sleeve: Bogut or Daymond?
To ACK or to NACK, as Shakespeare once wrote
Testing a new relay setup, after primal wiped my old relay list.
Can you ACK if you can see this post?
German Climate Idiots Use New Type Of Glue Requiring Jackhammer To Break Free https://www.zerohedge.com/political/german-climate-idiots-use-new-type-glue-requiring-jackhammer-break-free
Actually, a cleaver would also do.
Just have a trial run stay in Prague for Pizza Day 😉
It's in a couple of scout and you can you can scout the city
"pushed back on censorship" LOL
https://www.wired.com/story/the-kremlin-has-entered-the-chat/
Yep. Dammit
Could the same end not also be achieved simply by publishing your txs to a list of random (semi)trusted Electrum servers?
You use your own private node/Electrum server to verify incoming txs, but publish outgoing txs via a second (public, or private) node/Electrum server
actually thought about raising an issue for exactly that on sparrow a while back
That's just a ... relay, right
You set your own private relay, and configure your client to publish to it (in addition to your other, usual relays). Viola, all posts backed up in your own database.
Yeah but that (publishing to a third party Bitcoin node) is what your code does - which is why I was a bit dumbfounded. Because i could do that myself, without jumping through all these hoops in generating ephemeral no ups, publishing it to Nostr, some other third party running a watcher (which would de facto be another queue aka mempool) and in the end just do an API call.
` .post(&format!("https://mempool.space/api/tx"))`
Hm, I would have create a fresh identity for every tx I publish as to not allow clustering - but yeah doable.
But why would I not simply publish my tx directly to a trusted API (mempool, blockstream, etc)?? That's exactly what your code does..
What exactly would it be "good for privacy" if I publish my bitcoin tx on Nostr - and tie it to my Nostr identity(!) - only so that someone else I can publish it to the mempool.space API??
I can do the same thing with `curl`, without posting my tx publicly on Nostr.
Keep at it Matt. You're a class act!
[Zapped from my own node running in my basement, connected through Tor - because This is the way ]
The standard would be: the coordinator is blinded, so it wouldn't know whom to block.
However - don't know if the blinding happens client side, or server (=coordinator) side. In the latter case, you are obviously at the mercy of Samourai running the actual same coordinator code as on their Gitlab.
Btw, This would be the same attack scenario I described about how Wasabi could use Chainal to deliberately certain into a less private rounds