@GavinChait @ozoned

Agree wholeheartedly. @scottjenson had some great initial ideas on this. Here's some of the controls he suggested as a starting point:

- limit the total # of endorsements one person could make
- rate limit the speed that actors could make endorsements

Enforcement is up to the listener. Looking at who and how you've endorsed, do I believe you? With this, a botnet with 1000 self-endorsing sock-puppets could be identified automatically and silenced.

@benpate I need to namespace some of the concepts I am using for hopsauna, so I can use a version there till the AP spec supports it. But, yes, an endorsement, used appropriately, should carry weight. Not just another LinkedIn "number go up".

@GavinChait

Right now, I think Endorses are *very* similar to Likes, with some exceptions:

- you endorse ACTORS, you like CONTENT
- endorsements should be rare. Likes/Boosts should be frequent.
- endorsements must be offered and accepted. Two-way consent.
- endorsements carry additional metadata, such as a statement from the endorser, hashtags, or other information about the endorsee.

Does this work? I'm very open to any changes that will make this better

@benpate I suppose I can speak to my use-case. A creator wants to release a product, but the instance has a rule that you can only do so after two editors - who are not associated with you - verify that your product meets some specified standards. Those editors audit the product through a verifiable process & generate a unique token hash derived from digital artifacts of the product (specifications, photos, the work itself, etc). All of that combines into an endorsement.

@benpate The endorsement is then valid for some period, or indefinitely, as long as the product artifacts continue to be hashable to produce the same token. If not, endorsement is automatically revoked & the product must be re-audited. Any `Flag` raises a first check: does the product - as sold - cohere with the product artifacts? If not, revoke. This also cascades. If editors are found to have a pattern of abuse, _all_ their endorsements are revoked. I'm using this to support networks of trust.

@GavinChait

I *really like* the idea of requiring a certain number of endorsements before allowing a particular action. This could open up a whole new class of workflows that are not possible by just counting "Followers".

Again, HOW you use this may be very domain-specific.

One thought: If the editors publish an `endorses` collection, then the hash/cryptography may not be needed. Their profile simply authenticates that they made the endorsement, and you're off to the races.

@benpate I worked through this a few weeks ago while building the test functionality (python backend). I'll see if I can dig it up and share the JSON-LD I had in mind. Editors don't have to be on the same instance, so this is something that needs to be acceptable across AP instances, with safe fallback.

Yes, it is VERY similar to BadgeFed, and I'm on the BadgeFed matrix talking with everyone about how we can work together.

There are some technical differences that might be good enough reason to keep them separate, for the moment, but I *very much* want to work with the existing structures and standards that we have in place.

@johanna @GavinChait

@johanna

Oh, and the English translation of all the protocol gibberish is:

- I Offer you an Endorsement
- You Accept my Endorsement
- We both tell everybody

After that, us nerds are still figuring out all the fun math we can do with the data.

@GavinChait

I *really like* the idea of requiring a certain number of endorsements before allowing a particular action. This could open up a whole new class of workflows that are not possible by just counting "Followers".

Again, HOW you use this may be very domain-specific.

One thought: If the editors publish an `endorses` collection, then the hash/cryptography may not be needed. Their profile simply authenticates that they made the endorsement, and you're off to the races.

@benpate @GavinChait @ozoned
At the same time, we likely want to avoid the MySpace "Top 8" drama. But just like any currency, if there is some limit, it has value. It has an additional value of making it more difficult for bad actors. Of course, there is no thing stopping a bad server from compromising these rules but
a) They'd have to be very careful about timestamps which could be verified (not impossible but again, harder)
b) They would likely all be to people you don't know so have very little value.

The reason I like Ben's Endorsement proposal is that it's much like "rel=me" links. a simple bidirectional construct that is hard to spoof.

@ramsey
In looking at harm, it's important to look at the simplest "spam" type of attacks e.g. where someone endorses you over and over, even after you say "no". It's pure harassment with no intention of you accepting. Assuming that first "no" shuts down any future requests (or at least mutes them), we should be good.

There are likely other edge cases like this to vet.

@benpate @tchambers

I assumed I would simply Block someone after the first “malicious” endorsement.

But we can certainly add another mechanism into this if we need it.

Is there a subtlety here that Blocks don’t handle?

@scottjenson @ramsey @tchambers

@benpate @ramsey @tchambers
<smacks forehead>
You're right, that's likely simpler. I'm just in the habit of looking for abuse everywhere...

Great that you’re bringing this up. I haven’t really dig deeply into the social pressures people might put into blocks.

A simple fix to the “Top 8” dilemma is to allow a large number of unsorted endorsements. Given humans’ natural “tribes of 100” orientation, 100 or 200 feels good to me.

But there’s more than just this limit - what other social pressures could corrupt someone’s endorsements?

And: can a protocol prevent them?

@scottjenson @GavinChait @ozoned

For engineers and UX designers, this is the right habit to have.

@scottjenson @ramsey @tchambers

@benpate@mastodon.social @scottjenson@social.coop @DePemig@social.coop @thisismissem@hachyderm.io @johannab@cosocial.ca @oli@olifant.social @laurenshof@indieweb.social @wjmaggos@liberal.city @smallcircles@social.coop @GavinChait@wandering.shop @evan@cosocial.ca @iftas@mastodon.iftas.org @tchambers@indieweb.social

This reminds me of human.json. We need more things like this to help us tell humans from hidden bots!

Yes. I didnt know about human.json, but its very similar in spirit. Just translate from IndieWeb -> ActivityPub

Do you know of any prior art that helps quantify the NATURE of a relationship? (In-person, online, coworkers, i admire their music, etc) Thats the next big hurdle I think we’ll need to cross.

@golemwire

@benpate
Well, if we do limit them, we are in effect creating a currency. Although one that most likely has little value to most people. But if you are someone with a lot of followers, those 100 endorsements are worth a lot to some and could turn into a marketplace.

Although to be honest, there's probably going to be a marketplace, even without a limit, for very high-profile individuals no matter what we do?

It appears we're limiting them to prevent gaming the system, which just creates another system to be gamed? Maybe just throttle the rate so bad actors can't inflate their count quickly?

@GavinChait @ozoned

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