I was thinking about a bunch of systems that I need for different contexts I am in and I came to a thought that many of my needs can be abstracted to somthing like a ticket.
With a Ticket I mean an entry that has a description of an agreement, with a Timeslot when it is to take place and a possible payment
Examples of where this would be needed:
orders of many kinds, for instance food orders in a Cloud Kitchen app
Delivery Package Details, “a package going to X adress, at Y time, for this Z payment”
Tickets for an event, course, festival whatever (description, time of event, payment)
Timeslot at a washroom machine in the apartment building
So what I was wondering is, does it make sense to build this as a module, or is this something that is simply implemented by calling HoloREA straight since this is kind of what it is for (resources, events, agents) agreements and all that.
Still feel like I’d love to see an example of how this kind of implementation of REA might work. Does this make sense? Is it useful to make a module like this outside of REA? @pospi@guillemcordoba any thoughts?
From my perspective its a super nice general primitive - so full endorsements! Prescriptions, cheques etc. I’d be interested in jamming on the idea further as well if you wanted to bounce it. But yeah, curious what the others will say as well!
I suspect the VF modelling would be to describe such “tickets” first as intents, then commitments. In REA’s ontology it would be something like this process:
While the “ticket” is still in planning, it can be modeled as an intent for the ‘main event’ (eg. “deliver the food order”). The “ticket” has not definitely been planned to go ahead at this stage.
As the process comes together, more intents are added and refined by other agents for the other parts of the interaction (eg. “pay for the food”). All the related intents which go together to form the complete interaction are eventually grouped under a proposal and signed off on by all agents involved.
Once the whole proposal decides to go ahead, an agreement may be created in order to bind all agents to the plans they have made together.
Gradually, commitments are created to ‘satisfy’ each intent. Because the providing & receiving agent must be declared for each commitment everybody now knows exactly who must do what. Note also that many commitments may satisfy a single intent, since “deliver 5kg of sprouts” might be fulfilled by 5 different people delivering 1kg of sprouts. And for recordkeeping, commitments may also be associated as a clauseOf any prior agreement.
Commitments, like all flow record types, can have an exact moment in time or a time range. For these records all times are optional such that the time can be pre-known, or not.
Note that there is no distinction between the “payment” resources and the “provided” ones. REA treats them all as generic resource transfers between different pairs of agents.
Finally, one would log corresponding events when each individual step in the exchange is completed. So you would log 1 event to say “food delivered” at the time (or time window) the food came in; another totally separate event to say “payment made” later on. In all cases, the events are said to ‘fulfill’ the associated commitments and ‘satisfy’ the intents. This provides the same layer of indirection as between commitment/intent such that events can partially or over-fulfill the requirements of the network.
Hope that helps a bit… all these record types are available in Holo-REA now except for agreement, and that is a super simple DNA to build (only 1 record type and a few links).
So trying to understand this in some simple way, taking a restaurant order for instance.
As the waiter is at the table, a guest would be creating an intent for a dish (based on a recipe I guess) which would then be input to the kitchen that check to make sure it is available still and then signed directly as a commitment (implicit timeslot of 30min or so)? Also that commitment has a money resource coming from the guest to the restaurant (is this the group agent quandary? Money could be assigned to the waiter to then distribute according to recipe with chefs/owners/etc?).
As guest leaves the restaurant, they sign off to ensure that the economic resource (in this case money) is transferred from them to the restaurant. This would be logged then in the observation layer as a meal (or several dishes independently perhaps) which can be used for generating income statements for the restaurants as well as say expense account entries for the guest?
Does that make sense? If so, what would be needed to be customized to the back-end (datastore/HoloREA) to make this application possible. How much is just getting the right dataformats and GraphQL requests working from the app front end? That is to say, is HoloREA able to store the needed information of a dish (recipie), order and payment as is by using default information structures?
Just FYI, with @hedayat we have begun building a tickets implementation with multi-mutual-credit currency payment, for the next iteration of LeaP and the community currencies app. See the https://forum.holochain.org/t/session-8-virtual-hackalong/3123/2 recording to see more details about that
@ViktorZaunders that seems like pretty vanilla REA to me, and I expect Holo-REA can handle all of that. Another note, you also don’t need to record everything, when your use case seems like it should be simpler than a complete REA treatment, then it probably can. You need what you need.
Wow, I love you guys Had to twinkle-finger the recording it was so good. Loved seeing this just coming together. So cool! And @hedayat I love the way you hold the call. Will try to get to a meeting soon, I will wish for an extra 4hs per day.
For the question on non-redundancy of data for the single person dht of the teacher starting a course, how about teachers inviting others (maybe other teachers for good fun) as non-participant course holders. Basically sending a different ticket, with which a non-participant user is let in but does not get indexed and is like a shadow on the wall? Make sense?
