I’m wondering about this question because I’d like to have a “Product” type for my object in shops.
in shops, an item represents a listing for sales, so naturally, this object isn’t of type “Note” or “Article” (although Article “might” be close enough i could use for implementation).
If i make item to be of type “Note”, it’s going to show up on mastodon or other microblog platform. i feel like it’s going to pollute the social platform, also users might want to have more control on what they prefer to render depends on the user’s primary intent.
another different way of thinking about this idea of adding a new subtype comes from user’s intend, meaning a user is more aligned to the concept of Activity type itself than Object. because the user is intended to perform an action with intent to either Subscribe, Offer, or whatever, etc.
im not sure which is the better way to achieve this, my goal is still to have a mechanism where end users can use the fediverse platform with better control, especially when trying to buy / sell things.
Not that I am particularly aware of. But there are 2 online marketplaces fedi apps to take inspiration from and keep in mind to perhaps interoperate with..
Hi @sir , you are the same as @potato, right, we discussed earlier?
Are you interested in exploring using FEP-0837 instead of adding a new Product subclass?
I wonder if the Valueflows structure seemed too complicated? I’m happy to spend some time to see if we can make it work for you, and keep the AP economic standard extensions to a minimum. I’ll take a look when you answer @silverpill ‘s question about Product properties, and see how they map. If you are interested, of course!
P.S. Sorry to miss the last 2 weeks of conversation, I was traveling to visit family (new grandson!), couldn’t keep up.
yes i am! (sry for the confusion) and yes, i think 0837 is interesting (more interesting than my Product idea). huh… maybe you can teach me how to achieve a scenario i’ve been thinking to implement.
so i have this scenario where i want to make sure sysadmin being paid, and im not experienced with valueflow enough to understand how i can make the negotiation work.
scenario
alice: i want to buy a burger from bob. im from @alice@buyer.com
bob: sure. 1 burger is $2. im from @bob@seller.com
alice publishes a proposal. the intend is for this proposal is to buy a burger from bob while paying some server fee to alice’s sysadmin (to support electricity, domain, other costs, etc.)
(let’s call alice’s sysadmin sid, for now)
now this is where i’m stuck and need some help @lynnfoster .
so from what i understand, bob can send an offer to alice, great.
but can sid also send an offer to alice so that alice’s total payment can account for the costs of both the burger and the server fee???
well… a part of the reasons why i want to add a Product subtype into Object was because i want a way to differentiate the intent of an activity as well as the type of an item. so i think if there is a way i can make it happen with valueflow. it’ll be very nice.
I’m thinking about what you said. This will be a partial reply.
So one thing is that Valueflows does support multiple primary intents and/or reciprocal intents as part of one proposal. If they are multiple, an “and” is assumes, i.e. if alice is paying for a burger and a service fee, that is 2 intents, both of which must be paid to get the burger. (Each intent is one resource flow.) That isn’t explicitly defined in the FEP-0837 though, which is meant to be somewhat basic for a marketplace. @silverpill do you have thoughts about this?
But also I’m a bit confused. I think of a service fee as something that also is basically related to the main transaction, and affects both parties. I.e. if bob wanted $2 for a burger, and $n for a service fee for bob’s sysadmin, that makes sense to me. This often happens with shipping. If alice is giving her sysadmin a service fee, and bob isn’t involved / doesn’t care / doesn’t even know about it, that seems separate to me, and just between alice and alice’s sysadmin, a separate thing.
I think I also have to sort out some things about offers vs requests, but not tonight.
But also I’m a bit confused. I think of a service fee as something that also is basically related to the main transaction, and affects both parties. I.e. if bob wanted $2 for a burger, and $n for a service fee for bob’s sysadmin, that makes sense to me. This often happens with shipping. If alice is giving her sysadmin a service fee, and bob isn’t involved / doesn’t care / doesn’t even know about it, that seems separate to me, and just between alice and alice’s sysadmin, a separate thing.
yah, this is the same path i was thinking about. originally, i designed the server fee component to be tied to both alice & bob. but that didn’t seem to be a viable when they each come from different server instances, which led me to pick either alice’s sysadmin or bob’s sysadmin to be the sole recipient of the server fee.
but the idea of having a sole recipient in terms of server fee doesn’t make much sense in a federated marketplace, because it can lead to 1 sysadmin be better off than the other. which isn’t fair since both sysadmin contribute their work & time in maintenance and hosting. in the long run, this setup could lead to centralization because its financial incentive structure is not balanced or “decentralized”.
ultimately, my goal is to make sure fediverse marketplace can “somehow” grow together more fairly, than favoring any particular party in server fee incentive.
so i opt for the idea of alice paying her own sysadmin, while bob paying his own sysadmin when buying things in a federated marketplace.
also after talking about this out… i do realize i can happily implement valueflow without my “server fee” idea, at least for the time being.
in the long run, server fee is important to my design.
In relation to “Avoid Misconception” I just posted: This FEP should not have been accepted with this title. Besides not capitalized in line with other FEP’s it is unclear what “add product type to object” means..
I want to extend ActivityStreams with Product so it will be broadly supported (assuming this is not about Object.productType).
I want to formalize an extension to AP for doing product exchange (either app-specific or standards-driven extension).
Stackoverflow question: How can I extend AP with a Product type that is relevant to my app? No FEP needed, but good extensibility best-practices should be followed (but aren’t well-defined).
interesting… from what i can see in the extended object type, Activity Vocabulary some of them are a little app specific, i.e. Note vs Article
my fep is indeed app specific too, especially the way how i call it Productatm. i currently have no idea how to make things more generic.
i think another way to look at it from implementer side is to “guess” a type as long as it’s “close enough”. it’s kinda back to the duck typing idea again, aka. “if it looks like a Note, then the app will attempt to render it like a Note.”
I still think that FEP-0837 should only cover the basics (it is already too long for my tastes). But I can add a note saying that proposals can have multiple primary or reciprocal intents.
We could wait until we know for sure it is needed, if you like. Up to you, I do understand about keeping out extra complexity. (I hope this conversation will end with some more understanding from @sir on what they want to do, and that will help us?)
I agree Product is generic enough. It is defined in schema.org as “Any offered product or service. For example: a pair of shoes; a concert ticket; the rental of a car; a haircut; or an episode of a TV show streamed online.” It is not immediately clear if it is a product type or an actual product or both, but I probably didn’t read deeply enough. Although schema.org is made by and for big e-commerce, which leads me to think it is a product type.
Valueflows is more broad/generic, a product type is a Resource Specification, an existing product is an Economic Resource. Valueflows is meant to support more than marketplaces, including coordinating production or creative work, delivering services, accounting for externalities, etc, i.e. the ability to reflect whole economic ecosystems. So if that is a direction that people want, then it is good to have marketplaces as part of that so everything connects. Then for example you could look at something in a marketplace, and click to see what went into making and transporting that something, both good and bad (if that data was recorded of course). This is the idea behind the European Digital Product Passport, for example.
On the other hand, Valueflows just went to a stable 1.0.0 and is mostly emerging in the world of economic experiments that are better than what we have (although it works for conventional economic activity); schema.org is everywhere in e-commerce. So we have choices. (Although please don’t queue the standards joke! We wouldn’t have done Valueflows if we thought existing vocabularies would work for where we need to go. But we seriously do have actual choices with many tradeoffs.)
).
We wouldn’t have done Valueflows if we thought existing vocabularies would work for where we need to go. But we seriously do have actual choices with many tradeoffs.)