I spent the last few weeks working on Object Capabilities. One of the many challenges I’ve had is to figure out how to handle role attenuation in a federated situation. Example:
- Imagine a system with 4 roles: Admin > Maintainer > Developer > Guest
- There’s a project P
- There’s a team T
- Alice is an Admin in team T
- Bob is a Developer in team T
- Team T has Maintainer access to project P
So which level of access to Alice and Bob have in project P? I’ll save you the details of how OCAP delegation works, here’s the final answer:
- Alice has Maintainer access to P. Although she’s an Admin in T, Maintainer is what P is willing to give.
- Bob has Developer access to P. Although P is wiling to give Maintainer access, he’s only a Developer because he’s limited by the role he has in T.
This works very nicely, because the OCAP delegation chain travels through actors that use the same role system. If they don’t, it’s not going to work. Federation between e.g. Gitea and GitLab won’t work, unless they use the same set of roles. Not just the role names, but the actual actions they allow.
What do we do? Force the entire fediverse to agree on a single set of roles? Force all forges to agree on a single set of operations for each role?
Recently I’ve been rolling this idea in my head: What if, much like the forge federation can host repos, tickets, messages, etc. it also hosts another kind of object, called a set of roles? And then actors can refer to role sets they understand. And forge related actors can delegate OCAPs, if they can find at least one set they have in common. Each side may try to match the roles it uses internally with the roles they have in common. Gradually, we can create sets of roles together, and federated forges can implement them, and things will converge. Makes sense?
In Vervis, my ForgeFed implementation, a feature I’ve had for a long time is custom fields for tickets. It’s an extension of what’s commonly found as “issue labels” in popular forges. Some projects don’t use labels. Some use a simple small set. Some develop a rich set. And either way, it’s always possible to evolve it. But each project has its own separate set. When you create a project, perhaps your forge of choice lets you choose among some predefined sets, or copy a set from another project.
Can we release the process of creating useful label sets from the limitations of forges? Can we have a place where label sets are published and collaboratively evolved, and any project on any forge can then use any label set out there?
What if projects can mix and match different sets of labels from different places?
I know, it’s probably a really minor feature for most people…
So, I’m seeing these pieces of the development workflow, that are sort of about the “culture” we have as a team/group/community of developers:
- Which roles do we have in our organization? What’s the authority structure in our team?
- Which data do we use and collect, both manually and automatically, about our issues, MRs, epics, milestones etc. that we then use to search, sort and filter them, and manage our work and our community effectively?
So, I have this very initial idea: Much like forges host repos and issues etc. etc., another kind of shared resource could a special kind of island called a culture. There, people can collaboratively define stuff like roles, custom issue fields and custom rules for transitions between them, maybe even custom git flows defining how issues, branches, PRs, merges, rebases, tags, reviews, approvals, code scans and releases play together. And projects can freely pick and use whatever they like from those things.
That way, as a community, we can evolve those things together. Have roles, labels, fields, flows, etc. as first-class objects in our forges.
Does this stuff make sense? Or does it sound like some crazy idea that will quickly fade when it meets pieces of reality?
This is not just for fun and exploration; it’s a practical question! Because I need to figure out the roles stuff to finish ForgeFed’s OCAP system