FEP-c7d3: Ownership

[trwnh]

@trwnh

there might be a consideration for the AP server to verify or validate that any partial representation provided by the client will match the resource at that id provided,

after thinking about this some more, i think it’s the same issue with any usage of partial embedding and being able to trust that representation. which is to say: trust is an orthogonal concern, and it falls on the recipient and their client to verify/validate, not on the AP server. in other words, the AP server remains mostly a dumb pipe that carries out limited side effects, and in the case of (implicit) Create, the side effects are mostly limited to id assignment (plus the bits about how they SHOULD copy/merge attributedTo and addressing between the inner object and the wrapping Create, if the Create is explicit instead of implicit)

[silverpill]

@bumblefudge

@silverpill

I can’t simply change “MUST” to “SHOULD” or “MAY” because that would mean no authentication is fine. But I can add a note saying that same-origin check is not the only way to verify relationship between objects.

I think part of the confusion might between “FEP as draft SWICG Report” and “FEP as documentation of single-implementation experiments”. As I understand it, FEPs describe how other implementations can interop with a feature being experimented by the author’s implementation; they are NOT ready for widespread adoption as-is and are NOT being proposed for Fediverse-wide adoption.

There is no confusion. FEP-a4ed states it pretty clearly: “A Fediverse Enhancement Proposal (FEP) is a document that provides information to the Fediverse community.”

FEP-c7d3 is proposed for Fediverse-wide adoption. Moreso, it documents practices that are already widespread in Fediverse.

@bumblefudge

I think it’s also fair-game for a FEP to only work for Mastodon-API or powerful-server-model implementations

This FEP has nothing to do with Mastodon API or powerful-server-model.

[bumblefudge]

@silverpill

There is no confusion.

By “confusion” I was referring to Evan asking that the MUST be stricken because it makes assumptions contrary to the design of AP/AS. I think he’s right that a FEP should not become a CG Note if it contradicts affordances of core protocol, but I also think it is “fair-game” (i.e. conformant to FEP-a4ed) for a FEP (even a “status: FINAL” FEP!) to make strong-server or same-domain assumptions! I think acknowledging it as a transitional solution or one specific to the other extensions/capabilities your implementation is targeting is totally fine in a FEP; we can save the objections and cagefights for when the FEP gets proposed as a CG work item.

And I know full conformance to the Mastodon-API is not a pre-requisite of this FEP, that comment was aimed at Steve’s point that C2S is somewhat theoretical in 2024 if you’re targeting smooth interop with millions of end-users . Sorry if I’m dragging us further and further off-topic here, we should get back to giving your FEP useful feedback now!

[stevebate]

@bumblefudge

that comment was aimed at Steve’s point that C2S is somewhat theoretical in 2024 if you’re targeting smooth interop with millions of end-users

To be clear, I feel that “somewhat theoretical” is a significant understatement for 2024 and probably for quite some time (if one is targeting interop with more than approximately zero users).

This thread of discussion has shown me a few more aspects of C2S where the semantics of the API are not at all clear.

[stevebate]

@trwnh

@stevebate

It must at least support dereferencing the AS2 Image, right?

yes, but any web server can do this. it doesn’t need to be an AP server. (unrelatedly, the application can be an AP client.)

This statement about “any web server” doesn’t make sense to me. It’s creating AP objects and serving them using the AP content type. “Any web server” doesn’t create and store AP objects without some AP-specific software to do it. Whether it also implements AP client (C2S) functionality is a separate topic.

[stevebate]

@silverpill, although it may be out of scope for this FEP, have you thought at all about collective ownership of objects (members of a Group or Organization). I’m thinking, for example, of a group that might be authorized to modify a shared Collection. I know that ownership and authorization are separate concerns, but they seem somewhat closely related in this FEP.

Is it correct that

If activity modifies or deletes an object, its owner SHOULD match the object’s owner. If owners are different, their IDs MUST have the same origin.

would prevent a group ownership where the group members are from different origins?

Another question… given:

The object is considered authentic if any of the following conditions are met:

1. It was fetched from the location that has the same origin as its owner’s ID.
2. It was delivered to inbox and the request contained a valid HTTP signature created using a key whose owner has the same origin as the object owner.
3. It contains a valid FEP-8b32 integrity proof created using a key whose owner has the same origin as the object owner.

If none of these conditions are met, the object MUST be discarded.

and

• An object (that is, not an actor and not an activity) can have an attributedTo property, which describes the actor to which the object is attributed. This actor is considered to be the owner of the object.

Does that mean an “object” without an attributedTo property is not owned or that the ownership status is undefined? Or something else?

For example, if an outbox is dereferenced and there is no attributedTo property in the fetched object, does this FEP require that object to be discarded (since none of the authentication conditions are satisfied)?

(FWIW, I think collections (including inbox and outbox), should have an attributedTo property, but that’s a different discussion.)

[trwnh]

@stevebate

It’s creating AP objects and serving them using the AP content type. “Any web server” doesn’t create and store AP objects without some AP-specific software to do it

The point I’m trying to make is that these are all separate concerns. AS2 objects can be serialized / generated / persisted to a filesystem by some program, and then served by any web server that has access to the backing file. Neither the program nor the web server need to be aware of AP at all; AP C2S is a progressive enhancement to the program.

Example:

• You go to drawing.example and make a drawing
• You click Save
• drawing.example generates an AS2 Image and stores it locally
• You can fetch the AS2 Image by doing an HTTP GET

At no point is AP involved at all. AS2 is used as a data model for providing metadata about drawings.

Now say you want to add AP support and turn drawing.example into an AP C2S client. This can be done like so:

• At the Save step, drawing.example can ask you whether you want to authorize to an AP server and send out a Create activity to any arbitrary audience
  • The Create is stored on your AP server’s backend, but the Image remains on drawing.example

[bumblefudge]

@stevebate

(if one is targeting interop with more than approximately zero users).

I would not presume that the lack of any public roadmaps or announced funding rounds for C2S projects is a reliable indicator of nothing happening outside of the Mastodon API. In fact, a’s very subtle point about “AP objects” being an oxymoron and all objects that AP passes around actually being “AS2 objects” might be less academic than we know! I wouldn’t build a C2S project without some real funding, and I can’t imagine many funders of such a project wanting its fundees to blab about such a project before launch

To put it another way, a microblogging project whose northstar is interop with MAUs would, of course, be crazy not to measure all design decisions against S2S legibility to the users on Threads and Mastodon. But other kinds of projects would naturally have other metrics…

@stevebate

Does that mean an “object” without an attributedTo property is not owned or that the ownership status is undefined? Or something else?

For example, if an outbox is dereferenced and there is no attributedTo property in the fetched object, does this FEP require that object to be discarded (since none of the authentication conditions are satisfied)?

I love this line of questioning, and I’m not sure that discussion needs to happen elsewhere! One nuance of our kooky JSON-LD ontology (actually defined in RDF which is ignored by people working in JSON-only mode) was totally lost on me until last week when a pointed it out to me in another thread: any JSON[-LD] Activity has an “implicit” attributedTo by dint of having an actor property, at least when expanded to RDF, thanks to the ontological definition of Actor. Might (or should) inboxes and outboxes have an “implicit” attributedTo as well, i.e. the Actor object they sit in? If actors and activities both have attributedTo properties implicitly, making them mandatory for Objects might not be as radical an extension to the protocol. Indeed, it might be a simple and elegant way of figuring out a lot of nagging interop problems like CORS/cross-domain ownership, group actors, “Server Actors”, etc. I’m all for it!

Selfishly, I’m poking this hornet’s nest on purpose to get smarter people’s perspectives on what might, might not, should, and should not break when an Actor object sits in a different domain than its Inbox, in general, not just in the context of this FEP. I feel like so much of the nuance that went into the design of the AP protocol (often implicitly or contentiously) was lost in the square-peg/round-hole of the spec’s editorial process… and now needs to be written down urgently by different people intuiting and reverse-engineering it. If nothing else, debating these hunches and hypotheses here helps us establish a baseline understanding of status quo against which to debate breaking changes, and also to settle “who’s fault is this” interoperability disputes

[bumblefudge]

(and a’s offhand suggestion there of using net-new properties like onBehalfOf where overloading attributedTo struck me as really interesting, too! might sidestep the problem erincandescent pointed out)

[stevebate]

@bumblefudge

Might (or should) inboxes and outboxes have an “implicit” attributedTo as well, i.e. the Actor object they sit in?

It’s a common mental model, but inbox and outbox don’t “sit in” the Actor object. The Actor references the URIs of the boxes. They can be, and often are, dereferenced directly. Usually there’s a related actor floating around somewhere on the requester side, but it’s also possible the outbox URI could be provided in some way independent of the actor associated with it. AP is very flexible in that way.

For an Activity, it’s effectively explicit. The actor property is a subproperty of attributedTo.

[bumblefudge]

@stevebate

It’s a common mental model, but inbox and outbox don’t “sit in” the Actor object.

OK, let me ask it again rephrased. Should the inbox and outboxes at the other end of those URIs have an implicit attributedTo of the Actor(s) that point to it, if known (i.e. if you found that inbox or outbox by following a URI from an Actor object)? Would inboxes or outboxes with multiple actors (is that possible btw?) be able to have an array of actors in their AttributedTo ???

[stevebate]

@bumblefudge

OK, let me ask it again rephrased. Should the inbox and outboxes at the other end of those URIs have an implicit attributedTo of the Actor(s) that point to it, if known (i.e. if you found that inbox or outbox by following a URI from an Actor object)? Would inboxes or outboxes with multiple actors (is that possible btw?) be able to have an array of actors in their AttributedTo ???

My opinion is that they should have an explicit attributedTo property. I don’t know of any way to determine an implicit attribution given just the box given the lack of general-purpose query support in AP.

Sure, attributedTo can have multiple subjects/URIs. Per the AS2 Vocab, attributedTo …

Identifies one or more entities to which this object is attributed.

Same for actor…

Describes one or more entities that either performed or are expected to perform the activity. Any single activity can have multiple actor s.

But in practice… most (maybe all?) implementations only support one value for both properties. I think this FEP allows multiple values if they are from the same origin (?).

Side note: those actors (and attributions) are not required to be from the same origin.

[silverpill]

@stevebate

@silverpill, although it may be out of scope for this FEP, have you thought at all about collective ownership of objects (members of a Group or Organization). I’m thinking, for example, of a group that might be authorized to modify a shared Collection.

I think modification of a shared object can be done in two steps. For example, adding a Note to a shared collection:

• Group member sends a private Create activity to the group actor: Create { actor: Person, object: Note, target: Shared }. This activity doesn’t modify the collection, but the target property indicates that modification is requested. We can use an Offer activity if Note is already Create’d.
• Group actor verifies membership, generates a public Add activity, and sends it to group followers: Add { actor: Group, object: Note, target: Shared }

Recipients of such Add activity don’t need to know how to verify membership (the procedure may vary depending on group implementation). They just need to perform the same-origin check, which is fast and simple.

@stevebate

Does that mean an “object” without an attributedTo property is not owned or that the ownership status is undefined? Or something else?

Objects without owner are owned by the server indicated by their id. This is addressed in “Unattributed objects” section.

[stevebate]

Thanks for clarifications. Responding in reverse…

@silverpill

Objects without owner are owned by the server indicated by their id. This is addressed in “Unattributed objects” section.

I think that indirectly answers my question? So, you’re saying objects without attributedTo do not have an owner, except they do (the server). In any case, the phrase “Objects without owner are owned by” is confusing at best. So, the server owns all inboxes and outboxes if they don’t have an attributedTo property?

Elsewhere, the FEP states:

The owner of an object MUST be an actor.

I assume you mean an AP Actor. But a server, in general, is not an AP actor (regardless of “instance actors” used for that purpose in some implementations) and does not have an “id”/URI (I’m referring the Authentication criteria).

For the Group/Organization authorization question, we seem to be pretty far apart on how we think about this. I was thinking of Groups and Organizations as models of groups of Actors, not as computational entities. However, I understand that the use of those types of AS2 Actors is not well-defined (or maybe not defined at all) in AP.

Recipients of such Add activity don’t need to know how to verify membership (the procedure may vary depending on group implementation). They just need to perform the same-origin check, which is fast and simple.

Does the “same-origin” origin policy mean that any Actor from the same origin as the shared resource can modify the collection, not just the owner or the authorized group of Actors? I don’t think I would like that.

And, like I said in a previous response to @bumblefudge , a Group or Organization may group Actors from multiple origins. But I guess with your proposed “active Group” (aggregator, republisher) design, you’d require the Group Actor itself to always be the same origin as the shared resource?

[trwnh]

@stevebate

For the Group/Organization authorization question, we seem to be pretty far apart on how we think about this. I was thinking of Groups and Organizations as models of groups of Actors, not as computational entities. However, I understand that the use of those types of AS2 Actors is not well-defined (or maybe not defined at all) in AP.

My understanding is that they are just like any other actor, representing a singular entity. The concept of “membership” is something best left to a separate FEP.

[stevebate]

@trwnh

My understanding is that they are just like any other actor, representing a singular entity. The concept of “membership” is something best left to a separate FEP.

That’s a good point. I’m not suggesting adding it to this FEP. I’m exploring how the policies required by the FEP would or would not be compatible with a more general set of authz policies. I’m working on a server implementation and I’m trying to decide if I’d want to implement this FEP’s “requirements” or not. At this point, it seems to me to be overly restrictive in some ways and overly permissive in others.

---

The AS2 Group is described as “a formal or informal collective of Actors”. I’m thinking more along the lines of the “collective” being modeled as a Collection (e.g., "type": ["Group", "Collection"] (of Actor types or Relationship) and using that model to support group-based AP authorization decisions. Note that AS2 Actors are not the same as AP Actors since AS2 Actors do not require an inbox and outbox. It’s confusing because they use the same vocabulary, but I’m talking about the AS2 Group (which, optionally, could also be an AP Actor). The Group can also be the subject of attributedTo as an AS2 (vs AP) Actor.

I think I’ll not discuss Organization any further since there’s practically no definition for it in AS2 (it’s defined as “Represents an organization”).

[bumblefudge]

@stevebate

I think I’ll not discuss Organization any further since there’s practically no definition for it in AS2 (it’s defined as “Represents an organization”).

Yeah that part we can probably discuss in a [future] separate thread, unlikely to help silverpill draft his FEP, and could lead to long sidequests about legal liabilities and compliance

@trwnh

The concept of “membership” is something best left to a separate FEP

FWIW the Threadiverse group has been working in overdrive on this all summer, and my governance intuition is that anything this general and critical to cross-form-factor/user-story interop should ideally be hashed out beyond the microblogosphere at the “protocol-wide concern for corner-cases” level, not in “my users and their UX are my only concern” mode. Here are the FEPs I know of that might be relevant:

• FEP-400e: Publicly-appendable ActivityPub collections
  • FEP-db0e: Authentication mechanism for non-public groups: “mostly intended to supplement FEP-400e.”
• FEP-1b12: Group federation
• exhaustive socialhub thread “reconciling” and interoperating between the two above
• by way of comparison, it seems bsky’s ATProtocol has no group actors or plans to have them in-protocol?! i wonder how feeds like blacksky are built, given this constrain.

(a, silverpill, and probably steve are well aware of this, but just for posterity and people who randomly find themselves here, thought cross-links would be helpful to catch people up)

[trwnh]

@stevebate

The AS2 Group is described as “a formal or informal collective of Actors”. I’m thinking more along the lines of the “collective” being modeled as a Collection (e.g., "type": ["Group", "Collection"] […] I think I’ll not discuss Organization any further since there’s practically no definition for it in AS2 (it’s defined as “Represents an organization”).

My mental model treats as:Person/as:Group/as:Organization as similar to vcard:Individual/vcard:Group/vcard:Organization or foaf:Person/foaf:Group/foaf:Organization. This would suggest that AS2 ought to have an equivalent of vcard:hasMember or foaf:member. If you want to model that as a multityped Collection then I guess you could do that, but it seems like there is precedent for something more like a special collection of members.

As it relates to this FEP and the concept of “ownership”, however, I think that it’s possible to have the Group actor be a proxy or representative actor through which its member actors can perform actions as the Group if need be. This starts to get into a lot of other tangential topics though, such as RBAC within a Group, and how to model the intersection between a Group and an Organization, since in vcard/foaf, these are actually considered separate kinds/types that are actually disjoint with each other. Which is to say, an Organization in these vocabularies MUST NOT declare a vcard:hasMember or foaf:member property. Which is to say, this all requires much further thought.

@stevebate

how the policies required by the FEP would or would not be compatible with a more general set of authz policies

If you take the view that an actor can be puppeted by other actors, then the authz policies are generally orthogonal to the ownership concern (which can be expressed by attributedTo as described in this FEP)

[silverpill]

@stevebate

In any case, the phrase “Objects without owner are owned by” is confusing at best.

I agree and will change that phrase.

@stevebate

So, the server owns all inboxes and outboxes if they don’t have an attributedTo property?

Yes.

@stevebate

I assume you mean an AP Actor. But a server, in general, is not an AP actor (regardless of “instance actors” used for that purpose in some implementations) and does not have an “id”/URI (I’m referring the Authentication criteria).

It is not wrong to say that unattributed objects are owned by a server actor. Same origin rule will work as one expects. However, I’d prefer to not bring the notion of a server actor to this FEP.

@stevebate

But I guess with your proposed “active Group” (aggregator, republisher) design, you’d require the Group Actor itself to always be the same origin as the shared resource?

Yes. This seems to be aligned with FEP-1b12 and Conversation Containers where groups / conversations have centralized authorities.

[stevebate]

@silverpill

Yes. This seems to be aligned with FEP-1b12 and Conversation Containers where groups / conversations have centralized authorities.

It could be. I never claimed it wasn’t aligned with at least some use cases. However, I’m thinking of use cases other than centrally-controlled forums (other kinds of more decentralized group-based online social interactions).