Hey guys, I’m looking at improving the handling of edits (Updates) in the Discourse ActivityPub plugin and I’m curious to see what the ActivityPub brains trust here thinks of the approach I’ve used across these related PRs. There’s further details in the description of the PRs which I won’t repeat here, but happy to explain further if need be.
Can anyone see any issues with this approach of allowing an Updates from an actor other than to whom the object is attributedTo?
Yes, it’s an extension of the authorization scope. HTTP Signatures can be taken to mean that one is scoped to the permissions of the actor, who signed it. This actor has permission to modify the stuff it owns, e.g. where attributedTo is said actor. If one wants to do updates beyond that, one would need a server signing key, with more permissions.
The above has to be taken with a grain of salt. I do not think that the exact meaning of permission scope with HTTP signatures has been formalized. I think @macgirvin has been vocal about his criticism of ActivityPub about not addressing the issue of granting people greater permission scopes. The issue he likes is: You should be allowed to remove a comment from a post.
1b12 Group federation, group moderation section proposes using attributedTo as an ACL. Their example has it as a Collection, but an inline array could maybe work too. (I know here you want to allow Updates by anyone, not just an specific group.)
What, in your respective views, is the single most practical way of supporting the scenario where an actor performs an Update on an Object attributedTo another actor? I’m sure there are many possible approaches. What approach is at the top of your list (and why is at the top of your list)? Or do you think this scenario should not be supported by ActivityPub?
Do I take it that this is your preferred approach @helge?
Activities that create or modify an object - Create, Update, Delete, Undo, Move, etc - must be the same actor as the original object’s attributedTo or activity’s actor. This is generally called the “same origin policy.”
@snarfed Could you explain why you think there needs to be a strict 1:1 relationship between activity actor and object attributedTo? How would a “wiki” feature work with such a rule?
If I’m reading this right, neither of these approaches would support having an Update actor different from an object’s attributedTo, the first being about “changing metadata and remov[ing] malicious content” and the second being about “adding objects to collections”. Is that right?
My goal with that wiki page was just to try to understand what people are doing now, in the wild, and to distill those down to the minimum recommendations to satisfy obvious user expectations. I only really considered the traditional social networking use case - individual users posting their own stuff - and only a couple of the most basic expectations - users can only post as themselves, and they can’t edit or delete other users’ posts.
I don’t know offhand how AP should allow more sophisticated authz use cases. I like that you’re thinking about them! @eprodrom and I were discussing the same thing this morning; it scared us both to even consider designing more advanced authz when AP doesn’t even have the basics nailed down yet. But I guess the standard answer here is, write a FEP and see what people think!
Somebody sits down works out a permission model for ActivityPub / Fediverse that clarifies who owns what, and how additional permissions are granted (explicitly and implicitly).
There are a lot of issues here: Like how to model moderators or allowing somebody to remove a comment. I would claim: It’s a mess and requires a lot of work
However, this does not mean that I recommend to anybody to take my preferred approach. The server signing key is a practical recommendation based on “the server, Discourse, has a much better permission system than the Fediverse, thus let’s use it”. I would call