What you need is a checksum! sha256 hash with each Endorsement object. Maybe that hash forms part of the id itself, then you don't need a property.

Not sure who's going to yell at me for that one.

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

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.

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?

1. 7888 doesn't lay claim to context, additional uses are encouraged, even

2. Suggest downgrading requirement of proof to MAY. Upgrade it to MUST in a new FEP. Some of us have no immediate plans to support object integrity proofs. Especially since an endorsement is resolvable, there's no need for a proof — t'is merely a convenience.

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?

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

Like, block, etc. don't have that additional concern AFAIK. However it's not a sticking point for me and I am ok with whatever.

https://docs.joinmastodon.org/methods/endorsements/

It's not AP, so it's not conflicting with this FEP, no?

TIL Mastodon has endorsements.

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.

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?

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.

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.

It's not especially hard to add new activity handlers in NodeBB, it's just a personal preference.

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?

With pseudo-namespaces, you see an Activity type that is unique to an Object type. There is no special handling for each type as it doesn't matter. Depending on how painful implementing new AP types is in your software, using namespaces is cleaner and more obvious. If it's a pain to implement new types in your software,...

This also aligns better with Mastodon's existing "Endorsement" objects

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.

We're already derailing from the main topic at hand perhaps we can both agree JSON-LD is pointless and move on.