@movq@www.uninformativ.de Ahh, no you can. Much like what we’ve built here with Twtxt / Yarn. I’m building a spec, clients can implement the spec, or you can ya know, just curl and git your way through. I’ll link the spec soon™, just need to keep refining and testing and make sure this actually works properly 😅

@prologic@twtxt.net Ah, so I can’t send you a patch / PR unless I host gitxt myself?

gitxt is a purely decentralised git forge. There is no federation protocol, no instance-to-instance API, no accounts on other people’s servers. Each forge instance is fully independent; collaboration is an act of publishing and reading plain text files over HTTP

@fossham@twtpub.com I honestly think the most unique and interesting thing about doing this at all is that it is in fact inspired directly by Twtxt / Yarn.social itself – That is to say, I am confident I can do this in such a way as to be “truly decentralised”, no inter-networking like ActivityPub, no centraised forges like Github or Codeberg. You run your instance, I run mine, we just are able to collaborate. Think exchanging patches over Email, just without all the hard-to-learn ways to do that (enough though it’s not hard for some of us, but still).

@movq@www.uninformativ.de So the way this works in my design/prototype is this. You fork my repo in the app, it clones it to your own forge, follows my instance and it’s repo for updates and ping my instance to indicate “you’ve forked me”. Then when you publish changes, I can see them by pulling your instance’s feed. It all works on the same plain text principles of Tstxt itself. The feeds are “pull”-based with push-based “pings” on things like “someone forked your repo”, “a new issue has been raised against your repo”, etc.