We host Alexandria and our other projects on a private git server using OneDev.
Would other #nostrdevs be interested if we began providing a public git server as a (probably paid) service for others to host their projects?
Our goal is to break dependency on GitHub, and this would be a step in that direction.
Would other #nostrdevs be interested if we began providing a public git server as a (probably paid) service for others to host their projects?
Our goal is to break dependency on GitHub, and this would be a step in that direction.
Our team is hard at work on the latest round of user stories for project #alexandria.
What is a user story? We're glad you asked!
@npub1wqf…cqsyn explains in our first dev blog, which you can read on Alexandria!
What is a user story? We're glad you asked!
@npub1wqf…cqsyn explains in our first dev blog, which you can read on Alexandria!
I used to run one at happy tavern. I went back to GitHub when I rebuilt my server because my stuff was all there. I never spun it back up but you're right. We should try to all run our own. Or I can run one again for other people to use.
Hide replies
One advantage of the Git+Nostr integrations that people like @npub15qy…cyejr have been building is that it removes what was a single point of failure.
Today, if GitHub were to go down, everyone's work would grind to a halt. With Nostr, we can make it much easier to discover and manage repos across a network of smaller gitservers.
With that in mind, the more the merrier!
Today, if GitHub were to go down, everyone's work would grind to a halt. With Nostr, we can make it much easier to discover and manage repos across a network of smaller gitservers.
With that in mind, the more the merrier!
Depends on how much it would cost and what resource allocations would be provided to the average user.
Hide replies
We still need to explore costs further. Right now, we're just trying to gauge interest.
Baseline costs will largely be dictated by the costs of infrastructure. If, for example, we use a cloud provider, then we at least need to cover the hosting costs.
Additionally, different features will cost us more, and thus pricing to end users will vary. Code hosting, for instance, is far less expensive than running continuous integration jobs.
Baseline costs will largely be dictated by the costs of infrastructure. If, for example, we use a cloud provider, then we at least need to cover the hosting costs.
Additionally, different features will cost us more, and thus pricing to end users will vary. Code hosting, for instance, is far less expensive than running continuous integration jobs.
Can't calculate that, until we know approximately how many users it would be, as that would determine the server setup we'd select.
Hide replies
I have 1 project that will probably be in the 10-25gb range. Another that will probably be under 25 mb.
I may be interesed if the costs are affordable.
I may be interesed if the costs are affordable.
Hide replies
I think your first number is also MB, right? Alexandria is in the 4 MB range and our website is 16 MB. Njump is 33 MB.
Seems like circa 10-50 MB per repo, would be simplest to measure.
Seems like circa 10-50 MB per repo, would be simplest to measure.
I'd use it and happily pay, are you planning to host a gitworkshop (or equivalent) instance too?
Hide replies
I think our mentioning that we'd expect users to pay, is what left everyone underwhelmed. GitHub is "free", but we're not a Fortune 500 company.
Hide replies
That's why nostr needs decentralization. Kinda should have been working on P2P infrastructure before building more stuff on the broken infrastructure we already have, making it harder for your creation to be compatible with a P2P network.
But git on nostr is really important so good job anyway I guess
But git on nostr is really important so good job anyway I guess
Hide replies
I was thinking it'd be cool, if @npub15qy…cyejr could just add a "spin-up a repo" button to his page, and end with producing a repo event, with the GitCitadel repo listed in the event, or something like that.
That is the step where most devs start out, and they all head to GitHub for it. That's where we lose users: right at the beginning.
That is the step where most devs start out, and they all head to GitHub for it. That's where we lose users: right at the beginning.
Hide replies
Excellent point! We'll need to make the onboarding easy and fun, to retain users.
Hide replies
Hide replies
I was thinking that this could be something tied into the Awesome Nostr page.
Hide replies
i'm not sure i follow what should be tied into awesome nostr? you mean porting the repo to gitcitadel?
Hide replies
I was thinking we could have GitCitadel-repos/GitHub-repos statistics and listings. If we could map repos to commits to gitusers to npubs, then you could see who had worked on what where, for instance, and build a cross-gitserver contribution heat map.
Hide replies
Make a pull request and bug @npub1alj…hg9jp to merge it 😄
@npub15qy…cyejr has been talking about the need for a solution like this. There's a lot of potential in having nostr-based auth for git servers (that tracks the maintainers of a project and gives them push access)
It would be huge because now you have to manage permissions for each maintainer on all of your gconfigured git servers
It would be huge because now you have to manage permissions for each maintainer on all of your gconfigured git servers
Hide replies
Yeah, we agree with him, and we figured out a clean way to do it, without having to write a gitserver.
I support the idea, because Github is Microsoft, so yep (I am not a dev)
Hide replies
Well, it would also affect people who report bugs.
If you report it on some individual-dev's gitserver, it'll usually get ignored, as he is just going to look at GitHub. Also can't log in anywhere, with your Nostr signer.
If you report it on some individual-dev's gitserver, it'll usually get ignored, as he is just going to look at GitHub. Also can't log in anywhere, with your Nostr signer.
Hide replies
Or it's just extra work for bug reporters (which can be a good thing) compared to nostr issues. It's public and easy to submit, and not sequestered on the individual dev's server. Bug reporters don't need to make a bunch of email/password accounts to other dev's servers.
The best case, of course, is to make it easier for people to self-host code in some capacity, but many will want managed services. It's important to provide some competition to the big, established players.
I think this is an important thing to do, to aid the migration of Nostr repos to Nostr.
We could host a OS gitserver of our choice (like Gitea) in the cloud and build APIs to make it more Nostr-y, and then tie it into the GitStuff NIP-34 clients.
Some individual devs have their stuff hosted on their own webservers, but smaller projects are stuck on GitHub. Leaving them open to censorship. Codeberg and etc. are just differently bad. And spreading everything out hinders collaboration.
I don't think we'll ever get off GitHub unless we have someplace to escape to, and our name is @npub1s3h…975wz .
We could host a OS gitserver of our choice (like Gitea) in the cloud and build APIs to make it more Nostr-y, and then tie it into the GitStuff NIP-34 clients.
Some individual devs have their stuff hosted on their own webservers, but smaller projects are stuck on GitHub. Leaving them open to censorship. Codeberg and etc. are just differently bad. And spreading everything out hinders collaboration.
I don't think we'll ever get off GitHub unless we have someplace to escape to, and our name is @npub1s3h…975wz .
Hide replies
Have you looked at git.fiatjaf.com/song ? It seems an ideal fit for your usecase.
I briefly started a simpler project to put git-scm.com/docs/git-http-backend behind a reverse proxy and only let through push requests when the match the state in a nostr event but I've been distracted by other stuff.
I briefly started a simpler project to put git-scm.com/docs/git-http-backend behind a reverse proxy and only let through push requests when the match the state in a nostr event but I've been distracted by other stuff.
Hide replies
Yes, we have! We were just talking about it. @npub1qdj…3fqm7 has something similar in mind, I think.
Hide replies
Yeah that's effectively what I was thinking yes! It's a shame you're all crusty rusty @npub15qy…cyejr these days.
Song just popped back into my head today. We have to be careful with "self hosted" projects. Few developers put effort into the sysadmin side of things, which is the man power and most expensive part of running a business. It needs to be capable of easily scaling to handle multiple projects. I recall it was built for developers mostly. That, and our only Go developer is quite busy and has disgust for fiatjaf and his projects which makes this difficult for a company pet project. …
Song just popped back into my head today. We have to be careful with "self hosted" projects. Few developers put effort into the sysadmin side of things, which is the man power and most expensive part of running a business. It needs to be capable of easily scaling to handle multiple projects. I recall it was built for developers mostly. That, and our only Go developer is quite busy and has disgust for fiatjaf and his projects which makes this difficult for a company pet project. …
Our options are only as independent as our cloud provider(s)... Most cloud is supported by the same big tech. CDNs and other backend tools inside data-centers are often the same big tech subject to the same policies.
Hide replies
Hide replies
Hide replies
Could you guys give the five-year-old explanation on how I could get 📁 Repos on a #communikeys Blossom server or Relay?
It's not even clear to me what parts would go where: Server vs Relay.
The code file = blob on server ?
The PR = ????
It's not even clear to me what parts would go where: Server vs Relay.
The code file = blob on server ?
The PR = ????
Hide replies
The relay holds the repo announcement (that tells you which gitserver to interact with and which npub controls the repo), the issues/bug-reports, and the patches/code-change-requests, and the convos under the issues and patches.
You can use blossom to track git blobs, but it's a bit redundant. Mostly necessary, if your commits are really big.
You can use blossom to track git blobs, but it's a bit redundant. Mostly necessary, if your commits are really big.
Hide replies
Yeah code is on the gitserver, PRs are on the relays.
We can already do code collaboration via Nostr using ngit, but ngit still requires you to use a git server, and most people use GitHub.
Hide replies
Something to consider is we only need the git part... Onedev GitLab and whatever else you can think of are WAY too much.
Maybe we shouldn't even bother considering those extra features since we prioritize and encourage the use of nostr. We can do this literally with HTTP servers. Sure I can get more complicated but lets keep in mind what we need for a simple git remote server to work
Maybe we shouldn't even bother considering those extra features since we prioritize and encourage the use of nostr. We can do this literally with HTTP servers. Sure I can get more complicated but lets keep in mind what we need for a simple git remote server to work
Hide replies
Good point. Ngit can already handle a good deal of the collaboration, and our team will build more collaboration tools as we work more on git stuff. We just need a place to stash code that's not GitHub and that doesn't require reinventing git in the form of Nostr events.
Hide replies
Hide replies
You can list multiple gitservers there, but most repo events just have GitHub listed. We want to offer a second "low-friction" gitserver.
Hide replies
Thanks for reminding me. I should prolly work on that a bit tonight when I get home...
I need to figure out how to include propose edits like amethyst, and maybe some kind of community voting system to approve edits. 🤔
I need to figure out how to include propose edits like amethyst, and maybe some kind of community voting system to approve edits. 🤔
If we start hosting a public git server, we'll use it as a platform to start developing and testing new Nostr/git integrations.
