-
@ Arjen
2025-02-04 03:58:50
**This past week got me a lot of frustration with the GitHub actions runner and debugging it. Really testing my patience, but at least i saw a bit of progress. TollGate's had a nice wrap-up for the Proof Of Concept app, which some great new ideas on how to make the user experience even better! Let's dive in!**
## GitHub Actions
I've been having a low-key fight with the github actions runner containers. I have spent a lot of time trying to figure out WHY the blossom upload action would just not work. I was quick to find out that the action is being ran with an older version of NodeJS (v18) while the blossom uploader requires v20. Not a big deal you'd say as i just set the version to 20 in the pipeline. However, doing that explicitly had zero impact, and after diving down the github runner rabbit hole i concluded that the Actions that are imported (from marketplace) will just run with whatever node version is already installed in the runner's docker image. Which in the case of the act runner is Node 18. I tried updating to the latest images but I haven't been able to find a compatible one yet...
### Payments
I've been working on getting the money aspect working in the ci-cd runner. I added a wallet and a scheduled payout. I took this from the nostr-epoxy project and did some updates to upgrade to cashu-ts v2.
I added some advertisement info like the specs of the machine that the runner is on. I've been pondering how the payment flow should work though.
See the problem is that because of the nature of this DVM, it cannot predict how long a job will take to execute, a customer can literally do anything in their pipeline that will make a job last forever. I think for that reason there has to be some kind of deposit/credit or stream besides the one-off payment. I made a post asking what the best way would be: nostr:note17apw8unznvwx2k3z48t7qz6cq26tk077w83qh3f7zxukfrrfukhs7mpcsn
I currently feel best about the option of just sending a bunch of ecash that will sure be enough to execute the job (and otherwise act as the time-out) and that if the DVM uses less of that money, it will send it back as pubkey locked cashu tokens, to a given npub. Maybe NIP-60 can be a great way to handle returning the 'change' to the user.
Some ideas i have now:
- Billing should be per second
- Advertising should:
- advertise as sats/minute
- include specs of the machine, ideally searchable by tag
### Job request
So the flow i'm thinking of is:
- User posts request
- repository
- branch
- yaml path
- bid (max price per minute)
- min_vcpu
- min_ram
- min_storage
- DVM responds with
- price per minute
- vcpu
- ram
- storage
- runner-types
- price per minute
- User posts request:
- ... [same as above]
- cashu payment
- cashu return pubkey + relay
### User Interface
I also worked on building out a very basic user interface to run the GitHub Actions dvm.
The UI then shows all feedback to the job, where the first feedback event you can see gives back a status processing, and the next one gives back the console output of the pipeline run.
nostr:npub15qydau2hjma6ngxkl2cyar74wzyjshvl65za5k5rl69264ar2exs5cyejr and I agreed he'll copy over this basic setup into his upcoming version of gitWorkshop.dev which I can then build upon so we can experiment with the User Experience (how to handle competing Runners, display results, payments, etc...)
## Tollgate
There's also been the issue that has been bothering me since last week: Being able to dismiss a captive portal programatically in the Android app.
During a weekly check-in that nostr:npub1k03rader0vm94j5ee8fg7pc2x9xkr2phu77sljas7qu5mh8mvgvqpe8rty and I set up we discussed the issue. To me, it's a problem having the user to jump through all these hoops to connect, which should be as much automated as possible.
We discussed what if we'd ditch the open network and go with a WPA2 (password) protected one and have no captive portal. But then we lose the ability to do onboarding / expose users to Tollgate through the captive portal. Then the idea came up to create an extra (hidden) network for the app to use, while keeping the open one with the captive portal. I did not know it was possible to create multiple networks on the same (physical) radio, but apparently it's quite common. You lose a bit on efficiency but it shouldn't be too bad. The only challenge would be to exempt this network from getting a captive portal while still using the OpenNDS software to manage user's sessions. We'll see but this gives me a lot of hope for a seamless user experience!
After this call, despite our possible new direction I did want to try and get the full app flow working, to validate if it's possible at all. And after some digging int the Tauri docs and even their discord community i finally found what the issue was with me not receiving the android event for the captive portal. I'd ben adding the listener for this event to the `androidmanifest.xml` file for the Tauri Android plugin, while I had to put it into the tauri app one's itself -one level higher- if you will...
Anyway, that worked and I was FINALLY able to create the following full flow! (video)
nostr:nevent1qvzqqqqqqypzpwa4mkswz4t8j70s2s6q00wzqv7k7zamxrmj2y4fs88aktcfuf68qy88wumn8ghj7mn0wvhxcmmv9uq3zamnwvaz7tmwdaehgu3wwa5kuef0qydhwumn8ghj7un9d3shjtnwdaehgunsd3jkyuewvdhk6tcqyqyvs2js3x6ldpm2kkmqyf8d3lvrcezjk2eg26p2tvfxd2p6lkeqzn7l66t