We think of it that the money side would always be the reciprocal side, and that would follow through, not be based on the stage of the conversation. So primary always means “this is why we are doing this”. So even a “request for a service” exists because you want the service. The directionality is determined by the provider vs receiver.
One practical aspect of that way of thinking about it is that in a marketplace, if you are searching for what you are interested in, you shouldn’t have to see the reciprocal intents in your results. Or if there is matching logic between offers and requests, then reciprocal intents wouldn’t be part of that. I suspect our doc needs to be improved there.
Also noting that the reciprocal side won’t always be money, but in any case it will be “not the reason” that the proposal was made.
provider: the actor who provides the resource. This property is REQUIRED for primary intents.
I’m thinking about replacing this with
attributedToproperty on a proposal. This property is needed for transformation into “posts”, but thenproviderandreceivedbecome redundant.
Unfortunately, I think both may be needed, I think of a couple reasons. attributedTo is who posted the message, right? In the case of groups, the user who posted might be different than the provider or receiver, which might be the group, say a bike repair collective. The other reason might be something we need to handle better in VF, which is that the only way we know if it is an offer (from me) vs a request (something I want) is provider vs receiver. We’ve thought about putting offer, request, and maybe other things in the future, as a code in Proposal, but haven’t done it.
I agree that
Offerdoesn’t fit here, but there must be a way to reject the Commitment during negotiation stage. BetweenReject(Create)andReject(Offer), I would pick the latter. Or we can introduce some new activity (e.g.RequestorCommit).
I see your point. Not sure of the best way. Seems like this might be an ongoing kind of question on various AP extensions.
Sometimes
Agreementwill contain additional fields such as payment details, so I think it should be published by the same party who published theProposal.
Yes, got it.
Yes, something like that.
Proposalis needed to initiate a payment that can be tracked by servers.
Maybe this doesn’t matter, or maybe I still don’t understand the workflow, but wouldn’t it be that Agreement is what would initiate a payment? Like, maybe there will be several agreements that result from a proposal. Or, maybe it is at a higher level, like with the actor, who generally might accept a few methods of payment for any of their proposals? Don’t know.