Gitoxide aims to "become the foundation for a free distributed alternative to GitHub, and maybe even GitHub itself"

[happybeing]

I have a similar project and must have missed the above gitoxide aim when I visited in October or would have contacted you then. I'm interested in collaboration or to see if your project is close enough to my goal that I could contribute and use it as is, or adapt some part etc.

I happened here today looking again for Rust projects to help with my p2p Git Portal project (see below). The Git Portal proof-of-concept uses git-bug to add issues and comments seamlessly to any git repository. I'm no git expert but believe the approach is sound and it performs well. git-bug can already import issues from github and can push/pull its own data to git services as a git extra CLI (git bug), all without messing with your project's own git data. The only problem I've found with git-bug is that it is written in Go. It was great for a quick proof-of-concept but is much less suitable for building a product for various reasons, so I'm again looking for options using Rust which is how I arrived here today.

So I'm wondering:

• what you know about/think of the approach used by git-bug (if anything)
• whether gitoxide is pretty much what my Git Portal is intended to be (i.e. web app hosted on p2p static storage, or a core part of that)
• whether gitoxide or some parts of it can be adapted for my use case (e.g. to add issue support to a Rust/Wasm web app)
• if so I'd love to contribute or collaborate, although I'm not keen on your MIT/Apache licensing for a decentralised project (I use GPLv3)

p2p Git Portal

Git Portal is a proof-of-concept Svelte + Go/Web Assembly app which can create and view git based issues alongside core git functionality such as browsing the worktree and listing commits. So functionally similar to github but in a test harness UI (someone is working with me on a more github like experience).

The Git Portal demo/poc is live here. First load can be slow because of the 12MB Go runtime, so be patient (instructions in the README). What you see there is a test harness which proves the concept. From that we'll improve the poc to a reasonable demo, but longer term I don't think it makes sense to continue with Go, and Rust is my first choice.

It is written in Go because I chose to build the poc using git-bug for issue support (and go-git for git functionality). It is compiled to Web Assembly and so runs in a browser from static storage without server side code. My aim is to run it from peer-to-peer storage on https://SafeNetwork.tech although it would be possible to use it as the basis of a decentralised app from any static or p2p storage.

Thanks for reading, I'll be interested to hear back although I realise code may be a higher priority and in the mean time I'll spend some time getting to know gitoxide.

[Byron]

Thanks so much for getting in touch!

…although I realise code may be a higher priority…

First of all, I think the opposite is the case. Attempting to help folks to get started using or contributing to gitoxide is my priority right now and will always be no matter how much time I can afford for coding. Right now, this isn't very much unfortunately.

That said, let's get to the questions.

what you know about/think of the approach used by git-bug (if anything)

I didn't know about it, and after having had a cursory look at the model I believe it's a great way of adding any meta data to a git repository transparently. Of course I don't know if it's sound, but it's certainly a starting point.

whether gitoxide is pretty much what my Git Portal is intended to be (i.e. web app hosted on p2p static storage, or a core part of that)

No, definitely not, but it can be used to make such an application.

whether gitoxide or some parts of it can be adapted for my use case (e.g. to add issue support to a Rust/Wasm web app)

gitoxide offers low level crates to interact with git repositories in a way that allows perfect control over anything that happens. However, right now it's not geared towards WASM and wouldn't compile in that target. Luckily I believe this isn't anything too hard to fix, one could add special file system support in git-features which implements the respective functionality depending on whether it compiles for WASM or not. Furthermore compile-time flags could be used in any other special case that can't be covered by abstractions in git-features for some reason.

The contributors from #32 and #31 also target WASM, and that collaboration is certainly going to help getting it there.

if so I'd love to contribute or collaborate, although I'm not keen on your MIT/Apache licensing for a decentralised project (I use GPLv3)

I would be happy to support you in your collaboration efforts and coordinate the parties already involved. If you like we can have a video call to get your started once you have found your bearings taking a look at what's here for yourself.

Naively I would believe it's possible to keep the application you are building in whichever license you like and use gitoxide. Indeed, contributions would be under these licenses I presume. If you have ideas on how to resolve this issue without changing the license of gitoxide, I am definitely listening.

That's all for now, please let me know what you think.

[happybeing]

Thanks for getting back to me so swiftly @Byron and for your time here. I share your sentiments about priorities but not everyone has the bandwidth, and without code its hard to build community! I surprise myself how much time I spend sharing what I'm doing on mastodon, twitter, several forums and chat channels, but I do enjoy that part too.

Anyway, what you say is very encouraging. On licensing it's less of an issue using MIT/Apache code as a library than contributing under that license. I'm loath to publish/contribute code that way because I'm concerned it creates a disadvantage for business which would take the fully open route, and I do think business and particularly corporations (the way they are legally constrained to prioritise profit) is a problem. So generally I push against that.

Leaving that aside for now, you've hit the nail on the head in terms of what I'd need: a filesystem interface. Having go-git/go-billy for git features, and some fairly minor tweaks to do the same in git-bug is what has made it possible to create a working demo in under two months. If only they were Rust libs!

So the feasibility of doing this within gitoxide interests me, and of course what others are doing with wasm so I have some things to investigate - thanks! I was a bit downhearted after emailing you having got a sense of the size of the task. I really don't want to stick with Go, but it will require far less code to be written. I was totally new to Go and Wasm in mid October when I started to look at doing this and it proved far easier than I anticipated.

My impression is that Rust is better supported but I've not built anything yet.

I'll fork and take a look at the gitoxide code now, and investigate those other contributions and maybe start experimenting with Rust/Wasm and the relevant part of gitoxide to get a better idea of what I'd need. I'm not that familiar with the low level of git, so there's much to learn and much to do.

BTW are you still in China - I saw that on one of the issues you linked? If so I hope you're having a good time out there. I'll update you and no doubt be back with questions. Thanks again. Actually one question I have is whether there's something driving you to want to make gitoxide? My motivation is to support privacy, security and freedom through real decentralisation, not least on Safe Network. I'd be interested to hear what is important to you in relation to gitoxide.

[Byron]

So the feasibility of doing this within gitoxide interests me, and of course what others are doing with wasm so I have some things to investigate - thanks!

I also recommend having a look at tasks.md for the work needed to implement a complete clone. With that in place, one can handle a local working tree as well as commit graph iteration. Lastly, the work on WASM support hasn't started yet.

My impression is that Rust is better supported but I've not built anything yet.

I am happy to help. Having made my own experiences with Go before I came to Rust prior v1.0, I must admit that Rust has more to lean but has a much greater pay off, too. Certainly it's on you to decide on what to prioritize, going with Rust would certainly set back your project by quite a bit.

I'm not that familiar with the low level of git, so there's much to learn and much to do.

Depending on what you want to implement, I am happy to help with these aspects too and share my experience.

BTW are you still in China - I saw that on one of the issues you linked? If so I hope you're having a good time out there.

Yes, and yes :).

Actually one question I have is whether there's something driving you to want to make gitoxide?

The details are probably best summed up in the respective section of the README, but the short version is that I always wanted to make git more hackable by lifting it from C. Now with Rust the time is finally right, adding the ability to improve on everything, with safety, performance and usability being the first points that come to mind.
With a foundation like that, I believe everything can be built and if you would succeed in using it or radicle.xyz, that would be awesome!