@benpate@mastodon.social reading these FEPs and seeing definition of terms always reminds me of reading laws and how things have to be clearly defined. Because communication is so inefficient, especially in text, interpretation is so easy to get incorrect compared to original intent. But it makes new appreciate all the work even more. I absolutely love this idea and greatly appreciate all the work you and others do. Thank you.

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

@ozoned Hey, I’m glad you found this - and sorry I left you off the original list of tags. It wasn’t intentional.

Many of th ActivityPub specs are intentionally vague. There’s power in that, too, but it’s a design decision that has made interop… frustrating.

A lot of the recent additions, and all of the proposals I’m writing, are taking this other approach of spelling things out in very clear terms. Hopefully it helps implementors

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

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

I'm glad you're trying but I'm generally not a fan of adding complexity, esp when most people already can't handle choosing a server.

The fedi I want looks like the web. We'd be able to follow "horrible" people and not get cut off from also following friends and the "best" people on other servers. the problem is norms not tech.

I'm not a bad guy...

https://fba.ryona.agency/?domain=liberal.city

Yeah, it gets complicated really fast

According to one of the listings from your link, they're blocking liberal.city because: "crypto-fascists"

@wjmaggos

Yes. And thank you for reading this

One thing about a *decentralized* trust score is that it is personal - you would get different results than me because you might trust different people (in different domains) than I do.

The draft hints at this, but doesn’t really address use cases yet. I’ll try to make updates, but most implementation will be left up to devs themselves.

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

@benpate @tchambers This reminds me a little bit of PGP’s “web of trust” concept.

Yes. It is exactly that, with extra metadata.

What do you think we could do to: a) improve on this idea, and b) foster adoption around the Fediverse?

@ramsey @tchambers

@benpate @tchambers I’ll need to read the full draft before forming a complete opinion with feedback, but my initial thought process is focused on trying to pick it apart from a cultural aspect: How will people use this? Can they *game* it? Can they use it for harm? etc., etc. I’ll share anything concrete I have.

@benpate I think this is useful, but needs to be calibrated against the trustworthiness of the instance the endorsement is coming from. A well-moderated instance being more trustworthy than one which "isn't". But that then creates a layer of complexity between individual endorsements. However, at the instance level, perhaps a method to tune what endorsement messages will be accepted (i.e. an accept-list, rather than a block-list), and go from there?

@GavinChait @benpate I do not know if I understand this correctly, but I think an app/client would be able to summarize trust for the "trustee" based on how "trusted" their "trusters" are, cascade-wise starting from the observer (you). Something like "This person is trusted by 2 of your first level trustees and by 13 second level trustees."

Such would naturally reflect the trustworthiness of any server or person, from your own perspective.

Theoretically, yes. Setting aside what could become an enormous mathematical challenge, the center point of each person's "web of trust" is themselves, and it branches out in a shape that is unique to them.

This is all public information (and consensually opted-in) so you could (theoretically) get a pretty good sense of a person from their endorsements.

Your online reputation, therefore, becomes what you make it, based on the affects you have on those around you.

@DePemig @GavinChait

@benpate I think this is useful, but needs to be calibrated against the trustworthiness of the instance the endorsement is coming from. A well-moderated instance being more trustworthy than one which "isn't". But that then creates a layer of complexity between individual endorsements. However, at the instance level, perhaps a method to tune what endorsement messages will be accepted (i.e. an accept-list, rather than a block-list), and go from there?

@GavinChait

To your point, Gavin, @ozoned recommended that servers be able to "Endorse" other people or other servers themselves.

If our model assumes an implicit endorsement from me to my server, then *its* endorsements would automatically count as my own 2nd-level endorsements.

So yes, this is going to make some interesting math, and we'll have to recalibrate how to navigate this once real datagets published.

@benpate @ozoned You mentioned bad actors, & we have to be real mindful of this. The old spy novels (Forsythe, Le Carre) used to talk about spycraft of setting up wholly fictitious, but perfectly "real", identities which could be picked up when needed. Entire bureaucracies dedicated to moving paper around to give the impression of a real life. Of course, if you have social media with networks of endorsements ... well, you can automate this.

@benpate @ozoned For hopsauna, I've been thinking about exactly this. Before release, every product must be endorsed by allocated "editors" who review & authorise it. I was going to produce my own namespace term for this, but happy to use yours. However, my implementation was going to be different. An instance "recognises" an editor (an Actor), and the editor is responsible for endorsing a product (also an Actor).

@benpate @ozoned For hopsauna, I've been thinking about exactly this. Before release, every product must be endorsed by allocated "editors" who review & authorise it. I was going to produce my own namespace term for this, but happy to use yours. However, my implementation was going to be different. An instance "recognises" an editor (an Actor), and the editor is responsible for endorsing a product (also an Actor).