All github does is provide convenience. If you want to use github in a peer-to-peer fashion all the tools are already there.
This is because Pagure stores not just code but also all the project metadata (issues, PRs, Wiki pages, etc.).¨
In comparison most other git forges, including the big ones (GitHub/GitLab) store all project metadata in a central database, so if you want to move or even backup/restore a project you need to do a complicated export/import process.
In comparison on Pagure you can just clone the repo and get all the project data with it. Then just put it on another Pagure instance - done.
Should not be hard to adapt this system to be backed by a distributed system from below.
Proper p2p would be like joining a DHT swarm with a hash and downloading pieces from other peers.
Mercurial had a single command for this, "hg serve", that would just pop up a webserver for sharing. It was extremely useful for me during university, and I've often considered it a key failing that git does not provide a similar command out of the box. As a result, the distributed nature of git is hidden from a lot of people.
For the record, the command to make git do what mercurial does with hg serve is "git daemon --reuseaddr --base-path=. --export-all --verbose --enable=receive-pack".
Obviously this is insecure and anyone who can establish a connection can push and pull from your repo, but if you're just jamming with some friends you don't need github.
You don't even have to "host a server". Simply allowing ssh access to your machine is enough.
The vast majority of Linux developers don't have their own publicly-accessible repository that you can pull from - they push patches to the mailing list.
Various archives can host copies of the mailing lists (you can ask https://www.mail-archive.com to do so for you), and the git repository can obviously be mirrored anywhere anyone who can clone it likes. Congratulations, you now have a globally mirrored, decentralised development process where the canonical repo and any patches submitted never disappear.
But instead having many small hand-maintained servers, the admin of each is responsible for what's hosted on it, and of which there is no registry, doesn't sound much better. Very likely there would be a handful of effective central nodes in that network, but if you take down a couple of them, you end up with a situation where already-involved devs might still be able to navigate the landscape, but for a newcomer it might be really hard to find one of those nodes, or be sure it's one with the "right" revisions.