FEP-d767: Extend ActivityPub with Valueflows

Standards Fediverse Enhancement Proposals
, , ,
23

I like this a lot! If any of the following doesn’t seem like something you want to spend time on, then no worries at all, feel free to skip over.

Questions for you:

  1. You don’t want to support many primary Intents or many reciprocal Intents for one Proposal, correct? As in “keep it simple”.
  2. Thinking of “offers” as something I want to provide to someone else as the primary Intent, and “requests” as something I want to receive from someone else as the primary Intent, you want to only support “offers”, right? As in a standard marketplace.

Question in general: Should this FEP be a general marketplace with the workflow you suggested? Or even more generalized, like for timebanks or other exchange use cases that would have Proposals with some follow through? And/or should some of the workflow you are proposing be separate FEPs, like maybe dispute resolution? There’s an in-process discussion here, with a marketplace example here.

Some possible suggestions to consider (but I’m not pushing anything):

  1. An example, maybe I have a bike shop, and I offer (Proposals) repairs for $25 per hour as a service. And I also have a used bike to sell. There is a property unitBased on Proposal, that would differentiate those. The first would be unitBased: true (you can receive however many hours of my service you need, so can others), the second would be unitBased: false meaning there’s only one to sell, then it’s gone. Or you could be selling 4 boxes of apples, and the buyer has to take all of them, it’s not always about being quantity 1.
  2. Or, you have 4 boxes of apples, which could be offered unitBased:true, with the unit being one apple, or the unit being one box. In this case you might want to include availableQuantity so people know there is a limit.
  3. Intent has an image property that is pretty useful when people are offering something that it really helps to see, like a used bike. Also there is imageList for carousel kind of things, but that might be overkill for the fediverse, don’t know.

Then there is an existing VF problem (not your problem) with many-to-many relationships, how to support that cleanly in RDF land, but also in relational/OO land, as we try to be technology agnostic as much as possible. Right now we are basically relational in the “system of record” model, even though it is expressed as a turtle file. So we have “extra” entities to resolve many-to-many relationships, in this case ProposedIntent. I probably fudged that in my examples to you, to not have to add a bunch of explanation. And I know we have to do something about it, possibly having parallel structures; possibly doing it RDF style, with notes on the UML model suggesting how to do in a relational database, don’t know yet, it all just adds complexity to VF - but cleans it up for the fediverse etc. So, I don’t want to muddy your very clean and clear example, so this isn’t to suggest changes, just putting it out there so you know it is an open issue for us. This also came up earlier when @pukkamustard did a simple implementation, and they did something like your example in their experiment.

A question, in case you (or others here) know: How would this be done in general in an RDF standard? Would Proposal reference a list of publishes Intents and a list of reciprocal Intents, and also would Intent reference a list of publishedIn Proposals? And would there be no relational “associative entity”? Thanks if any RDF person has an opinion!

1 Like