I'm playing around with Offer activities in Fedify. The AP Vocab provides this, easy peasy.
✅ Alice OFFERS Book to Bob
✅ Bob ACCEPTS Alice's OFFER
Or:
✅ Bob OFFERS Rotten Tomato to Alice
❌ Alice REJECTS Bob's OFFER
----------------
But I'm not clear if this is right:
❓Alice ANNOUNCES OFFER of Labubu to Followers?
❓Bob OFFERS $10 for Labubu to Alice?
❓ Alice ACCEPTS Bob's OFFER of $10 for Labubu?
✅ Alice OFFERS Labubu to Bob
✅ Bob ACCEPTS Labubu
@smallcircles@social.coop @box464@mastodon.social oh super interesting!
@box464@mastodon.social @smallcircles@social.coop @bhaugen@social.coop @lynnfoster@social.coop
@box464@mastodon.social I think the Announce isn't really needed in the first place, the original Create should allow the object to reach its audience. Also, Offer is an activity, so the first one feels odd. I'd just Create a Note with the details, or some custom object if you want to have it used as a special logic for the frontend, or want to use custom fields for price for instance. Maybe using schema.org's Product (I just find the fact that they use their own Offer type for the price a bit confusing)
Yes. Depending on what you want I'd follow a more design-first approach of the particular domain you want to model. And not shy away from custom types, or better, an existing domain-specific vocab.
On the fediverse there's this urge to try to cram and map any functionality on the poor #ActivityStreams vocabulary, which only has a small number of 'social networking primitives' to work with. The use case section in the spec at par. 5.8.12 states that Offer involves "offering one object to another" which is a very low-level technical ability, more indicating of a protocol capability than for general use as "business domain".
https://www.w3.org/TR/activitystreams-vocabulary/#motivations
In your last scenario "Bidding" seems to indicate the business domain / bounded context, part of perhaps a larger eCommerce toplevel domain. You might use https://eventmodeling.org
Also: who is the actor? You may have an Offer service, and "OfferService announces Alice's offer".
Interesting too: https://offerbots.org/the-problem/
Btw, I added #OfferBots at the end, a (halted) project by Andrew Mackie, that has a very interesting concept for the #ActivityPub fedi. The website describes *very well* the problem with "aggregators" to be addressed, but the solution section of the website is not up to par. It was stopped right at the time when Andrew became aware of the fediverse.
Discussed here on #SocialHub:
https://socialhub.activitypub.rocks/t/offers-unchained-federated-offerbots/697
To just name a well-known existing eCommerce vocabulary: GoodRelations.
http://wiki.goodrelations-vocabulary.org/Cookbook/
Not saying it is appropriate, or the only choice, but just as example. Here you'd have a gr:Offering instead of an as:Offer to indicate "something available for purchase (or bartering)". And there are a bunch of constructs to model payment, delivery methods, etc.
Avoiding the very generic as:Offer has the advantage you convey proper meaning, and don't get to deal with "whack-a-mole" development where you have to adapt your internal business logic to all the overloaded uses some app developer put on the fediverse wire for their own custom as:Offer interpretation :)
@smallcircles@social.coop @box464@mastodon.social @ivan@bonfire.cafe While I think having domain-specific custom types is good, your answers show the problem with that approach, and why Fedi devs try to stick with the existing primitives as much as possible: there are already plenty of vocabularies available, I name schema.org, you named another 3... Which one do we want to use for maximum compatibility? Should everyone trying to make a federated e-commerce software just support vocabulary from 10 different sources because each first-party developer creates their own custom types? That breaks the inter-service compatibility... In that sense, using simpler types from the Activity Streams Vocabulary, and just extending them by adding the wanted properties, makes it a better experience for interoperability.
I think the Social Group behind AP proposals was working on an extended vocabulary spec, I don't know what the status is on that, though.
It is a general problem that comes with interoperability in that there should be some kind of shared consensus on how the domain is modeled. The fediverse developer ecosystem does not facilitate this really. It does not distinguish between core protocol mechanics and domains modeled using the extensibility mechanism.
Instead it follows an opposite approach encouraging devs to just invent it along the way, and then perhaps file a FEP document for further standardization hopefully. This is easy and pragmatic, freeing the dev to start coding a new domain right away. But modeling every domain with a small set of low-level granular primitives comes at a high cost too. Combinatorial explosion of logic to figure out when receiving an AS object. Then protocol decay and tech debt, and whack-a-mole development to catch up to the ever-changing reality on-the-wire, basically doing app-to-app integrations and interop isn't really a thing.
If you look at https://forgefed.org it chose to implement as:Offer in the context of "software development" toplevel domain (or perhaps "code forges" application domain).
Here we may say that it is alright to do so, if its use adheres the informatively specified functionality of "offering one object to another" in that general sense.
Yet I think I'd model this quite differently, and mapping to ActivityStreams is more a disadvantage than anything else. The spec has to describe the combinatorial logic of what to do when receiving as:Offer and needs a 'smart pre-processor' to determine the use case and bounded context.
