@benpate I still agree with @silverpill@mitra.social that Endorsement makes more sense because it's metadata can be updated (content, tags, etc.)

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.

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

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

@benpate could Endorsement types be split off into a separate FEP? I think keeping things simple makes it easier for potential devs to digest.

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?

Two thoughts:

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.

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?

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

@benpate thinking out loud, we don't need proofs to do this, they just guarantee that the object the proof is attached to hasn't been modified in transit.

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.