peers/forgefed

+++ title = "Team-Resource Links" date = 2024-07-14 [extra] author = "Pere Lev" +++

The previous posts described project nesting and team nesting. So at that point, it was possible to:

Create projects with components in them
Create project hierarchies
Create teams
Create team hierarchies
Add collaborators/members to projects/components/teams

There are still details to polish, of course (e.g. how to link a Repository with its PatchTracker), but the core authorization system has been missing one final piece: Adding teams as collaborators in projects and components. This piece is now implemented! All the exciting info is below, including a demo.

As always, my task board is available.

Collaboration via Teams

The main purpose of gathering people in Team actors is to make access control easier: You create a Backend team and give this team access to the backend-related repositories and resources.

Before, we were forming child-parent links between projects, and then between teams. Now there's a new kind of link, in which:

One side is a Team actor
The other side is some resource actor, that isn't a Team

The resource actors mentioned in the ForgeFed specification (and implemented in Vervis) are:

Project
The 3 component types: Repository, TicketTracker, PatchTracker

So these resources can now, in addition to regular Person collaborators, have Team collaborators, via the new kind of link.

Team-resource links are created and removed using a mutual-consent process very similar to how parent-child links work, so I won't go into the technical details. See the previous posts for those.

In the UI, here's where I placed team-resource links:

For teams, there's now a Projects tab (which I'll probably rename to Resources)
For resources, under the existing Collaborators tab there's a teams section

Bonus: Inbox Debug Reports

Vervis has had some UI for examining the activities received in actor inboxes, and the results of their processing, but this feature was very lacking. In particular:

Only error messages are shown, while successful processing results aren't
Only S2S remote activities are shown, on a per-instance page, i.e. local activity results aren't displayed anywhere and actors don't have their own per-actor debug reports
Activity reports are stored in-memory, which means they disappear when Vervis is restarted

The debug report system recently got an upgrade!

Actors have their own "errbox", i.e. an inbox displaying activities whose processing resulted with an error
Actor inbox display shows processing results, whether it's error or success
The per-instance federated report page grabs activities from the DB, so they don't disappear when Vervis is restarted

This upgrade made my life so much easier, during the work on parent-child and team-resource links.

"Errbox" link for every actor:

Inbox item, including processing result:

Implementation

I started from the DB, UI and API parts, and left the sweet actual S2S implementation for the end. While working on this task, I also polished, fixed and added missing bits for project-component links, which made this task take longer than I hoped (but those bits were important).

The OCAP implementation for components is reusable, but right now only TicketTracker is using it. Repository and PatchTracker are temporarily out of the game for now, because I want to figure out the details of linking them together, as well as the mechanisms for federated-OCAP git-push. Then, when I see the bigger picture, I'll wire in these components as well. Want to join the brainstorming on this? Comment on the issue <3

Team-resource links:

Inbox debug reports:

Funding

I really want to thank NLnet for funding this work! The extended grant is allowing me to continue backend work, and allowing André to work on the Anvil frontend.

Next Steps

Meanwhile, the Anvil frontend is making progress as well:

The previous blog post has a list of challenges waiting ahead. With the core OCAP system complete, I'm now looking at the list of remaining funded tasks. There's primarily 3 kinds of tasks:

Documentation, API and bug-fixing, to support Anvil's development, and the deployment of a Vervis-Anvil federated forges
Actor-programming library and demo (much more powerful than the current ActivityPub-based OCAPs, and I believe necessary for the growing federated ecosystem)
Vervis core features for Repository and PatchTracker

The 2nd kind is the most difficult for me: Create a powerful type-safe actor-programming library in the Haskell programming language. I already started this, probably over a year ago, but haven't touched that work in a long time. And it's quite advanced Haskell (at least for me). Luckily there's already work by another NLnet-funded project, and the Haskell implementation of Cap-n-Proto, which I hope to reuse.

In the coming months I hope to touch all of those tasks. But I'm not sure yet how to divide my time and focus between them. I'm especially afraid to spend a lot of time on the actor-programming library, and end up failing. I really need the income right now, so working on safer tasks is easier. On the other hand, much of my remaining funds are for the library. We'll see :)

See It in Action

I recorded a little demo of all this! Watch it on my PeerTube instance.

If you want to play with things yourself, you can create account(s) on the demo instances - fig, grape, walnut - and try the things I've mentioned and done in the video.

If you encounter any bugs, let me know! Or open an issue

Comments

Come chat with us on Matrix!

And we have an account for ForgeFed on the Fediverse: https://floss.social/@forgefed

Right after publishing this post, I'll make a toot there to announce the post, and you can comment there :)

index.md 13 KB Link permanente Histórico Raw