Hey, would you be up for doing a workshop in London? For details speak to @CYPHERMUNK HOUSE | LONDON @psy𝑓er

Looks like we bought the https://gitrepublic.dev domain, for the server. 👀 Should see something appearing there #thoon. @ChipTuner @MichaelJ and @Enki are working on the system design PR. And I added the ngit events to #Sybil, so that we can eventually add more and I can use my utility to generate test events. The #GitRepublic git server is happening, folks.

If it's not clear from the screenshot, it's an HTTP-based git server that uses both the normal git password login and NIP-98 authorized logins over HTTP.

GitHub

nips/98.md at master · nostr-protocol/nips

Nostr Implementation Possibilities. Contribute to nostr-protocol/nips development by creating an account on GitHub.

That's why I also implemented NIP-98 on Sybil.

Probably you can do with blossom (idk)

GitHub

GitHub - sandwichfarm/nsyte: deploy, manage and inspect nsites

deploy, manage and inspect nsites. Contribute to sandwichfarm/nsyte development by creating an account on GitHub.

Yes!

Interesting. Are you planning to use NIP-34 state event to authorise pushes? I've not thought to much about restricting read access as I've focused on FOSS repositories. NIP-98 over HTTP seems interesting.

@Lez did some work on this:

GitWorkshop.dev

Decentralized github alternative over Nostr

I also wrote an incomplete PR to ngit to put git packs on blossom to maximise efficiency. Ultimately we both concluded that using a git server is better. Its super efficient, battle tested, has lots of advanced features that people use (LFS, shallow cloning, etc) and allows backwards compatable integration (eg. with CI /CD).

GitWorkshop.dev

Decentralized github alternative over Nostr

Even many FOSS repos started out private and go public when the MVP starts really taking shape, or with the first released version. It can just be a draft. It's a containerized, multitenant server that scales horizontally, but I'm not deep enough into the backend to tell you how it all works. I think the MVP is going to be manual administration of lists and later versions will be using the AUTH relay to send/receive events to automanage the repos and the git service. But @ChipTuner it makes sense to "register" a tenant with a repo announcement on the wss://gitcitadel.nostr1.com relay and get the repo maintainers from that announcement. Announcements from npubs who have left the relay subscription could be deleted, which would pause their access to the git server, until they resubscribed and rebroadcast the repo event to the relay. Or something like that. Later GitRepublic versions could auto-update based upon the events, but first we need to get all of the various machines and services setup. That's actually the hard part.

The Git+Nostr combination means that you could have different visibility for the repo and the social interactions surrounding the repo. You can have a repo announcement for a git repo nobody can access, for example.

And vice versa.

that was the first version, this is the third version, florian did the second one and probably you can do "enable CI /CD via a DVM style marketplace" and use blossom

Can you explain what you mean a bit more?

We need to have a way to filter the announcements to return public repos only. Shame we don't have negative filters.

Lfg !

Could add a repo-visibility tag to the announcement.

according to what chatgpt says "🧠 Interpretation This is not a full CI/CD, but can work well for: Static websites Single-page apps Simple deployments nsyte acts like the deploy agent The nbunksec token is your secure auth key (like an API token)"

NIP-70 tag...

That's what they use for groups, too, right?

yes, also lockbox https://lockbox.fiatjaf.com/ (used for kind 1)

> But @ChipTuner it makes sense to "register" a tenant with a repo announcement on the wss://gitcitadel.nostr1.com relay and get the repo maintainers from that announcement. Announcements from npubs who have left the relay subscription could be deleted, which would pause their access to the git server, until they resubscribed and rebroadcast the repo event to the relay. Or something like that. Agreed, that was kind of my thoughts we talked about on the pr exactly! As long as we can control/monitor those subscriptions?

100% and it allows the git server itself to be very dumb and let nostr do the work!

For a non-dev who wants to try this out for non-tech product management, where do I start?