I've updated the document to use "Endorsement" as an object (instead of "Endorse" as an activity). This changes the name to "FEP-d471: Endorsements". I've also tried to incorporate a number of the ideas and suggestions here, including a context URI to identify specific KINDS of endorsements, as well as explanations for many common questions.

If you're following this, now is a great time to revisit the FEP. This whole thing will be migrated to Codeberg soon (a PR is already in the works) and this will be the primary place to discuss updates

As it stands now, Accept, Reject and Undo are identical to activities related to a follow relationship.

I suggest picking more descriptive names for activities:

- OfferEndorsement
- AcceptEndorsement
- RejectEndorsement
- UndoEndorsement

And maybe Endorse should be an object instead of activity? An endorser may want to update the endorsement metadata (content, image, tags).

Hey @silverpill@mitra.social !

I tried to use the existing vocabulary as much as possible. It seems like this fits the existing grammar, does it not?

{
  type:"Offer"
  object: {
    type:"Endorse"
  }
}

Also, Gilles makes a strong point to just use the word "Trust" -- it's simpler and better known around the world. What do you think of that, instead?

I don't know. Why do you want to use the existing vocabulary?

A descriptive activity name leads to a better developer experience:

- You can look at activity and instantly know what action is being performed.
- Servers that implement your FEP don't need to use heuristics, look up object, etc. to figure out what's going on.
- Servers that don't implement your FEP silently ignore unsupported activities, without wasting any resources.

@silverpill @technical-discussion @benpate If you are going through the trouble of using your own vocabulary, why not at least make it so that namespace conflicts don't ever happen again, similarly like they do with semantics using AS Vocab now.

If you implement OfferEndorsement and I want to use it as well, but for something incompatible with your thing. Then I guess I need to invent a new less descriptive name for my thing like: NewAPServerOfferEndorsement, if you effectively reserve that name for your thing and depend on that name being unique for handling.

So I think, something like below is a better solution to the same problem, while admittedly looking worse:

• fep-3447:OfferEndorsement
• fep-3447:AcceptEndorsement
• fep-3447:RejectEndorsement
• fep-3447:UndoEndorsement

Or

• fep-3447:Offer
• fep-3447:Accept
• fep-3447:Reject
• fep-3447:Undo

@phnt I wouldn't say that introducing a new vocabulary is a trouble (unless you care about JSON-LD, which requires deploying a website every time you invent a property or type)...

But you're right, it's better to use prefixes - I already started doing it in my FEPs. Prefixes could be dropped once a FEP is finalized.

@benpate

Also, Gilles makes a strong point to just use the word "Trust" -- it's simpler and better known around the world. What do you think of that, instead?

I prefer "endorse". IMO "trust" is too vague and often used in discussions related to security.
In the user interface, the different flavors of "endorse" could be described using other words.

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).