FEP-c7d3: Ownership

In this FEP I talk about the concept of ownership in ActivityPub network, and specify authentication and authorization procedures based on it.


Seems fine mostly, but the “first actor is the owner” doesn’t hold up technically. They’re unordered sets. It would be a mistake to make such assumptions based on ordering of the JSON presentation. We currently make the same mistake with the attachment array.

1 Like

I’d prefer an extension (e.g., maybe an explicit owner property?) rather than redefining existing terms.

In the Ownership section, you mention that AS2 defines some of the terms you are using, but then you use a variation of those definitions (or attributedTo, for example). A section that describes differences with the AP/AS2 recs could be useful.

Every activity MUST have an actor property, which describes one or more entities that either performed or are expected to perform the activity. These entities MUST be actors and the first actor is considered the owner of the activity.

Any entity that is the subject of an actor property is an actor, by definition. The MUST seems unnecessary.

True, but what could be done about it? The FEP may say that actor and attributedTo values MUST be a single actor, but multi-actor attributedTo values are actually quite common, for example PeerTube uses them.

Yes, ideally it should be a new property, but actor and attributedTo are already used in the way described in this FEP. I think it wouldn’t hurt if we adjust definitions based on the implementation experience.

By variation, do you mean the removal of “The attributed entities might not be Actors” from the original definition?
I could add a note about that.

I’d like to keep that part for completeness.

That (which is significant), and the concept of a “first” item in the actor and attributedTo sets, and that attributedTo is required for every object.

I was saying that it is complete without it. It probably doesn’t hurt to add redundant information, but it might raise questions about whether a specific point is being made.

1 Like

I think you could say an activity is valid as long as it’s signed for by… any of? all of? the “owners”. That could be tricky to authenticate, but it’s where we are. The same issue arises for multiple inReplyTo or multiple context when paired with various control/authorization schemes.

1 Like

I updated the proposal. Now it requires actor and attributedTo values to contain a single actor, and says in “Implementation notes” section that multiple owners are possible but not covered.

Diff: https://codeberg.org/fediverse/fep/commit/d62f5722801b5824af1464e845ac83785fcff4d4