Weird thought: Merkle DAG based things end up having centralized ownership due to root nodes. Stuff like #ipfs or #dat might converge on large "root nodes" acting as authorities. append-only log based things like #ssb or #cabal are more flat and local

Something like GUN is pretty cool too because it's random bits of data that folks are replicating together with some CRDT magic to have a bit of causality for updates.

Re: “root nodes”, is that a problem if it is effortless to become your own node? Or is there a one-way street or funneling that creates centralization? Of the hash table discovery? (I’m still trying to learn the nuances between the diff protocols.)

I think the main pain point I have is with regards to content discovery and editability. If I've got a website that's only editable by a single person publishing a root node, it's harder to find updates or getting people to collaborate on it without the initial owner adding them

For IPFS and Dat the base is you have a single author with a single chunk of data (IPFS less so with content addressing deduplicating files) With SSB you have a local view of a bigger state of data with stuff that's collaboratively edited.

And with GUN you have an application where basically anyone can add data to it since everyone is swarming together for it. Holochain is kinda similar but they formalize what data can exist in the app with validation code.

Returns-to-scale is another subtle centralizing force. Easy to dismiss at early stages, because "possible to be decentralized in principle". Yet it's a compounding advantage, centralizing the system over time. Real-world old web examples: server farms, streaming video, etc.

You need some sort of "progressive taxation" at the protocol layer that disincentives centralization and incentivizes distribution. Very tricky.

it's all using append only logs and merkle tree. I think the difference here is kappa architecture/crdts?

In ssb/cabal kappa app, a user could still go an fux w their own merkle and cause there to be two conflicting histories and probably break something :) kappas also necessitate data model validation in the app (like holo, as you say)

Interesting! It's kind of like node module trees, isn't it? Lots of us depend on hypercore (for example), so we also depend on its tree of dependencies, giving whoever controls it a lot of power. All we can do is build NEW root nodes higher up and link downward to the big trees.

Bleh. I guess I'm not feeling good about everything being about domination and hierarchy. Like, adding another level of authority seems to just perpetuate the same structures. I have no clue of alternative and from what I'm reading in Hierarchy in The Forest it seems predestined

I think the Q of "who controls these trees/DAGs?" matters a lot. It being managed by a central authority is different than it being managed by a group of individuals, or a committee, or publicly writable.

Most open source projects I see & use don't have formal structures for deciding control. It just kinda ends up being at the whim of the owner ("meh sure i'll add you") or an informal tyranny of structureless sort of thing where a clique runs things but nothing's written down.

Which is interesting, cuz the big Old School Open Source projects seemed to have a lot more intentionality around governance. I kinda wonder if it correlates to when GitHub made open source really popular.

I think a lot of it is down to pace that has been creeping ever upward

Repos getting smaller and smaller make it hard to bother investing a lot of effort into governance also.

Are you still on IRC at all?

yep!

Someone (agh i forget who!) shared an idea with me of a github-like platform where each repo is treated like a shared community resource. There'd be no "owners", and also no "master" branch: just one shared set of - branches - issues - PRs and anyone can contribute.

I'd be really keen to run this social experiment, and see how people learn / not learn to play together. I think this could lead to healthier forking too.

I had wondering if using something like grakn to really actually model _projects_ would provide a space for discussing these questions. Complexity without a good way to visualize it is super taxing.

do you know if the old school open source projects always were intentional around governance? or did the governance grow organically? or are they big and known *because* of their governance?

Likely a mix, though there are coordinating groups from that era that have had made efforts, like the Apache Foundation and Linux Foundation.

I'm wrestling with this exact question right now .. writing a COMTRIBUTING.md for a project that all of a sudden has tons of new volunteers and trying to figure out a good transparent process for giving people commit access (and taking it away) ...

you wouldn't have any suggestions or recommendations for me ?

Don't just like this tweet give me all the advice ! All the advice please now 🙏 also the codes can you plz send. Thanks ;-)