Modeling & Behavior: Describe Join->Accept->Grant flow #161
The Invite->Accept->Grant flow allowed people to invite other people to
access a resource. What if I want to request access for myself?
This commit adds the Join->Accept->Grant flow, allowing people to
request and receive access to a resource.
Rather than being flexible and ambigious about types of actors, the spec now clearly specifies 3 forge related actor types: - Repository, which already existed - The now added TicketTracker - The now added PatchTracker There are other actor types such as Person of course, but Person is a standard ActivityPub type so we don't need to define it in ForgeFed :) On forges like Gitea and GitLab, projects contain all of those 3 types of components, but any other combination is valid and supported. In addition to adding the actor types: - Ticket's 'context' in the Modeling spec requires the context to be a TicketTracker or a PatchTracker (but I haven't used the MUST word... yet, just in case some unexpected use case comes up) - In the Behavior spec, I removed the section talking about flexibility of actors because explicit actor types are now provided instead (yay, simpler life) Co-authored-by: fr33domlover <firstname.lastname@example.org> Reviewed-on: #157 Reviewed-by: Anthony Wang <email@example.com>
When an ActivityPub client or server wants to interact with some remote object, it needs to identify *which actor controls this object*, and send the activity (at least) to that actor. Right now, as far as I can tell, the way to identify that actor is case-specific: - When commenting on a Note, notify the Note's `attributedTo` - When interacting with a Ticket, its `context` specifies the tracker actor - When interacting with a Commit, its `context` specifies the Repository that contains it - When sending a Grant providing access to some resource... hmm no generic way to determine who the actor (who controls the resource) is! Q: Why not use the `context` property for this? A: Because it's a standard general-purpose commonly used/abused/overloaded property. It's much safer and more friendly to have a dedicated property for this, allowing devs to continue using `context` for whatever stuff they're already using it for. Q: `managedBy` isn't specific to forges, why put it in ForgeFed? A: It's indeed not specific to forges. At a later time, I'd like it to be elsewhere, in its own spec or Fediverse Enhancement Proposal. For now, to make it already available for experimentation and implementation, for now it's in ForgeFed, along with some other properties and types (such as Grant). Co-authored-by: fr33domlover <firstname.lastname@example.org> Reviewed-on: #159 Reviewed-by: Anthony Wang <email@example.com>
Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?