Exactly. Either a straight fraction, or with a chosen modifier, like I can send half (or double?) the value I receive. As you wrote, the consuming server decides who and how much to trust, so this would be an advisory for the algorithm only.
@benpate @scottjenson @GavinChait

@benpate@mastodon.social I guess there are two parts... the backend establishing of trust — perhaps the trust score goes up the more content is received... although a case could be made that this ought to be left as an exercise for the implementor...

And the proactive query "do you trust xyz"... might be two FEPs

I'm wary of tossing around Endorse activities, because of all the sync issues endemic to ActivityPub in general, which is why my mind immediately went to some queryable API...

However that's not so much AP <img class="not-responsive emoji" src="https://activitypub.space/assets/plugins/nodebb-plugin-emoji/emoji/android/1f60f.png?v=b232808582d" title="" />

Could you share more of what you mean by "what does it mean if some links in the chain come from a different context?"

I am starting to think we need to enumerate the KIND of endorsement you're getting. And, other limits might be appropriate.

For instance, my college professor might endorse my work within a scope (as a student) for a particular time (< 1 year after finishing the class) but not give me a blanket endorsement in other contexts.

@osma @GavinChait @scottjenson

@benpate @osma @scottjenson that's why I said an attestation is by actors who have defined roles to attest against a specific scope. E.g. I want to publish a novel. Before my instance will permit me to release it for sale, it requires that one editor review it & test to its readiness. The instance attests editors recognised for this purpose, & I will need to ask one of them to read & approve my book. Later, another instance can pose the question: who edited this book, & approved the editor.

@benpate @osma @scottjenson More importantly, if it turns out an editor was attesting plagiarised work, their attestations are subject to the existing `Flag`, & can cascade to all instances where they are authorised & all their attestations revoked.

@julian

All of you are so far ahead of me on this already -- working out how to make this real before I've even made a full FEP. It's awesome.

There MIGHT be a way to query it. We could lean on the proposals for querying collections, and get that done with a minimum of paiin.

But the more data we're talking about, the more likely that I might want some way to sync up ALL of the endorsements across an entire server, to do some kind of big data across them.

What do you think?

If I interpreted that correctly, the ‘Kind’ of an attestation is defined by who the root of the chain is. But unless you encode the chain by its timestamps, there is no root in a directed graph. The editor may be attested as such by the bookstore after they attested your book. They may have an attestation for an entirely different purpose (“great cook”) from someone unrelated to the publishing use case. The consumer may be seeing both, and more.

In order to encode the chain, each attestation would have to refer to the role attestation it is given with. But, as above, they may not be in a clear time order.

@GavinChait @benpate @scottjenson

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

@osma @benpate @GavinChait But there could be 10,000 self-referential links, but I think was Ben's original proposal, that the number is calculated uniquely for me, which is what is the count of your endorsement of people that I know. That number will be unique to every single person. So the 10K gamified account will be a zero to me

I think we're revisiting old ground here. I'm just want to make sure *I'm* not misuderstanding something here. Is it liberating to say "they can have all the self referencial endorsements they want, they will still score zero for me."

@scottjenson @benpate yeah, that's my conclusion. I _need_ attestations for my project - federated collaborative marketplaces can't work without them - but it's complementary to endorsement, not an extension.

@benpate @scottjenson @DePemig @thisismissem @johannab @oli @laurenshof @wjmaggos @smallcircles @GavinChait @iftas @tchambers I added an issue here:

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

It's good to have a collection of activities, also, so you can `Undo` them.

@GavinChait @benpate @osma As a UX designer, I'm a big believer in a tried and true process:
STep 1: Pretend it's magic. Assume have the perfect API (just for now)
Step 2: Design your UX that uses this API. What are the exact steps necessary for everyone to a) Do and b) understand what is happening?

The point being that even with a "perfect API" you can still have problems. I'm suggesting this as a supportive comment, I'd like to see you succeed here and figuring out how this presents itself to the user (even before you figure out the API) almost always returns deep insights.

RE: https://wandering.shop/@GavinChait/116980990601263523

@scottjenson @benpate by the way, I'm currently prototyping my fedi marketplace UI under #hopsauna if you want to follow along. About to start the UI pathway for exactly this: create a product, request an editor, attest for publication, etc...

By reversing the order, the explicit chain becomes clear, at the cost that each attestation is single-purpose and single-use. Meanwhile, endorsement (at least the way I initially understood it) is reusable and doesn’t require reciprocity (I can endorse you, without you having to accept or recognise that endorsement). Are they the same concept in reverse and forward direction?

It’s too late here for me to try to figure that out now.

@GavinChait @benpate @scottjenson

@scottjenson @benpate @osma
I'm a data scientist & usually build horribly complex things (just released https://openlocal.uk). My approach is what you suggest, although my first step is to prototype every complex function to understand exactly what the code requires of the UI. So I've tested about 6 different payment rails, shippo for deliveries, & every type of AS2 jsonld message chain I could think of. I'm not really a designer, so I focus on thinning down complexity when prototyping UI.

I wish I could give you a good answer, but the best I can think of is GPG's (PGP's?) "TOFU" policy thing. The gpg(1) manpage has some docs on its --trust-model option which might spawn some more research.

I added a few more questions. I think this is an interesting piece of work!

@osma @benpate @scottjenson
They're different:
```
{
"@context": ["https://www.w3.org/ns/activitystreams",
"https://hopsauna.com/ns/v1"],
"type": "hop:Attestation",
"id": "https://books.eg/attestations/01J9X",
"attributedTo": "https://books.eg/actors/mara",
"object": "https://books.eg/products/title",
"hop:confers": "hop:approved",
"hop:authorisedBy": "https://books.eg/attestations/01J8K",
"hop:fingerprint": "sha256-9f2a",
"hop:disclosure": "published",
"endTime": "2027-07-28",
"published": "2026-07-28"
}
```