As it stands now, Accept, Reject and Undo are identical to activities related to a follow relationship.

I suggest picking more descriptive names for activities:

- OfferEndorsement
- AcceptEndorsement
- RejectEndorsement
- UndoEndorsement

And maybe Endorse should be an object instead of activity? An endorser may want to update the endorsement metadata (content, image, tags).

Hey @silverpill@mitra.social !

I tried to use the existing vocabulary as much as possible. It seems like this fits the existing grammar, does it not?

{
  type:"Offer"
  object: {
    type:"Endorse"
  }
}

Also, Gilles makes a strong point to just use the word "Trust" -- it's simpler and better known around the world. What do you think of that, instead?

I don't know. Why do you want to use the existing vocabulary?

A descriptive activity name leads to a better developer experience:

- You can look at activity and instantly know what action is being performed.
- Servers that implement your FEP don't need to use heuristics, look up object, etc. to figure out what's going on.
- Servers that don't implement your FEP silently ignore unsupported activities, without wasting any resources.

> As it stands now, Accept, Reject and Undo are identical to activities related to a follow relationship.

I disagree, I think using existing vocabulary is superior. You probably already distinguish your logic paths based on the object.

In fact, that this FEP uses a scheme similar to existing Follow relationships makes it easier to adopt.

Ben, I'd even put in a blurb to make note of the similarities, and how they're intentional.

@silverpill@mitra.social @technical-discussion@activitypub.space @benpate@activitypub.space If you are going through the trouble of using your own vocabulary, why not at least make it so that namespace conflicts don't ever happen again, similarly like they do with semantics using AS Vocab now.

If you implement OfferEndorsement and I want to use it as well, but for something incompatible with your thing. Then I guess I need to invent a new less descriptive name for my thing like: NewAPServerOfferEndorsement, if you effectively reserve that name for your thing and depend on that name being unique for handling.

So I think, something like below is a better solution to the same problem, while admittedly looking worse:

• fep-3447:OfferEndorsement
• fep-3447:AcceptEndorsement
• fep-3447:RejectEndorsement
• fep-3447:UndoEndorsement

Or

• fep-3447:Offer
• fep-3447:Accept
• fep-3447:Reject
• fep-3447:Undo

@phnt@fluffytail.org @silverpill@mitra.social look, I'm against JSON-LD as much as the next guy, but isn't that the whole point of JSON-LD — so you don't have to do these contrived naming shenanigans‽

> @silverpill@mitra.social said:
>
> And maybe Endorse should be an object instead of activity? An endorser may want to update the endorsement metadata (content, image, tags).

I agree with this. Offer(Endorsement) sounds better.

@julian@activitypub.space @technical-discussion@activitypub.space @silverpill@mitra.social The point is getting rid of JSON-LD while still getting pseudo-namespaces.

If you wanna use JSON-LD to verify those semantics, you are free to do so, but that is entirely optional.

@phnt@fluffytail.org - how would these semantics be different from the definitions we already have in Activity Vocabulary? And, if the existing Accept and Reject activities aren't meant for this, what are they meant for?

@julian - Since I'm the next guy, we'll have to arm wrestle over who's more against JSON-LD

@phnt@fluffytail.org yeah but I'm also saying you don't need JSON-LD to adequately distinguish between embedded objects. People have been doing it for decades already. No pseudo-namespaces, no JSON-LD

We're already derailing from the main topic at hand perhaps we can both agree JSON-LD is pointless and move on.

@phnt I wouldn't say that introducing a new vocabulary is a trouble (unless you care about JSON-LD, which requires deploying a website every time you invent a property or type)...

But you're right, it's better to use prefixes - I already started doing it in my FEPs. Prefixes could be dropped once a FEP is finalized.

@julian Yeah, the Noun/Object form may be cleaner than Verb/Activity. I don't have a good reason why I chose one over the other. It'll probably change the FEP name and number, but that's not really a big deal.

This also aligns better with Mastodon's existing "Endorsement" objects

@benpate@activitypub.space @technical-discussion@activitypub.space @julian@activitypub.space The point @silverpill@mitra.social is trying to make is that side-effects differ based on the Object an Activity points to. So if you are ingesting an Activity of type Accept, you have to dereference the Object, fetch it or look it up in the DB, check the type of the Object and then decide what to do.

With pseudo-namespaces, you see an Activity type that is unique to an Object type. There is no special handling for each type as it doesn't matter. Depending on how painful implementing new AP types is in your software, using namespaces is cleaner and more obvious. If it's a pain to implement new types in your software,...

@phnt@fluffytail.org This implementation detail is a good point. Thank you for clarifying.

In my own software, I think we're already doing this - dereferencing the "object" of an activity before I route it to the appropriate transaction handler. Given all of the different kinds of activities we have to accept, it seems like this would already be a requirement for any ActivityPub server, yes?

@phnt@fluffytail.org considering the Endorse (or Endorsement) object needs to be resolved anyways as it contains potentially relevant metadata, it seems the "save network requests" argument is moot.

It's not especially hard to add new activity handlers in NodeBB, it's just a personal preference.

@benpate

Also, Gilles makes a strong point to just use the word "Trust" -- it's simpler and better known around the world. What do you think of that, instead?

I prefer "endorse". IMO "trust" is too vague and often used in discussions related to security.
In the user interface, the different flavors of "endorse" could be described using other words.

@benpate @technical-discussion
>Given all of the different kinds of activities we have to accept, it seems like this would already be a requirement for any ActivityPub server, yes?

More or less yes, but that doesn't mean it must be that way forever. Currently Accept/Reject is mostly only for follows for example. Now if I add something like group chat Invites, the two would have completely different side-effects.

I don't really have a preference for one over the other, as the language I would use solves the type check for me via pattern matching. But if it wouldn't, the result would probably include a giant switch/case statement somewhere in the object logic and a plethora of handle_incoming_type_asdf functions for each Activity(Object) variation supported.

The network request point is kinda moot, as you would want to derefence (and fetch) the Object most of the times anyway. At least for me it's about developer experience (clarity), getting rid of JSON-LD while still getting some validation and removing possible semantics conflicts between FEPs and/or different extensions. The last is solved by LD, but I want to get rid of it instead. As a bonus, instances not supporting the extensions will drop it early instead of making requests only to drop the Activity in the end.

Thanks for this. All good points

Add "FEP-8b32 Object Identity Proofs" into the mix, and we may get to skip one of those HTTP lookups. We're going to NEED signatures on endorsements to keep people honest, with the side-benefit of simplifying some network stuff in the meantime.

Can content have some prescribed shape or specific attestations? Or maybe better asked, would I be able to say “I trust Bob for matters pertaining to cooking and carpentry, but not windsurfing” ?