#gitpub — Public Fediverse posts

One Open-source Project Daily

The GitHub app for minimalists.

https://github.com/awmleer/gitmug

#1ospd #opensource #angular #github #githubapp #githubclient #gitpub #ionic #typescript

One Open-source Project Daily

The GitHub app for minimalists.

https://github.com/awmleer/gitmug

#1ospd #opensource #angular #github #githubapp #githubclient #gitpub #ionic #typescript

One Open-source Project Daily

The GitHub app for minimalists.

https://github.com/awmleer/gitmug

#1ospd #opensource #angular #github #githubapp #githubclient #gitpub #ionic #typescript

One Open-source Project Daily

The GitHub app for minimalists.

https://github.com/awmleer/gitmug

#1ospd #opensource #angular #github #githubapp #githubclient #gitpub #ionic #typescript

One Open-source Project Daily

The GitHub app for minimalists.

https://github.com/awmleer/gitmug

#1ospd #opensource #angular #github #githubapp #githubclient #gitpub #ionic #typescript

@sir by that time, the #GitPub folks could have spent a lot of energy going down what you claim is the wrong path. You hesitate now to put this claim in writing in one place, so it can potentially guide their work down the right path. Could it be that you are almost ready to concede the possibility that you were drawing on funds that weren't really in the bank?

@sir . FWIW despite what the name suggests, #GitPub plan to support any and all version control systems, not just #Git (even raw patches)

@sir #GitTorrent is one attempt to solve the decentralized GH problem, your #sr.ht is another, #GitPub is another, #Git-SSB is another (https://github.com/noffle/git-ssb-intro). Each one tries using a different standardized of protocols (#BitTorrent, email, #ActivityPub, #SSB). Ideally it would be possible to bridge them all, so users and projects could hosted anywhere, and users could contribute anywhere

@sir @Wolf480pl @Michcioperz
This is precisely because of the problem #GitPub is trying to solve. Where should it be hosted? On GitLab.com? On a GL instance? Which one? Once GitPub (or something like it) exists, it won't matter, because anyone will be able to interact with it as if its on their own home instance (self-hosted, community-hosted, whatever).

@sir @Wolf480pl @Michcioperz one more thing, I would be very interested to see you expand on this in long form, in fact on anything we've discussed today, so I can share a link with the #GitPub folks

@sir @Wolf480pl @bob @Michcioperz this is all totally fair enough. You're scratching your own itch. You're making tools for users like you. Users who are not like you also need tools, and they need to be more like GH / GL. That's why people are working on #GitPub. If you can propose a protocol set to them that is simpler than the AP set, by all means, go for it! They'll love you for it and so will I.

@sir @Wolf480pl @Michcioperz right, they're in #GitPub's target audience, which is why it is needed, despite the fact that you and other CLI-based software engineers don't need it. Yes?

@sir @Wolf480pl @Michcioperz @Karneolius
> most people who use git are engineers

I don't think this is true, for a number of reasons. The main one being that engineers are only one of the specialists involved in post-CLI software dev, especially for net software. Other specialities include graphics, #UI, and #UX designers, doc writers, beta testers.

> I do not feel the need to make tools which are accessible to noobs.

I'm not saying you must, but that's the use case GH and #GitPub are for

@sir @Wolf480pl @Michcioperz @Karneolius
> If any change would be good, it would be to move things like tickets into git objects.

OK, my understanding is that #GitLab does this. It doesn't seem to help users, projects, or organizations on multiple instances of #GitLab etc interact, creating a federate replacement for GH. If you have a better way to solve this problem that would work for doc writers who will never touch a command line, I'm all ears, and I imagine the #GitPub folks would be too

@Wolf480pl @Michcioperz @Karneolius @sir fair point. Maybe something to talk to the #GitPub folks about? Would the lists.sr.ht tech allow existing instances of #GitLab etc to federate though?

@Michcioperz @Karneolius @Wolf480pl #GitPub is about federating together instances of #GitLab, #Gogs, #Gitea etc, to create a similar #UX to GH (everything is connected, low barrier to drive-by contributions), without forcing everyone to develop free code on a proprietary platform now owned by one of software freedom's oldest enemies
http://www.ecis.eu/documents/Finalversion_Consumerchoicepaper.pdf

@Michcioperz @Karneolius @Wolf480pl sure but #ActivityPub != Mastodon or just microblogging. It's also #Hubzilla (blogging), #PixelFed (photos), #PeerTube (videos), and hopefully soon #GitPub (code). Why not forums?

@alexl What I know about federation protocols would fit on the back of my hand, but ... #GitPub is a pretty specific and uncommon use case, it's not suprising it needs a few extension to standard #ActivityPub vocab. But surely micro-posts don't need an AP extension, they are the core functionality of the whole standard! Also, why can't comments use the same data type as micro-posts?

#Framasoft have a mailing list for spec work on #federation of #Git hosting stes (see also #GitPub)
https://framalistes.org/sympa/arc/git-federation/2018-06/

By all means, #movingtogitlab-dot-com does not solve the problem GitHub has (centralization), and moving to a privately hosted GitLab re-introduces the problem GitHub mostly solved (separation).

#GitPub is trying to solve this problem by defining a federation protocol for git services: https://github.com/git-federation/gitpub