Gavin has been doing some interesting work on this, and is considering using "Endorsements" as a vetting process for products before they're allowed on his federated marketplace.

In the case of product reviewers, I might legitimately endorse several hundred products. The same goes for institutional endorsements, such as my college professor endorsing me as one of his students, or my collect endorsing me as a graduate.

@scottjenson @GavinChait @ozoned

I'm not saying this to bring more clarity, but to say that -- as I dig into this deeper, it's harder and harder to make some clear rules.

I'm optimistic that various "endorsement types" might help us, with corresponding expectations and norms around each one.

I still have to digest Gavin's most recent emails, then I'll try to put something forward.

Above all, I'm happy to be the secretary on this, but this FEP will be everyone's design.

@scottjenson @GavinChait @ozoned

@benpate @GavinChait It's always a "particle/wave" type of discussion where you discuss theory for a while (which has it's concerns) then implementation for awhile (very different concerns) and you ping pong back and forth, trying to not get burnt out in the process.

But I often find a very simple implementation detail can short circuit all sorts of theory based navel gazing. That is likely going to be the biggest hurdle, to ground the discussion so we don't wander off into "the land of the perfect design"

@scottjenson @benpate my very real design requirement is that no product on my federated market can be sold without attestation from a third party reviewer. That review gates release. So, a creator invites a reviewer to review. The approval is an attestation object which permits publication of the product. But the audit trail is a chain of attestations. An instance admin endorses each of the seller & reviewer. The instance actor endorses the admin, & nodeinfo identifies the instance actor.

@benpate @GavinChait It's always a "particle/wave" type of discussion where you discuss theory for a while (which has it's concerns) then implementation for awhile (very different concerns) and you ping pong back and forth, trying to not get burnt out in the process.

But I often find a very simple implementation detail can short circuit all sorts of theory based navel gazing. That is likely going to be the biggest hurdle, to ground the discussion so we don't wander off into "the land of the perfect design"

I ran into this by coincidence and you don’t know me, so ignore at your will. However, my experience in both social networks and currencies suggest that if you try to limit max count, you’re making it more gameable. What might work is “weight”: the more people endorse me, the more my endorsement has value. The more I spread that to others, the less one endorsement means. It’s still very gameable and a market will form, but it balances better than a hard limit. Federated accounting will be a bit of a challenge.
@scottjenson @benpate @GavinChait

@scottjenson @benpate this auditable chain can be used anywhere needed, with attestation roles assigned to attestors which scopes what they're permitted to do. In a network without central authority, chained attestation is the only record of trust we can offer to create supply source transparency. Attestations can be limited: period, hashed fingerprint... Sure a famous person could endorse a product, but who endorsed them to endorse the product? What weight does that endorsement carry?

@GavinChait

I love this discussion because it gets right to the heart of the human nature, Fediverse, and what makes this the right technology for us to build on.

And, I love the can of worms that we've opened here. I'm still reading through your email about Endorsements and Attestations probably being different beasts -- that may be a good choice. But each is going to learn from the other, so I'm eager to dig deeper into this

I ran into this by coincidence and you don’t know me, so ignore at your will. However, my experience in both social networks and currencies suggest that if you try to limit max count, you’re making it more gameable. What might work is “weight”: the more people endorse me, the more my endorsement has value. The more I spread that to others, the less one endorsement means. It’s still very gameable and a market will form, but it balances better than a hard limit. Federated accounting will be a bit of a challenge.
@scottjenson @benpate @GavinChait

@osma @scottjenson @benpate it still depends what this is for. A straight "number go up" endorsement is always gameable, no matter how you try to mitigate. But endorsements of specific things for specific purposes by actors which are themselves endorsed with the authority to offer that endorsement is an attestation chain that conveys some auditable sense of trust.

Tagging those who contributed to the `Endorse` activity design. Here's an update

https://github.com/EmissarySocial/fep-endorsements

There's more work to do, but it's enough that your input is super valuable. Another round and I'll post to codeberg.

Feel free to share with anyone with informed opinions, and no worries if you're busy/sick/uninterested/whatever - absolutely no obligation to join in

@scottjenson @DePemig @thisismissem @johannab
@oli @laurenshof @wjmaggos @smallcircles @GavinChait @evan
@iftas @tchambers

Yes, this makes a lot of sense. Thanks for joining the conversation

Ultimately, decisions about "who to trust" will be up to each individual app/server/user. So, we don't REALLY need that in a simple protocol design about how to publish Endorsements.

But, we want to work our some solid recommendations so that our first dozen implementation aren't immediately abused by the people we're trying to reign in.

@osma @scottjenson @GavinChait

@benpate I think it's a genuine gap in AP right now, & the timing for this discussion is excellent, for me anyway.

I'll let Gavin detail his use case, but I think the "root" is relative to each observer.

From my POV as a user, or the application running on my server, I think the "root" in this case would be the application account on each server. From there, we could branch out to see who WE trust, which is probably similar-but-not-quite-the-same as who someone else might trust.

Does that make sense?

@osma @GavinChait @scottjenson

@benpate @GavinChait I think this is a lovely example for us to work through, but it does feel different than Ben's original point. The original point was, what can I know StrangerA? It was fairly lightweight. It was just like, oh, I know the three people that claim they know StrangerA. That is genuinely helpful.

However attestation feels like it's entering whole other domain. I'm not against it, but it feels like a V2 of the protocol. Does that make sense? I generally prefer walking before running...

@ramsey @GavinChait @benpate @tchambers
I agree with your concerns. This is what I meant by the complexity issue in a previous thread. It *is* YAF (yet another feature) and if we're not careful, people just a) won't get it or b) not be bothered.

But need is clear. Follows and likes aren't enough. This is a public connection *between* two people. That is its difference. It's power comes from the "rel=me" aspect of both people agreeing. That appears powerful. It is a stronger signal to to build a web of trust, feels decentralized, durable, and seemingly unspoofable (I hope?).

But we really do have to keep it simple. Maybe we call it something else? But I'm hearing the concern that you feel it's not actually that valuable? Do I have that right?

@scottjenson @ramsey @benpate @tchambers I think it's more "how do you intend for this to be used?" than whether important or not. I never use likes, but some people prefer them. The affordance isn't a problem. More that we don't overclaim what it can be used for.

@GavinChait
I started to sketch a couple of designs and quickly ran into some serious questions that might be helpful for us to discuss here. Let's start with a simple one. What do we show the user? Do we show them a number between zero and one?

There's a lot of magic here, and if we're not careful, we'll make it far too complex to the user. I'm leaning towards a simple three icon approach: low (some type of endorsement) medium (good endorsement) and high (exceptionally strong). There can also be NO icon at all.

I don't think someone cares if someone is 67% endorsed versus 78% endorsed.

I also think that endorsements are going to be somewhat rare (at least at first) so the chances of this icons showing up AT ALL is quite low. I'm playing with the idea that your followers endorsements act as a weak signal (low). This provides a 'gateway scoring' system that gets people exposed without initiallying having any endorsements of their own.

Thoughts?

@ramsey @benpate @tchambers

@scottjenson @GavinChait @benpate @tchambers What is low/med/high a calculation of? IOW, when someone endorses you, is it like favoriting them, thumbs up or thumbs down (i.e., “down” de-ranks them), or a rating system (e.g., 1-5 stars)?

I could see how thumbs up/down or ratings can lead to low/med/high scores, but just a simple “I endorse” toggle won’t have much signal, unless it’s treated as a percentage against followers or some kind of static thresholds (e.g., <25 is low, <100 is med, etc.).

@scottjenson @GavinChait @benpate @tchambers What happens to your endorsements or to those you endorsed when you move servers?