-
This is my first attempt of regularly reviewing my week (currently, week 2) and I want to take you along for it. This week was one where I was rebooting after all the festivities, personal obligations and a bit of travel! First, I worked on getting back on some comments on my proposals on [NIP-42](https://github.com/nostr-protocol/nips/pull/1609) and the [Transport Method Announcement NIP](https://github.com/nostr-protocol/nips/pull/1585). ### NIP-42 proposal The responses to the proposal of the NIP-42 exstension confused me a bit, my interpretation of nip42 AUTH was both authentication and authoriziation. But as it turns out people only want authentication to be part of this NIP, which is understandable. I'm wondering what other structure should be used for authorization then. I thought this would be a great place because of the similar allow/disallow mechanism that applies to both authentication and authorization. I get the argument that authorization would need to be handled somewhere else. In my case i want authorization by payment. meaning there is no Authentication, we don't care who it is. I worked out this comment, to see what other options would come up. https://github.com/nostr-protocol/nips/pull/1609#issuecomment-2577243988 ### Evaluating current state Epoxy It's been a little bit since I made any progress on epoxy, but this week i'm picking it back up. So i'm trying to see what my next steps on it will be. I thought first maybe i need to add the random delays, but that's in the bigger scheme of things a 'nice to have'. I should probably first work on fixing the nightmare that is unencrypted traffic. And for that, i need pubkey addressing to work properly. ### Evaluating current state CI/CD This week i met up with Auggie, who's quite knowledgable into CI/CD stuff. I think a cool short-term goal for myself is to get an automated build and publish of the epoxy docker container. That shouldn't be too hard to attain, but I needed to refresh my memory on what I last worked on for a bit. I realized that that was a very hacky approach and i really want to know Auggie's perspective on it. I came across his comment on my [blogpost about it](https://habla.news/u/arjen@swissdash.site/chaining-dvms-for-nostr-cicd-pipelines) which i'd missed earlier. My doubt is wether i should try to rebuild what CI/CD is from scratch, but nostr-native. Or should I strive to have something backwards-compatible and use existing GitHub/Gitea runners? In our call we settled on trying to get the runner approach working and see how we go from there. I'd work out a GitHub action so we could upload artifacts to Blossom and he'd look into the inner workings of Gittea as he had worked on the stack before. ## Blossom uploads GitHub action I tried to move forward on the Blossom uploads on friday but got stuck on imports that would just not resolve on the github action (`ERR_PACKAGE_PATH_NOT_EXPORTED`). Long story short, I was just not bundling my build properly and (spoiler) worked this out on Monday. ## In short Quite an alright week, ramping up my efforts now and i'm exited for what's coming. See you next week!