FEP-0837: Federated Marketplace

Updating the proposal: #318 - FEP-0837: Support donations - fediverse/fep - Codeberg.org

Following the discussion in another topic, arbitrary quantities has been allowed to support donations. I also added a sequence diagram (can be previewed at feps/0837/fep-0837.md at main - silverpill/feps - Codeberg.org).

1 Like

Update: #620 - FEP-0837: Update proposal - fediverse/fep - Codeberg.org

I added a context file for FEP-888d, now we can do this:

"@context": [
  "https://www.w3.org/ns/activitystreams",
  "https://w3id.org/fep/0837"
]

Plus some purely editorial changes.

2 Likes

@lynnfoster Is there a recommended property for indicating the “status” of an Agreement? Suppose it is completed in N stages:

  1. Agreement created
  2. Stage 1 completed.
  3. 

  4. Stage N completed.
  5. Exchange fully completed, agreement closed.

I’d like to send an activity every time a stage is completed. Preferably an Update:

{
  "type": "Update",
  "object": {
    "type": "Agreement",
    "stipulates": "..."
    "status": "Stage 2 completed"
  }
}

By the way: the link to rules definition is not working in https://www.valueflo.ws/specification/all_vf.html#Agreement

Thanks @silverpill !

There isn’t a status on Agreement. The thinking is you can derive the nuances of that by looking at the Commitments and fulfilling EconomicEvents, plus finished flags.

Are you thinking that will be useful while the Agreement is being negotiated, or while it is being fulfilled, or both?

And are you thinking free-form text?

Anyhow, if you would like a status, we can add it to the FEP, and see how it goes for people. Or even just add it to any app that wants it. We wouldn’t add it to VF without some actual use to test it out.

P.S. The rules link certainly is not working, thanks!

1 Like

I think it may be useful in both cases, but right now I am interested in providing progress indicators for the fulfillment phase.

I think it might also be a structured data, i.e. an object with multiple properties.

1 Like

Maybe it will be preview:

{
  "type": "Agreement",
  "preview": {
    "type": "Note",
    "name": "Stage 2 completed"
  }
}

Let’s think about what statuses might be useful.

What there is right now in VF:

  • While people are creating the Agreement, there isn’t really anything. In my experience, people create them basically all at once, so the Agreement and all Commitments. (like Alice transfer 1 used bike to Bob, Bob transfer $20 to Alice) You wouldn’t see just one of those commitments out there during this process (it’s a unit of work) - but there’s nothing saying it has to happen that way.
  • Once an EconomicEvent has been recorded as fulfilling a Commitment, then the Agreement is in progress.
  • When a Commitment is marked finished then nothing more is expected on that Commitment (although it doesn’t mean that the Commitment was completely fulfilled).
  • When all Commitments are marked finished then the Agreement is complete (again doesn’t mean everything was fulfilled as expected, but you can see what was fulfilled).

Sounds like you are thinking a user-defined status? I don’t have experience with preview but it sounds different. Would that persist as a status, or be more for an immediate display on a message? Or I could see where you might be going with something like a note update that you want to communicate, like “Almost ready to send, should be in the next couple days”. But maybe that is just the already proposed blend of social (AS) and economic (VF) communications?

Should we also think about more defined states that might be needed?

An exchange is rarely atomic, payments and deliveries often take time and may consist of multiple steps. These steps vary depending on the use case.

For now I just need a progress indication mechanism for my application (not for the FEP). preview is different but it’s close enough and I don’t want to introduce a new property.

1 Like

Ah you’re writing something, looking forward to that!

>An exchange is rarely atomic, payments and deliveries often take time and may consist of multiple steps. These steps vary depending on the use case.

Very true.

1 Like

Introducing minimumQuantity: #693 - FEP-0837: minimumQuantity - fediverse/fep - Codeberg.org

The “Implementations” section now includes Mitra (it’s not a new one, I implemented federated payments there at the same time this proposal was published).

2 Likes

One thing that I don’t like about FEP-0837 is how resources are described. Currently we describe them using the resourceConformsTo property, which value is an URI.

In the Proposal example, the primary intent is “bicycle” (https://www.wikidata.org/wiki/Q11442) and the reciprocal intent is “US dollar” (https://www.wikidata.org/wiki/Q4917).

I think implementers may want to point to an ActivityPub object, such as Image representing a bicycle, instead of a Wikidata page.

@lynnfoster can we use resourceConformsTo for this? Maybe there is a better property?

I agree. Here are some other options for Intent resource-related properties: name, image, imageList, note (sort of a duplicate of the as:content above but could have a detailed discription of the resource), resourceClassifiedAs. Offers/requests are the loosest and least understood as regards identifying resources. Some mutual aid kinds of apps just have a description and that’s it. I also do think an image would be good.

To at least partially clarify resourceConformsTo and resourceClassifiedAs, the first refers to the lowest level resource type needed to completely identify the resource in the use case, which might be more like “Schwinn bicycle model xyz123 blue” (or not). Using wikidata is misleading, which is our fault, as we use that as shorthand in VF examples. resourceConformsTo points to ResourceSpecification, which is actually defined within VF, so might not even be a uri. Wikidata could be more appropriate for resourceClassifiedAs, which for offers/requests could use an agreed upon taxonomy or set of categories for matching/search, or just tags, pretty loose depending on the app, and can be multiple. But still, it depends on the use case, and we don’t have a good understanding yet of the formality that people will want to coordinate their resource specifications (resourceConformsTo) across networks or the public, even just limited to marketplace type apps.

1 Like

i think i was describing my simple interpretation of my VF. (i didn’t know what VF was, and i’m still trying to catch up on the whole economicEvent of VF atm)

the comment i had was basically trying to keep a copy of the object of the proposal activity to the Night to the appropriate copy of THE.

this copy of the object is intended to be frozen in time at the creation of the proposal activity to avoid race condition.

anyhow
 let me read more about VF


1 Like

The work has started on adding FEP-0837 types and properties to Fedify:

2 Likes

I’d like to update the recommendations related to representation of amounts. Currently we have this:

  • hasUnit (REQUIRED): name of the unit, according to Ontology of units of Measure classification. The RECOMMENDED unit for countable items is one.
  • hasNumericalValue (OPTIONAL): the amount of the resource. If not specified, arbitrary amounts can be used when responding to the proposal.
  1. The one unit is not a good fit for currency amounts. @lynnfoster, what are the alternatives? I found “amount of money”, is it supposed to be a unit label, e.g. "hasUnit": "amount of money"?

  2. hasNumericalValue is a string in all FEP-0837 examples, but this is not a requirement. I want to make serialization into decimal string mandatory, because JSON numbers should not be used for currency amounts.

1 Like

Thanks @silverpill , good issues.

Agree, it’s not great. Apologies for the following lengthy kludge, if that is too much, I’ll try again.

The “amount of money” looks like it sits in a different part of their model than the units, i.e. it is a quantity, not a unit. OM2 has defined a bunch of fiat currencies as units, as have some other unit of measure vocabs. Quite awhile back, VF decided not to do that, after some long discussion. Partly this is general semantics, but specifically also (IIRC) because units have basically defined permanently in relation to each other, vs currencies which have fast moving conversion rates, and also units tend to be pretty fixed and long-lived, gathered into vocabularies, while people invent alt and local currencies all the time. Different behaviors, although one as a currency requires some different behaviors too, on the UI. So we ended up with currencies as ResourceSpecifications. Anyhow, I’m pretty sure it is not worth asking OM2 for a new unit, since they have the individual currencies defined already. Maybe we just make up one that we recommend people use when using VF? Maybe we could add a subproperty (or whatever is correct) of one to VF, amountOfMoney isn’t bad. Do you not like one because it feels like an integer? (QUDT, the other vocab we had under consideration, calls it number. Both are the “one dimensional unit”.) Side note: In fact, one doesn’t work cleanly for other business uses very well either, like “each”, “count”, etc. I have asked for those in OM2, and got turned down, very politely, didn’t pursue.

Related note: We have label and symbol on vf:Unit, which override those properties coming from OM2. Lots of the unit labels need to be clarified and simplified for user groups, beyond currencies.

I wish this weren’t so complex, a downside of using another very thorough vocab for something simple to us.

I think whatever is best for the technology is good. Will decimal string also work for other hasNumericalValue situations? It is used on all quantities, whether currency or weight or volumes or time or whatever needed for material things, energy, work, etc. Seems OK to me, but thought I better ask that.

Related, I’m wondering if we should have hasNumericalValue as an optional field when part of a quantity? We do have a couple default units on ResourceSpecification, defaultUnitOfResource and defaultUntiOfEffort. I’d need to look more carefully at your examples before doing more than wondering.

1 Like

Sounds good. currencyAmount would work too.

Yes.

I think there should be different units for items and currencies.

Yes, I think it should always be a decimal string.

It’s already optional:

hasNumericalValue (OPTIONAL): the amount of the resource. If not specified, arbitrary amounts can be used when responding to the proposal.

1 Like

That seems good. I don’t want to formally define that in VF until we’ve tried it out, but we can just define it in the FEP, and include in the examples. And I’ll start an issue in VF.

:+1:

Sorry, I meant maybe it shouldn’t be optional, and we use another way to define the suggested or defined unit. But I’m OK leaving it as is too, and we see how it goes, that was off topic anyhow.

I added currencyAmount to examples (without formally defining it, for now): https://codeberg.org/fediverse/fep/pulls/799.

Also, I realized that the minimal example of a Proposal is not useful because it doesn’t contain enough information. I made resourceConformsTo property required to address that.

On a related note,

Can we use resource? It could point to a Product object (FEP-c07e).

@silverpill I happened to run into a unit of measure vocab from the UN, which has a lot of the “business” units that the scientific unit vocabs don’t have. Still investigating, and thinking about how to possibly incorporate it at this point.

>Currently we describe them using the resourceConformsTo property, which value is an URI. Can we use resource? It could point to a Product object (FEP-c07e).

I think resource is confusing because you don’t know it is a resource type.

But, actually the VF spec says resourceConformsTo points to a ResourceSpecification. I don’t remember how we got the URI in there, maybe our examples are confusing things. Or maybe we have some unclarity in VF because sometimes these definitions will be at some point in some workflows found out on the web. Formatted Specification - Valueflows

1 Like