Endorsements MUST have a context property, which contains a context URI that identifies the nature of the endorsement.

This usage conflicts with FEP-7888. If you're modeling Endorsement after Relationship, perhaps relationship property would be more appropriate?

Endorsements MUST have a proof property, which contains an Object Integrity Proof as defined in FEP-8b32. This is required to prevent someone from changing an endorsement maliciously after it has already been accepted.

Who generates this proof? Who owns the Endorsement object?

This information is crucial for the verification of proofs, see https://codeberg.org/fediverse/fep/src/branch/main/fep/8b32/fep-8b32.md#proof-verification.

Server admins MAY make server-level endorsements on behalf of the server's Application actor.

This statement links to FEP-2677, which requires discovery through NodeInfo endpoint. Consider using FEP-d556, which recommends on Webfinger instead.

@silverpill@mitra.social

Yes, an Endorsement is very similar to Relationship and I wrestled with this a bunch. But I think we're modeling a one-way relationship, not two way. I think it's something like this:

Relationship: Alice <- work together -> Bob
Endorsement: Alice -> endorses work product -> Bob

And in more practical (and less theoretical) terms, this new object allows us to assume tighter controls around how an Endorsement was made. As under-specified as it is, I could post a valid Relationship between myself and Robert Plant (I did meet him once) and there's no way to verify it. Using a new object, like Endorsement, we can rely on the workflow around this object a little more, and can verify that Robert Plant actually acknowledged my endorsement (but I'm certain he wouldn't remember me, the kid in the bookstore)

So, we should reuse as much of the existing vocabulary as we can (context, content, etc) but I think there's a good reason for a new top-level object.

I think it's fine to use a different type. What I wanted to point out is that context property is for grouping related objects, and that there is another property that does exactly you want - relationship.

we're modeling a one-way relationship, not two way.

In a two-way relationship, there is an expectation that another Relationship object exists representing a reverse claim.

Is there another way around this issue that DOESN'T require Object Integrity Proofs?

I am not sure if integrity proofs really solve this problem... It's hard to tell without knowing who signs what (I didn't find that information in the FEP).