2025 Q1 Report

GitHub Actions (CI/CD) over Nostr#

I Spent quite a bit of time on getting Nostr-based GitHub actions working. I have a basic runner implementation now, which i've reworked quite a bit when working with @dan on getting the front-end of it into gitworkshop.dev. We found that the nature of these jobs don't really lend itself to fit within the NIP-90 DVM spec.

What we have now:

• A dvm-cicd-runner that
  • Advertises itself using NIP-89 announcements.
  • Takes a DVM request with:
    • repository
    • branch/ref
    • path to workflow file (.yml)
    • job timeout (max duration)
    • 🥜 Cashu prepayment for the job timeout (to be refunded)
  • Pulls the repository and executes the provided workflow file
  • Sends logs in batches as partial job results
  • Publishes job results and gets displayed in gitworkshop
• Gitworkshop.dev (all ⁠DanConwayDev work) UI that :
  • Shows available workflow runners.
  • Instructing + paying runner to execute workflow file
  • Displaying job status, live updating with the latest logs / autoscroll, all the stuff you'd expect
  • Neatly displaying past jobs for the current repository

TODO'S + Ideas/vision#

• TODO: refunding the unused minutes (job timeout - processing time) to the requester
• TODO: create seperate kinds/nip for worflow execution over nostr
• Create separate kinds for streaming arbitrary text data over nostr (line by line logs)
• automated git watchers for projects to kick of jobs
• Separate out workflow management stuff from gitworkshop.dev. A micro-app might serve better to manage runners for git projects etc and takes away pressure from gitworkshop.dev to do it all.
• Perhaps support just running .yaml files, without the requirement to have it in a git repo. Could just be a .yaml file on blossom.

TollGate#

I spent most of my time working on TollGate. There's been a lot of back and forth to the drawing board to narrow down what the TollGate protocol looks like. I helped define some concepts on implementing a tollgate which we could use as language to discuss the different components that are part of a tollgate implementation. It helped us narrow down what was implementation and what is part of the protocol.

Current state of the project#

• We have a website displaying the project: TollGate.me
• Worked on a basic android app) for auto payments, validating we can auto-buy from tollgates by our phones
  • demo
• Presented TollGate at @Sats 'n Facts
• There's a protocol draft, presented at SEC-04
• We've done workshops, people were able to turn an OpenWRT router into a TollGate
• Building and releasing TollGate as a singular OpenWRT package, installable on any compatible architecture
• Building and releasing TollGate OS v0.0.1 (prebuilt OpenWRT image), targeting a few specific routers
• First tollgate deployed in the wild!! (At a restaurant in Funchal, Madeira)
• Other developers started to make their own adjacent implementations, which decentralizes the protocol already

What's next:#

• We're gathering useful real user feedback to be incorporated in OS v0.0.2 soon
• Refine the protocol further
• Showing TollGate at various conferences in Europe throughout the summer
• Keep building the community, it's growing fast

Epoxy (Nostr based Addressing)#

Although i've pivoted towards focusing on TollGate I worked out an implementation of my NIP-(1)37 proposal. During SEC-04 I worked out this browser plugin to demonstrate one way to make websites resistant to rugpulls.

It works by looking for a meta tag in the page's head:

<meta name="nostr-pubkey" relays="relay.site.com,other.relay.com">[hexPubkey]</meta>

When we've never recorded a pubkey for this domain, we save it. This pubkey now serves as the owner of the website. It looks for a kind 11111 event of that pubkey. It should list the current domain as one of it's domains. If not, it shows a warning.

The key concept is that if we visit this website again and one of these scenario's is true:

• There is no longer a meta tag
• There's another pubkey in the meta tag
• The pubkey is still on the webpage, but the 11111 no longer lists this domain

Then we consider this domain as RUGPULLED and the user gets an error, suggesting to navigate to other domain listed by this pubkey. I'd like it to perhaps auto-redirect to another domain listed by the owner, this is especially useful for frequently rugged domains.

This extension does try to solve a bootstrapping problem. We need to establish the website's pubkey at some point. We have to start somewhere, which is why the first load is considered as the 'real' one, since we have no way of knowing for sure.

Other#

🥜/⚡️ Receipt.Cash - Social Receipt sharing app#

During SEC I worked on scratching an itch that has been lingering in my mind since SEC-03 already. And now that vibecoding is a thing it wasn't this huge undertaking anymore to handle the front-end stuff (which i suck at).

The usage scenario is a bunch of bitcoiners that are at a restaurant, we get the bill and want to split it amongst each other. One person can pay the bill, then:

• Payer photographs receipt
• Payer adds Cashu Payment request
• Payer sets dev split %
• App turns the receipt + request into a (encrypted) nostr event
• The payer shares the event with QR or Share Menu

The friend scan the QR:

• Receipt is loaded and displayed
• Friend selects items they ordered
• Friend hits pay button (⚡️Lightning or 🥜Cashu) and pays
• Payment gets sent to Payer's cashu wallet
  • Dev split set by Payer goes to dev address.

Some features:

• Change LLM model that processes the receipt to extract data
• Proofs storage + recovery (if anything fails during processing)

Todo's:

• Letting payer configure LNURL for payouts
• Letting payer edit Receipt before sharing
• Fix: live updates on settled items

The repo: receipt-cash