@[email protected]

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’d rather not use Object Integrity Proofs either, and I’d be happy to cut them entirely. But here’s the big issue I’m concerned about:

Someone may endorse me for one thing (Ben likes Tea) that I’m perfectly ok with. I accept the endorsement, but then they maliciously change the endorsement (Ben likes Coffee, gross) and I still keep their endorsement, leading me to lots of embarrassment.

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

Yes, that’s a good idea. I’m hoping we can make a really streamlined document for the protocol and then to put the other important “how to use this” stuff into some separate document. So it makes sense to put context types somewhere else, too.

For the very short term there’s a lot of overlapping conversations so it’s easier for me to dump everything into one big messy document. Will that work, with the general understanding that context URIs break out into their own FEP long before we start building?

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

Ok. I’m going to rewrite it as a noun and see how that works.

Yes, exactly. It’s not AP now, so it’s not technically reusing the name. If anything, we’re taunting Mastodon to just connect up what they’ve already got in place. Though, they may be ditching this in favor of their new “Collections” feature – which will be very cool.

@julian I’m spinning back and forth on this. Should this be a noun or a verb? In a way, it’s kind of irrelevant - we could query this data all the same whether they’re objects or activities.

Pros for Activity:

• Follow, Like, and Block are all activities. Endorse should feel parallel to them
• We have other examples of actors Accept-ing and Reject-ing other activities.
• Mastodon API already publishes Endorsement, so we shouldn’t overlap with that.

Pros for Object:

• Offer(Endorsement) reads cleaner than Offer(Endorse)
• As a noun, an Endorsement feels like something I could pick up and hold, attach a signature to, or put on my home page.
• Mastodon API already publishes Endorsement, so we’d just be opening this up to a broader ActivityPub audience.

content should probably be free-form HTML, so maybe not? But we definitely need something – I’m kicking around either tag or context for this.

I’m leaning towards context because we could define URL-like namespaces for specific things, where tags are usually more of a “folks-onomy” and therefore harder to aggregate.

What do you think?

Thanks for this. All good points :)

Add “FEP-8b32 Object Identity Proofs” into the mix, and we may get to skip one of those HTTP lookups. We’re going to NEED signatures on endorsements to keep people honest, with the side-benefit of simplifying some network stuff in the meantime.

@[email protected] This implementation detail is a good point. Thank you for clarifying.

In my own software, I think we’re already doing this - dereferencing the “object” of an activity before I route it to the appropriate transaction handler. Given all of the different kinds of activities we have to accept, it seems like this would already be a requirement for any ActivityPub server, yes?

@julian Yeah, the Noun/Object form may be cleaner than Verb/Activity. I don’t have a good reason why I chose one over the other. It’ll probably change the FEP name and number, but that’s not really a big deal.

This also aligns better with Mastodon’s existing “Endorsement” objects

@[email protected] - how would these semantics be different from the definitions we already have in Activity Vocabulary? And, if the existing Accept and Reject activities aren’t meant for this, what are they meant for?

@julian - Since I’m the next guy, we’ll have to arm wrestle over who’s more against JSON-LD :)

Hey @[email protected] !

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?