benpate@benpate@activitypub.space

FEP-3447: Endorsements

This is a topic for community work on FEP-3447: Endorsements. The early-early-pre-draft is currently on my own GitHub, but should be moving to the official Codeberg repository soon.

I recently started a discussion on Mastodon that is ready to move to a bigger venue. So here we are 🤓

Planning and discussion for a FEP to add "Endorsements" into the Fediverse - EmissarySocial/fep-endorsementsGitHubGitHub - EmissarySocial/fep-endorsements: Planning and discussion for a FEP to add "Endorsements" into the FediversePlanning and discussion for a FEP to add "Endorsements" into the Fediverse - EmissarySocial/fep-endorsements
silverpill@silverpill@mitra.social

Replying to @⁨benpate@activitypub.space⁩

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

benpate@benpate@activitypub.space

Replying to @⁨silverpill@mitra.social⁩

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?

Summary of my input: I think "trust" is a better word than "endorse" I think there is no way to get around allowing different "flavors of trust" I am not sure the implementation proposed allows rem...GitHubWording, flavors of trust, and changing your mind · Issue #4 · EmissarySocial/fep-endorsementsSummary of my input: I think "trust" is a better word than "endorse" I think there is no way to get around allowing different "flavors of trust" I am not sure the implementation proposed allows rem...by gillesdutilh
silverpill@silverpill@mitra.social

Replying to @⁨benpate@activitypub.space⁩

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.

Phantasm@phnt@fluffytail.org

Replying to @⁨silverpill@mitra.social⁩

@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