mirrors/fep
1
0
Fork 0
mirror of https://codeberg.org/fediverse/fep.git synced 2026-08-05 11:46:04 +00:00
Code Packages Wiki Activity

FEP-0837: Update proposal

Browse Source 
- Improve examples of intents, add note on directionality.
- Remove inReplyTo property from Offer activity.
- Improve description of negotiation process.
- Add content property to Reject(Offer) activity.
- Recommend using FEP-0ea0 for payment page link.
This commit is contained in:
silverpill
2023-09-12 06:40:24 +00:00
parent 1e08afb03e
commit cf7be5af6f
1 changed files with 17 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files
fep/0837/fep-0837.md
+17 -14
View File
@@ -39,9 +39,11 @@ The representation of a proposal is a JSON document with the following propertie
**Intents** are proposed economic transactions. The **primary intent** describes what is being offered or requested, and **reciprocal intent** describes what is expected or offered in return. Some examples:
- A good is offered in exchange for money.
- A good is offered as a gift (no reciprocal intent).
- Service is requested in exchange for money.
- A good is offered in exchange for money. Transfer of a good is a primary intent and a money transfer is a reciprocal intent.
- A good is offered as a gift. Transfer of a good is a primary intent and there's no reciprocal intent.
- Service is requested in exchange for money. Delivery of a service is a primary intent and money transfer is a reciprocal intent.
Whether proposal is an offer or a request is determined by the properties of the primary intent (see below).
The representation of an intent is a JSON document with the following properties:
@@ -53,8 +55,8 @@ The representation of an intent is a JSON document with the following properties
- `hasUnit` (REQUIRED): name of the unit, according to [Ontology of units of Measure](http://www.ontology-of-units-of-measure.org/) classification. The RECOMMENDED unit for countable items is `one`.
- `hasNumericalValue` (REQUIRED): amount of the resource.
- `availableQuantity` (OPTIONAL): the quantity of the offered resource currently available.
- `provider`: the actor who provides the resource. This property is REQUIRED for offered resources. If used in primary intent, the value of this property MUST match the value of `attributedTo` property.
- `receiver`: the actor who receives the resource. This property is REQUIRED for requested resources. If used in primary intent, the value of this property MUST match the value of `attributedTo` property.
- `provider`: the actor who provides the resource. This property is REQUIRED for offered resources. If used in the primary intent, the proposal is considered an **offer** and the value of this property MUST match the value of `attributedTo` property.
- `receiver`: the actor who receives the resource. This property is REQUIRED for requested resources. If used in the primary intent, the proposal is considered a **request** and the value of this property MUST match the value of `attributedTo` property.
Example:
@@ -73,7 +75,6 @@ Example:
"unitBased": "vf:unitBased",
"publishes": "vf:publishes",
"reciprocal": "vf:reciprocal",
"resourceClassifiedAs": "vf:resourceClassifiedAs",
"resourceConformsTo": "vf:resourceConformsTo",
"resourceQuantity": "vf:resourceQuantity",
"hasUnit": "om2:hasUnit",
@@ -160,9 +161,7 @@ Consuming implementations which don't have marketplace features MAY display prop
- `satisfies` (REQUIRED): the reference to the intent.
- `resourceQuantity` (REQUIRED): the amount and unit of the economic resource.
To respond to a proposal, an interested party MUST send a `Commitment` object wrapped in `Offer` activity to the actor indicated by the `attributedTo` property of the proposal. This `Commitment` object MUST reference the primary intent of the proposal. It is transient, therefore `id` MAY be omitted. If the value of `unitBased` property of the proposal is `false`, the amount of resource MUST be equal to the amount specified in the primary intent. Otherwise, the amount MUST be a multiple of the amount specified in the primary intent.
`Offer` activity MUST have `inReplyTo` property indicating a proposal for which this activity is considered a response.
To respond to a proposal, an interested party MUST send a `Commitment` object wrapped in `Offer` activity to the actor indicated by the `attributedTo` property of the proposal. The `satisfies` property of this `Commitment` object MUST reference the primary intent of the proposal. It is a transient object, therefore `id` MAY be omitted. If the value of `unitBased` property of the proposal is `false`, the amount of resource MUST be equal to the amount specified in the primary intent. Otherwise, the amount MUST be a multiple of the amount specified in the primary intent.
Example:
@@ -183,7 +182,6 @@ Example:
"type": "Offer",
"id": "https://social.example/objects/fc4af0d2-c3a1-409b-947c-3c5be29f49b0/offer",
"actor": "https://social.example/users/bob",
"inReplyTo": "https://market.example/proposals/ddde9d6f-6f3b-4770-a966-3a18ef006930",
"object": {
"type": "Commitment",
"satisfies": "https://market.example/proposals/ddde9d6f-6f3b-4770-a966-3a18ef006930#primary",
@@ -198,15 +196,17 @@ Example:
## Agreements
Parties negotiate to reach an **agreement**.
After receiving `Offer(Commitment)` activity, the proposing party MUST either commit to action described in the proposal or send a rejection.
In the first case, actor sends `Accept(Offer)` activity back to the interested party.
In the first case, the proposer sends `Accept(Offer)` activity back to the interested party.
In the second case, actor sends `Reject(Offer)` activity.
In the second case, the proposer sends `Reject(Offer)` activity. The interested party MAY send `Offer(Commitment)` activities many times until agreement is reached.
### Accepting a response
The proposing party MUST create an **agreement** that includes commitments corresponding to intents described in the proposal. If a similar agreement between parties already exists, it MAY be updated.
The proposing party MUST create an agreement object that includes commitments corresponding to intents described in the proposal. If a similar agreement between parties already exists, it MAY be updated.
The representation of an agreement is a JSON document with the following properties:
@@ -214,7 +214,7 @@ The representation of an agreement is a JSON document with the following propert
- `type` (REQUIRED): the type of the object MUST be `Agreement`.
- `commitments` (REQUIRED): the list of commitments associated with the agreement. The first commitment MUST satisfy the primary intent of the proposal. The second commitment MUST satisfy the reciprocal intent of the proposal.
- `id` (REQUIRED): the unique global identifier of the commitment. Implementations SHOULD use URL fragments to identify commitments associated with a given agreement. The RECOMMENDED fragment identifiers for commitments satisfying primary and reciprocal intents of the proposal are `primary` and `reciprocal`.
- `url` (OPTIONAL): one or more links to resources associated with the agreement. An example of such resource is unique payment page.
- `url` (OPTIONAL): one or more links to resources associated with the agreement. An example of such resource is unique payment page (which can be represented as FEP-0ea0 link).
The `object` of `Accept` activity MUST be the `id` of the `Offer` activity previously sent to the actor.
@@ -279,6 +279,8 @@ Example:
The `object` of `Reject` activity MUST be the `id` of the `Offer` activity previously sent to the actor.
Activity MAY contain `content` property indicating the reason for rejection.
Example:
```json
@@ -288,6 +290,7 @@ Example:
"id": "https://market.example/activities/8c05f97f-1531-4b70-9ca8-4ee4a09f36a4",
"actor": "https://market.example/users/alice",
"object": "https://social.example/objects/fc4af0d2-c3a1-409b-947c-3c5be29f49b0/offer",
"content": "Not available",
"to": "https://social.example/users/bob"
}
```