Ideas

[staltz]

Hey @noffle since you're moving fast I want to bring this discussion to your attention: %HPMQEUbULKcJJMEAP/iMnVfuykNZ9llEymArjkuEO/A=.sha256

And specially this idea: %+8m/lsrYwlQ3YeR/+v8+Cb9d/MfZPECtwTyqU+wUvq8=.sha256

Cross-forks project view

• Owned by no one (it's noderify not dominictarr/noderify)
• Owner-less place contains the issues and PRs
• Shows you currently known graph of forks

a public discussion forum, owned-by-none yet owned-by-all, people will figure out what needs to be done and by whom. I believe they'll self-organize into some structure that makes sense for them. The fact that GH makes cross-fork collaboration hard (at least because there isn't cross-fork discussion forum) tends to centralize discussions in one fork. If all forks are displayed equally, and if it's easy to navigate and utilize/install other forks, I think we would gain a lot more flexibility.

---

Fork view

• Owned by dominictarr
• Has no issues / PRs
• Shows the files, commits, readme

the "fork view" requires nothing else than rendering data from a git repo. It doesn't have any added metadata whatsoever. It's literally a read-only rendering of the git repo. That's actually quite useful! It means the cross-fork project view is the only git-less thing to build.

[hackergrrl]

This is a really cool idea @staltz! I'm thinking about it & imagining cases and here is my stream of thoughts, pull(thoughts()):

excited

• I really like how this could encourage collaboration, by making the issues/PR space a commons
• the value is in the collective view of all forks, not in some particular person's blessed core. I dig this so much! :heart:
• folks might tend, in this case, to move toward convergence instead of divergence, since the issues/PR (collaboration space) is shared and open
• damn I really want to implement this just to see how it plays out as a social experiment!
• I like that this would let people create forks but be able to borrow the ears & attention of the whole group by default

uncertain

• depending on how far the forks have diverged, I wonder if conversations on the cross-fork view will get increasingly difficult, since the amount of shared context will decease
• however, maybe this will encourage folks to stay relatively converged?
• could this also get confusing, if I were to fork react-native and want to quietly work on it /w some friends, but not fill the cross-fork view with noise?

[billiegoose]

Totally with you guys on this! In my vision of the future, the "commons" view would show all the current branches around the world, and people could indicate their approval / disapproval of branches by leaving cryptographic signed "thumbs up / thumbs down" messages in the repository. (Possibly GPG signed annotated tags, but potentially a completely different mechanism like sodium-signatures.) The "commons" view would highlight branches made by people in your circle of trust, and those that have lots of upvotes, or lots of activity, etc there are different criteria that could be used.

I think "fork" has a negative connotation, associated with a "hard fork". Github has a stupid policy of requiring you to create a hard fork of a repository in order to create a PR if you are not already a "contributor". In my vision, such user-created forks would simply be "branches". E.g. everyone can read/write whatever git objects they want the global repository, and the only action that requires authority is moving branch pointers.

Edit: which brings me to an interesting thought... Currently git has no concept of a signed branch. Could probably work around it by making the branch point to an annotated tag, which can be signed, or point to signed commits.

[billiegoose]

could this also get confusing, if I were to fork react-native and want to quietly work on it /w some friends, but not fill the cross-fork view with noise?

extend the idea of "signed branches" to "private branches". Allow branches to control their own P2P seeding policy. Then members of the cabal would see a "common view" that includes mainstream and their quiet fork, while those not in the know about this secret branch would only see the mainstream work.

You could also have optional levels of noisiness with branch "attributes". E.g. have a branch attribute like "WIP" that enables others to filter "WIP" branches out of their view. And individual users could apply user-level attributes like "mute" to control which branches are in their view.

[billiegoose]

@staltz instead of calling it "Fork view" you could call it "Branch view". Then instead of a "Branches" dropdown you could have a "branches by this author" dropdown.

Edit: Or not have a branches dropdown at all.

[happybeing]

I'm quite likely missing things being relatively inexperienced, but a couple of things occur:

• we like ownership (followers, likes, being in control all motivate individuals, or is it just me 😄), so maybe some will lose interest and motivation without that.

• how does something become a separate project? Things diverge. Isn't a fork as often about "hey, that's cool, I can make it do this new thing" as often as it is about "I want to hello develop this existing thing"? I guess that's easy to cater for, so I'm probably just showing my lack of understanding here, but I'm OK with that.

I'm interested to learn, and to understand the way you guys are thinking here.

PS for @noffle and @staltz I am aka @safepress, [waves]

[hackergrrl]

Great Qs @theWebalyst!

Another open Q: can a commons that's shared by the entire internet even work? I've seen it work beautifully in contained environments (like secure-scuttlebutt), but I wonder how this would look with such an open participation model and so many potential people. I wonder if something like what SSB is facing (a desire to block/hide other people & groups due to noise) would happen here.

[billiegoose]

I hope this doesn't seem completely irrelevant - but I'm reading this right now

https://arstechnica.com/gadgets/2018/06/talkin-treble-how-android-engineers-are-winning-the-war-on-fragmentation/

and I'm finding it fascinating how Google changed it's development process so that silicon manufactures could directly contribute the AOSP repo to reduce time to market. I'd describe previous Android development as a waterfall release cycle with silos; I'm not sure what I'd call the new process (god I can't even fathom what it must be like to have 6000 Qualcomm engineers working on Android) but definitely a powerful case study for the benefits of everyone working together. I think we have a real shot and breaking the mold of siloed development that GitHub has created, and creating the first truly community centered source code development platform, where we can encourage this kind of teamwork as the norm.

[billiegoose]

we like ownership (followers, likes, being in control all motivate individuals, or is it just me 😄)

@theWebalyst I think you might have to reevaluate the universality of that. I'm sure it's not just you, but that's definitely NOT me. I wouldn't describe myself as a communist techno-hippie, but I am definitely friends with people who fit that description. I'm motivated by the end results and by the pure joy of solving problems. To me, software project ownership seems like a problem that just creates friction and slow down a project. The existence of http://openopensource.org/ and https://probot.github.io/apps/invite-contributors/ are both examples of what I'd call attempts to solve the technical burden of "ownership"... which is definitely a consequence of GitHub's design that such elaborate measures as a bot are needed to auto-add collaborators.

[Gozala]

I really like idea of encouraging convergence :+1:

I do fear that shared issues/pr is little utopian. It is important to allow different groups to have relative independence so they could choose level of coordination and allow groups to set their own participation rules. Proposal here assumes everyone will get along, which in practice does not seem to happen all that often, in fact I’d argue that hard forks happen not because github makes it difficult to converge but beacuse people / objective differences

Not to discourage though, I think there’s definitely a room to make convergence more desired outcome.

[billiegoose]

in fact I’d argue that hard forks happen not because github makes it difficult to converge but beacuse people / objective differences

Github really confused the meaning of "fork". They turned "cloning a project into your own user-space" into "forking", which was not what the term historically meant. You are correct that hard forks of projects happen because of people / objective differences.

But I have 46 "forks" of projects that exist simply because I wanted to make a pull request. Github's technical limitation made it such that in order to separate "my" repos from "ones I forked because of Github's technical limitations" I actually made a separate Github identity here https://github.com/wmhilton-contrib

[billiegoose]

Proposal here assumes everyone will get along

I mean... it would still be possible to do a hard fork, right? Just start a new repo, then copy and paste all the files. Do we want to make it easier than that? Do we want some kind of association or link to connect the repos if the two groups are at the point where they literally can't stand the sight of each other's Issues and PRs?

[Gozala]

I mean... it would still be possible to do a hard fork, right? Just start a new repo, then copy and paste all the files. Do we want to make it easier than that?

It suppose could be good enough

Do we want some kind of association or link to connect the repos if the two groups are at the point where they literally can't stand the sight of each other's Issues and PRs?

I think there are ton of legit scenarios where group might desire relative independence from canonical repo and limit their coordination.

[Gozala]

Github really confused the meaning of "fork". They turned "cloning a project into your own user-space" into "forking", which was not what the term historically meant. You are correct that hard forks of projects happen because of people / objective differences.

I think you’re making a good point here. I agree that githubs default of making fork (terminology aside) be full blown thing with own issues and wiki etc encourages independence rathet than collaboration. I think changing this deafult would could make significant difference. That being said I think non default option to do so though would still make a lot of sense.

But I have 46 "forks" of projects that exist simply because I wanted to make a pull request. Github's technical limitation made it such that in order to separate "my" repos from "ones I forked because of Github's technical limitations" I actually made a separate Github identity here https://github.com/wmhilton-contrib

[billiegoose]

Maybe this is off topic, but I wanted to mention it just as a technical footing: the entire world does not - theoretically - need more than one git repo.

If you do the research, the likelihood of a git hash collision is so rare that you could fit all the world's git objects into a single address space. The 160-bit object id (which is the hash of the object AND its length, so not vulnerable to any known collision attacks) means there's an address space of 2^160 or roughly 10^48 possible objects. If you wanted to keep the probability of a hash collision to say, 1 in 100 trillion, then you can safely store about 10^17 objects (source) which is equivalent to the number of git objects if everyone on earth created one per second for an entire year. OK, I may have just shot myself in the foot now by coming up with a scenario in which we'd use up the entire address space in only a year, but that's VERY unlikely.

Anyway my point was that you can consider every commit, blob, and tree to be uniquely identified among all in the entirety of the world. So you could create a system (and maybe this is how hypergit works but I doubt it) where you just have one repository - one "object storage" per device. Then all the fine-grained concepts about identity and access control can be done at the ref level. Instead of thinking of repos as object stores, we could think of them as "just" namespaces for branches and tags.

Edit: I call this the One Repo Hypothesis.

[happybeing]

Your

One Repo Hypothesis

... would sit well on SAFEnetwork, where the address of a blob is its hash, with levels of abstraction above it. The nice part being that immutable data lasts forever. I could go on but don't want to shill. I'm just intrigued by the correspondence here.

[hackergrrl]

@wmhilton You're touching on what IPFS basically does: a global p2p hash space of git objects. :D

[billiegoose]

I think IPFS uses SHA256 though, or multihash. I just want to get across the idea that even within the old-fasioned SHA1 address space used by git, you could probably do this. The limitations are merely practical (file system restrictions etc). They could be abstracted away and "repos" could be replaced with a different abstraction altogether.

[billiegoose]

Oh hey! Perfect example of how this "repo" boundary enforced by Github could be relaxed. You know how PRs can include "Resolves #so-and-so" and then when the PR is merged it auto-resolves the associated issue? Github won't let me auto-resolve an issue created in one repo (https://github.com/isomorphic-git/isomorphic-git/issues/242) with a PR created in a different repo (https://github.com/isomorphic-git/isomorphic-git.github.io/pull/13)

Also, I think @babel wrote a bot to copy issues from individual repos to their new monorepo.

[billiegoose]

Was watching https://www.youtube.com/watch?v=4XpnKHJAok8 and had a mental breakthrough.

What about this workflow?

• you see a cool repository and want to contribute (fix a typo, whatever)
• you click "branch" *
• (insightful bit) the repo adds your local copy as a remote under refs/remotes/{{dat id}}
  • it could also lets you specify an alias like refs/remotes/wmhilton
• you are granted scoped write access to the repository that lets you
  • push packfiles
  • create/move/delete refs under refs/remotes/{{dat id}}

When others clone a repository with hypergit, in addition to the branches in refs/heads they can have the option to fetch a copy of all the branches in refs/remotes. This allows them to immediately do things like "git pull noffle master".

Then all that's needed is a way to create "pull requests". Perhaps by default all users have permission to create refs in refs/pulls?

* note that Linus never uses the word "fork" in his talk;

he always refers to users "working on their own branch". I don't know what the internal politics of Github were that they started using "fork" but to me that term is associated with their goal of centralizing control of git repositories within their proprietary walled garden, which is the anathema of the entire concept of git, which is about distribution. It makes users feel like their "fork" of the code lives on github.com, and what is on their local machine is a mere "clone", whereas in the original git model, everyone's local copy of the data were equal in status.

[hackergrrl]

@wmhilton Interesting. So the idea is that known remotes are automatically pulled down in the initial clone?

[billiegoose]

@noffle Well sure, that's what I would have said if I'd grokked my own idea well enough to distill it into one sentence. 😆

Yeah, "known remotes are automatically pulled down when you clone". That way when you view the hypergit in the gitverse view, you can see what everybody is working on! All the remotes and all the branches. This is getting back to the "Cross-forks project view" that @staltz describes. I'm trying to figure out how one implements it.

[staltz]

Good exercise when designing p2p systems is asking yourself: what about spam?