Looks like we bought the https://gitrepublic.dev domain, for the server. 👀 Should see something appearing there #thoon.
nostr:npub1qdjn8j4gwgmkj3k5un775nq6q3q7mguv5tvajstmkdsqdja2havq03fqm7 nostr:npub1wqfzz2p880wq0tumuae9lfwyhs8uz35xd0kr34zrvrwyh3kvrzuskcqsyn and nostr:npub1gnwpctdec0aa00hfy4lvadftu08ccs9677mr73h9ddv2zvw8fu9smmerrq 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.
https://github.com/nostr-protocol/nips/blob/master/98.md
That's why I also implemented NIP-98 on Sybil.
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.
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 nostr:npub1qdjn8j4gwgmkj3k5un775nq6q3q7mguv5tvajstmkdsqdja2havq03fqm7 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.
We need to have a way to filter the announcements to return public repos only. Shame we don't have negative filters.
Could add a repo-visibility tag to the announcement.
NIP-70 tag...
That's what they use for groups, too, right?
yes, also lockbox https://lockbox.fiatjaf.com/ (used for kind 1)
100% and it allows the git server itself to be very dumb and let nostr do the work!
> 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?
