Modeling & Behavior: Describe Join->Accept->Grant flow #161

Merged

fr33domlover merged 2 commits from :join into main

2022-09-25 06:53:52 +00:00

fr33domlover commented

2022-09-09 10:11:31 +00:00

Owner

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.

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.

fr33domlover added the

Core Spec Decision

label 2022-09-09 10:11:31 +00:00

fr33domlover added a new dependency 2022-09-09 10:11:46 +00:00

#160 Modeling & Behavior: Describe Invite->Accept->Grant access granting flow

fr33domlover added this to the OCAPs milestone 2022-09-09 11:22:58 +00:00

fr33domlover added a new dependency 2022-09-09 13:32:45 +00:00

#162 Behavior: Support `Reject`ing a Join request

fr33domlover changed title from ~~WIP: Modeling & Behavior: Describe Join->Accept->Grant flow~~ to Modeling & Behavior: Describe Join->Accept->Grant flow

2022-09-09 13:33:17 +00:00

dachary approved these changes 2022-09-14 20:29:56 +00:00

xy approved these changes 2022-09-17 03:46:02 +00:00

xy added the due date 2022-09-23

2022-09-17 03:46:23 +00:00

fr33domlover added 2 commits 2022-09-25 06:50:57 +00:00

bbc4f30968 Spec: Add TicketTracker and PatchTracker actor types (#157 )

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 <fr33domlover@riseup.net>
Reviewed-on: #157
Reviewed-by: Anthony Wang <xy@noreply.codeberg.org>

d5d650e8dd Vocabulary: Add 'managedBy' property for objects to specify parent actor (#159 )

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 <fr33domlover@riseup.net>
Reviewed-on: #159
Reviewed-by: Anthony Wang <xy@noreply.codeberg.org>

fr33domlover force-pushed join from 823b536b24 to a19870eac7

2022-09-25 06:51:56 +00:00

Compare

fr33domlover force-pushed join from a19870eac7 to 0ec9729c1e

2022-09-25 06:53:16 +00:00

Compare

fr33domlover referenced this issue from a commit

2022-09-25 06:53:52 +00:00

Modeling & Behavior: Describe Join->Accept->Grant flow (#161)

fr33domlover merged commit c94188bb0b into main

2022-09-25 06:53:52 +00:00

fr33domlover deleted branch join