Holo Demo Scenario

[fosterlynn]

@sqykly is working on a "good first demo" in Holochain. Here is the rough scenario:

A cast of agents:
-- Al, who runs "Al's Apple Farm".
-- Bea, who runs "Bea's Beans".
-- Chloe, who runs "Cloe's Coffee".

The story:
-- Al has picked 100 apples.
-- Bea has gathered 2 kg of beans.
-- Chloe owns 300 mL of coffee (beginning balance).
-- At that exact moment, Al arrives with 3 apples. He gives them to Chloe, Chloe receives them.
-- In exchange, Chloe gives Al a 300 mL cup of coffee. Al receives it.
-- Chloe consumes 3 apples to bake 1 turnover.
-- Bea wants the 1 turnover in exchange for 1/2 kg of her beans. See above for how that works.
-- Chloe consumes those beans to brew 1000 mL of coffee

The idea for the demo is to enter the data at each step and be able to see inventory (or a primitive balance sheet) for each agent at each step.

I'd like to define this out in more detail here. Partly this is to contribute to the current discussions on transfers. Partly this is to better define this scenario in VF terms with expected outputs.

Al has picked 100 apples.

Process:
-- id: 123
-- name: Pick apples
EconomicEvent:
-- id: 1
-- action: produce
-- outputOf: Process 123
-- provider: Al
-- receiver: Al
-- affectedQuantity:
---- numericValue: 100
---- unit: Count
-- observedTime: 2018-10-10
-- affects: EconomicResource 1
EconomicResource:
-- id: 1
-- resourceClassifiedAs: Apple
-- currentQuantity:
---- numericValue: 100
---- unit: Count

Bea has gathered 2 kg of beans.

Process:
-- id: 456
-- name: Gather coffee beans
EconomicEvent:
-- id: 5
-- action: produce
-- outputOf: Process 456
-- provider: Bea
-- receiver: Bea
-- affectedQuantity:
---- numericValue: 2
---- unit: kg
-- observedTime: 2018-11-11
-- affects: EconomicResource 5
EconomicResource:
-- id: 5
-- resourceClassifiedAs: Coffee beans
-- currentQuantity:
---- numericValue: 2
---- unit: kg

Chloe owns 300 mL of coffee (beginning balance).

EconomicEvent:
-- id: 10
-- action: adjust
-- provider: Cloe
-- receiver: Cloe
-- affectedQuantity:
---- numericValue: 300
---- unit: mL
-- observedTime: 2018-11-20
-- affects: EconomicResource 10
EconomicResource:
-- id: 10
-- resourceClassifiedAs: Coffee
-- currentQuantity:
---- numericValue: 300
---- unit: mL

Inventory

Al: 100 Apple
Bea: 2 kg Coffee beans
Cloe: 300 mL Coffee

Al arrives with 3 apples. He gives them to Chloe, Chloe receives them.

Transfer:
-- id: 2
EconomicEvent:
-- id: 30
-- action: give
-- provider: Al
-- receiver: Cloe
-- affectedQuantity:
---- numericValue: 3
---- unit: Count
-- observedTime: 2018-11-20
-- affects: EconomicResource 1 (currentQuantity now 97)
-- inputOf: Transfer 2
EconomicEvent:
-- id: 31
-- action: receive
-- provider: Al
-- receiver: Cloe
-- affectedQuantity:
---- numericValue: 3
---- unit: Count
-- observedTime: 2018-11-20
-- affects: EconomicResource 30
-- outputOf: Transfer 2
EconomicResource:
-- id: 30
-- resourceClassifiedAs: Apple
-- currentQuantity:
---- numericValue: 3
---- unit: Count

Inventory

Al: 97 Apple
Bea: 2 kg Coffee beans
Cloe: 300 mL Coffee, 3 Apple

Chloe gives Al a 300 mL cup of coffee. Al receives it.

Transfer:
-- id: 3
EconomicEvent:
-- id: 33
-- action: give
-- provider: Cloe
-- receiver: Al
-- affectedQuantity:
---- numericValue: 300
---- unit: mL
-- observedTime: 2018-11-20
-- affects: EconomicResource 10 (currentQuantity now 0)
-- inputOf: Transfer 3
EconomicEvent:
-- id: 34
-- action: receive
-- provider: Cloe
-- receiver: Al
-- affectedQuantity:
---- numericValue: 300
---- unit: mL
-- observedTime: 2018-11-20
-- affects: EconomicResource 34
-- outputOf: Transfer 3
EconomicResource:
-- id: 34
-- resourceClassifiedAs: Coffee
-- currentQuantity:
---- numericValue: 300
---- unit: mL

Inventory

Al: 97 Apple, 300 mL Coffee
Bea: 2 kg Coffee beans
Cloe: 0 mL Coffee, 3 Apple

Chloe consumes 3 apples to bake 1 turnover

Process:
-- id: 789
-- name: Bake turnover
EconomicEvent:
-- id: 50
-- action: consume
-- inputOf: Process 789
-- provider: Cloe
-- receiver: Cloe
-- affectedQuantity:
---- numericValue: 3
---- unit: Count
-- observedTime: 2018-12-01
-- affects: EconomicResource 30 (currentQuantity now 0)
EconomicEvent:
-- id: 51
-- action: produce
-- outputOf: Process 789
-- provider: Cloe
-- receiver: Cloe
-- affectedQuantity:
---- numericValue: 1
---- unit: Count
-- observedTime: 2018-12-01
-- affects: EconomicResource 55
EconomicResource:
-- id: 55
-- resourceClassifiedAs: Apple turnover
-- currentQuantity:
---- numericValue: 1
---- unit: Count

Inventory

Al: 97 Apple, 300 mL Coffee
Bea: 2 kg Coffee beans
Cloe: 0 mL Coffee, 0 Apple, 1 Apple turnover

Cloe gives Bea the 1 turnover

Transfer:
-- id: 5
EconomicEvent:
-- id: 60
-- action: give
-- provider: Cloe
-- receiver: Bea
-- affectedQuantity:
---- numericValue: 1
---- unit: Count
-- observedTime: 2018-12-02
-- affects: EconomicResource 55 (currentQuantity now 0)
-- inputOf: Transfer 5
EconomicEvent:
-- id: 61
-- action: receive
-- provider: Cloe
-- receiver: Bea
-- affectedQuantity:
---- numericValue: 1
---- unit: Count
-- observedTime: 2018-12-02
-- affects: EconomicResource 60
-- outputOf: Transfer 5
EconomicResource:
-- id: 60
-- resourceClassifiedAs: Apple turnover
-- currentQuantity:
---- numericValue: 1
---- unit: Count

Bea gives Cloe 1/2 kg of her beans

Transfer:
-- id: 5
EconomicEvent:
-- id: 60
-- action: give
-- provider: Bea
-- receiver: Cloe
-- affectedQuantity:
---- numericValue: .5
---- unit: kg
-- observedTime: 2018-12-02
-- affects: EconomicResource 5 (currentQuantity now 1.5)
-- inputOf: Transfer 5
EconomicEvent:
-- id: 61
-- action: receive
-- provider: Cloe
-- receiver: Bea
-- affectedQuantity:
---- numericValue: 1
---- unit: Count
-- observedTime: 2018-12-02
-- affects: EconomicResource 60
-- outputOf: Transfer 5
EconomicResource:
-- id: 60
-- resourceClassifiedAs: Coffee beans
-- currentQuantity:
---- numericValue: .5
---- unit: kg

Inventory

Al: 97 Apple, 300 mL Coffee
Bea: 1.5 kg Coffee beans, 1 Apple turnover
Cloe: 0 mL Coffee, 0 Apple, 0 Apple turnover, .5 kg Coffee beans

Chloe consumes those beans to brew 1000 mL of coffee

Process:
-- id: 987
-- name: Brew coffee
EconomicEvent:
-- id: 70
-- action: consume
-- inputOf: Process 987
-- provider: Cloe
-- receiver: Cloe
-- affectedQuantity:
---- numericValue: .5
---- unit: kg
-- observedTime: 2018-12-15
-- affects: EconomicResource 60 (currentQuantity now 0)
EconomicEvent:
-- id: 71
-- action: produce
-- outputOf: Process 987
-- provider: Cloe
-- receiver: Cloe
-- affectedQuantity:
---- numericValue: 1000
---- unit: mL
-- observedTime: 2018-12-15
-- affects: EconomicResource 10 (currentQuantity now 1000)

Inventory

Al: 97 Apple, 300 mL Coffee
Bea: 1.5 kg Coffee beans, 1 Apple turnover
Cloe: 1000 mL Coffee, 0 Apple, 0 Apple turnover, 0 kg Coffee beans

[elf-pavlik]

-- action: adjust

I would suggest to start with already existing vf:increment and later make PR which would propose different way to increment and decrement and explaining need for it.

The idea for the demo is to enter the data at each step and be able to see inventory (or a primitive balance sheet) for each agent at each step.

For that requirement example doesn't require using any instance of vf:Transfer. Just the events allow to see the quantities in inventory. Introducing vf:Transfer seems only needed if one has additional requirement to track which decrement in one resource relates to increment on another resource (where resources have the same classifications).

Actually given the minimal requirement proposed, one doesn't have to use any instance of vf:Process as well. It only comes needed where one has requirement to track how decrements on resources, use and work result in increments on other resources (where input and output resources have the same classification).

Once additional tracking requirements get added, one can also notice that one will get the same result after

• replacing every instance of vf:Transfer with an instance of vf:Process
• replacing every instance of vf:give with an instance of vf:load
• replacing every instance of vf:receive with an instance of vf:unload

Now even with just initial 'inventory snapshots' requirement application should still work the same way when it processes data with changes I suggest above. For that one has to adjust quantities based on vf:decrement and vf:increment actions and handle any sub property of them the same way.

I also would like to notice that example above seems to use Transfer as Teleportation, and for that reason it should behave exactly the same way as if Transportation gets recorded. I don't see any specific rights and responsibilities management here, just teleporting quantity between two different resources.

Given very limited initial requirement, I would suggest to avoid distracting oneself with any Process / Transfer aspects and focus on proper implementation of events and defined actions. It may also come very helpful that each agent records events on resources they control. I find it more straight forward than who would record the 'Transfer' or 'Agreement' entry. In #383 I actually used 3rd party with https:/notary.example namespace to record the agreement and most likely also syndicate all the flows under it created in namespaces of involved parties.

Meanwhile I hope we'll clean up issues related to Process (including transportation and transfer) and Agreement.

[bhaugen]

@elf-pavlik

I don't see any specific rights and responsibilities management here, just teleporting quantity between two different resources.

This is all about transfers of ownership, which will be interesting to this audience. They are also interested in how we can do conventional accounting, so the demo will present mini balance sheets after every transfer of resources. And balance sheets are all about assets ( = ownership or what some other agent owes you) and liabilities ( = what you owe ).

Lynn also wants to do a mini incoming value flows traversal, which she can describe (and which I will work on detailing tomorrow).

[fosterlynn]

-- action: adjust

I would suggest to start with already existing vf:increment and later make PR which would propose different way to increment and decrement and explaining need for it.

I forgot we don't have adjust. I'll make a PR. vf:increment won't work, it is not always an increment. The 2 use cases are beginning balances and inventory counts that need to override what the system is showing.

Lynn also wants to do a mini incoming value flows traversal,

Yes, that is my hope. But also I felt it was important to have the value flows in the code and data examples for this demo because there will be devs and others interested in the detail of how REA/VF works. Processes and transfers are needed for that, as well as to just make it clear what is actually going on.

[sqykly]

-- action: adjust

I would suggest to start with already existing vf:increment and later make PR which would propose different way to increment and decrement and explaining need for it.

I actually started with give/receive from a fourth omnipotent Agent, David. Technically he is still there. What is the difference between adjust and increment, as you see it, that makes increment more appropriate?

For that requirement example doesn't require using any instance of vf:Transfer. Just the events allow to see the quantities in inventory. Introducing vf:Transfer seems only needed if one has additional requirement to track which decrement in one resource relates to increment on another resource (where resources have the same classifications).

Actually given the minimal requirement proposed, one doesn't have to use any instance of vf:Process as well. It only comes needed where one has requirement to track how decrements on resources, use and work result in increments on other resources (where input and output resources have the same classification).

That is exactly why I didn't include any of that initially. The Events are the only part truly necessary to calculate the inventories. However, we are concerned that will look like "faking" REA, not truly modelling the system. Whether or not we use the Process and Transfer capabilities, we want them to be there to ensure that anyone poking around can legitimately envision how they might be added.

Once additional tracking requirements get added, one can also notice that one will get the same result after

* replacing every instance of `vf:Transfer` with an instance of `vf:Process`

* replacing every instance of `vf:give` with an instance of `vf:load`

* replacing every instance of `vf:receive` with an instance of `vf:unload`

Funny story. In order to make TypeScript believe that Events could have either a Transfer or a Process despite their lack of a common interface (internally, inputs and outputs are very different in HoloREA), I added a wrapper, EconomicFunction, that does a pretty good job at both for identifying and traversing. There's no way to get one from the web API, so there's no need to worry about standardizing it. But, in absence of semantics, and disregarding the fact that they name their classifications differently, Transfer could easily be a superclass of Process. The difference appears, to me, to be semantic.

I also would like to notice that example above seems to use Transfer as Teleportation, and for that reason it should behave exactly the same way as if Transportation gets recorded. I don't see any specific rights and responsibilities management here, just teleporting quantity between two different resources.

I wish the current VF carried sufficient information to do such management. I've been asking about expanding the classification classes to direct those flows for a long time.

Given very limited initial requirement, I would suggest to avoid distracting oneself with any Process / Transfer aspects and focus on proper implementation of events and defined actions. It may also come very helpful that each agent records events on resources they control. I find it more straight forward than who would record the 'Transfer' or 'Agreement' entry. In #383 I actually used 3rd party with https:/notary.example namespace to record the agreement and most likely also syndicate all the flows under it created in namespaces of involved parties.

Too late.

[fosterlynn]

Hey @sqykly welcome to the land of VF! Great to see you participating here!

What is the difference between adjust and increment, as you see it, that makes increment more appropriate?

Funny story. I had forgotten we didn't have adjust, so I made a PR today. But I ended up liking increment and decrement better than adjust for VF, mostly because I didn't want to have a negative quantity when we already have increment and decrement behavior... and I couldn't think of good one-word action verbs for adjust-up and adjust-down. If we could think of those verbs, I'd rather use them because they would be more specific and clear. I don't think @elf-pavlik has had a chance to respond to that PR yet. valueflows/valueflows#389

Funny story. In order to make TypeScript believe that Events could have either a Transfer or a Process despite their lack of a common interface (internally, inputs and outputs are very different in HoloREA), I added a wrapper, EconomicFunction, that does a pretty good job at both for identifying and traversing.

Actually, I'd like to explore a superclass for Transfer and Process for the vocab. We have thought about it off and on, but nothing like a little experience writing code to clarify things. Perhaps one for EconomicEvent, Commitment, and Intent too, but you haven't run into that one yet @sqykly .

Also a bit of context: right now @elf-pavlik and I are doing a big re-visitation of the validity of the concept of Transfer that is not anything close to being resolved. Sorry if that is confusing. In general, I think we can expect there to be wobbles in VF for some time, especially as more user groups use it. Mostly those wobbles will be around the edges. The concept of transfer is pretty central to REA, so I hope we can resolve that one soon. In the meantime, we'll keep on trucking, not to be confused with transportation or transfer.

[fosterlynn]

A couple things I'd like to bring over here from the long chats @elf-pavlik and I have been having, in terms of Transfer, because this is a good scenario to look at it. In this scenario, Al harvests 100 apples. Harvesting apples is largely a supply-driven activity. The trees are mature, they have ripe apples. Al probably has some idea of how many apples he can trade, give, etc. But he doesn't actually know, and he doesn't know who will be the receivers. So we can't use the produce event to transfer the apples, the reality is he has 100 apples in his inventory after harvesting. (Another scenario could be different, and some agent could be producing for a specific receiver, in a make-to-order scenario for example.)

In terms of using the transportation events in the exchange with Cloe, there will not always be transportation. In this case, say Al got a ride with his 100 apples to the local farmers market, and sold 97 of them. So he is walking home with 3 apples in his bag. He stops in at Cloe's coffee shop and offers his 3 apples for a good cup of coffee, and she agrees. They physically make the trade, handing over the resources. It doesn't really rise to the level of unload, but there is a physical movement involved.

So now we have apples getting little-t transferred from Al to Cloe. There are 2 aspects. One is the physical movement of handing Cloe the apples, so she has possession. The other is the agreement they made verbally, which made clear that Cloe now can do whatever she wants with those apples, there was a transfer of ownership rights in addition to the physical movement. If Al had said, "can you just keep these here for a couple hours while I run an errand, and I'll be back for them", then the agreement was not for transfer of ownership and Cloe wouldn't consume the apples to make turnovers, being a kind person. But the physical movement would have been the same, and she would have possession.

I think this talk of "teleportation" confuses the physical movement with the transfer of rights. And they are intertwined in many situations, including this one, so I get that it can be confusing. If Cloe doesn't have possession, it doesn't do her much good to have ownership rights. But what is the important aspect that should be recorded? In this case it is the transfer of rights, imo. If transfer of rights includes a bit of work to change possession, or to record the transfer (like sitting with a landlord to sign an apartment lease) and a small physical movement (like being handed the key), that is real but is secondary to recording the event in a way that facilitates traversing value flows or understanding the situation on the ground. And there is nothing wrong with recording those activities too, maybe it is important to know that you sat with the landlord for an hour of your time.

There is a fundamental difference in economic terms between production and circulation - creation of value and transfer of value. I think we need to have that distinction in VF. In terms of the gray areas, and the fact that different people want to look at them differently, that just means we need to provide full vocabulary for both.

[fosterlynn]

Ha, I was looking for this last week in all the wrong places, but @bhaugen has found it. https://www.vdmbee.com/2014/07/vdml-roots-possession-ownership-availability-poa/ might be useful to further look at the transfer stuff, if we can all agree that transfer is useful at some level. I'll study it in the next couple days.

We also could think about other nuances of transfer, like custody/responsibility kinds of things that aren't outright ownership. Maybe we need to define some new actions, or whatever, to make the rights and responsibilities more out front at some general level, instead of all hidden in an agreement somewhere.

This is all to say, let's continue to discuss and work with examples. But I hope we can agree to not throw out the whole concept.

[bhaugen]

But I hope we can agree to not throw out the whole concept.

The concept is required.

P.S. Sensorica uses custody all the time, so we need that concept, too.

[elf-pavlik]

Transfer could easily be a superclass of Process. The difference appears, to me, to be semantic.

I can't think of situation where one couldn't just use Process instead of Transfer and implementation wouldn't process it the same way (unless application makes some additional assumptions not based on VF vocab). Following definitions from: https://www.slideshare.net/Demetrius_Gallitzin/Hessellund05a#8

give and receive do not 'change existence' while consume and produce do. Having actions responsible for that I don't see need to try to use either Transfer or Process for cases that 'change existence' or not.

Given that we don't require 'pure transfers' where provide and receive happen only in data and physical resources stay unaffected. I see give and receive used for 'teleporting' just as one could use load and unload (which also don't 'change existence')

So we can't use the produce event to transfer the apples, the reality is he has 100 apples in his inventory after harvesting. (Another scenario could be different, and some agent could be producing for a specific receiver, in a make-to-order scenario for example.)

IMO application which fully support VF needs to support any flow with provider and receiver and we have to define in unambiguous way how to interpret it for every action. 👏 for #389 which should address it. I see Process (and Transfer) only relevant for tracking provenance of resources with of without them 'changing existence'.

If Al had said, "can you just keep these here for a couple hours while I run an errand, and I'll be back for them", then the agreement was not for transfer of ownership and Cloe wouldn't consume the apples to make turnovers, being a kind person.

An agreement could include simple

'@context`: 
  al: https://al.example/
  cloe: https://cloe.example/
  #...
'@id': cloe:6148e235-a218-4e79-81f1-32ac2533cfdb
'@type': Commitment
provider: cloe
receiver: al
action: give # load or just decrement would work just fine
involves: cloe:34d1a44d-fafc-425f-b2ce-f5aa41705fc1 # EconomicResource 34
commitedQuantity:
  qudt:unit: qudt:Unitless
  qudt:numericValue: 3

Then when Cloe plans her consumption of apples, she will get correct 'available' quantity which deducts those 3 already promised to 'give back' to Al.

There is a fundamental difference in economic terms between production and circulation - creation of value and transfer of value.
If Cloe doesn't have possession, it doesn't do her much good to have ownership rights.

I see a 'pure transfer' more under what you referred to as 'transfer of value'. In case where Al actually delivered apples to Cloe, I see aspect of 'creation of value' since it changes location of resources in a way that supports planned processes. Even that transportation load & unload doesn't 'change existence' as transformation consume & create does.

---

I still stand by my statement that application fully implementing current state of VF should treat in the same way data which uses:

• give and receive with Transfer
• load and unload with Process

Currently we haven't defined any specific difference in how applications should reason over those two version. In addition not requiring 'pure transfers' and having give and take used for 'teleportation', means that application consuming data from heterogeneous sources has no way of knowing that application which produced that data used first or the second approach.

[sqykly]

I definitely envisioned Al personally picking the apples, walking into Chloe's Coffee Shop, and handing her the apples. If it helps, he doesn't even toss them, leave them on the counter, or drop them; there is no point at which the apple is in no one's hands.

I'll take a noob stab at the issue. From the semantic perspective, there is a clear enough difference to justify having separate Transfer and Process simply because humans are often reading the output. The computational differences as they stand right now are not significant, but that doesn't mean they can't be, nor that those differences can't be useful.

First, a short side quest. When I was writing the HoloREA code dealing with the interplay of EconomicEvents and EconomicResources, I came to think that EconomicResource could be broken down a bit. It has identity and it has state. Identity is the identifying information that uniquely specifies what it is (classification) and, among the owner's inventory and according to their tracking scheme, which subdivision it is (tracking identifier). Those things are immutable (computationally). State is a collection of axes that events target to mutate them:

• Quantity
• Ownership/custodianship
• Location (I know VF doesn't do this, but it would be a nice feature that people will want, I think)
• Availability

My idea is that Transfer and Process divide the state up. Events that affect the quantity axis or the availability axis are managed by Processes. Events that affect the custodianship axis or the location axis are managed by Transfers. This hard, fast rule gives direction to the evolution of their respective classifications in that they can be used to easily validate the completeness and correctness of their event sets and neatly separate their concerns when classifications are created to constrain the operations that are valid. Even with the current nominal classifications, we can detect an invalid Transfer by finding a non-zero net quantity in its events.

Why am I terribly off base?

[sqykly]

Clarification: Transfer would itself affect those axes, and Process itself would target availability, since EconomicEvent only applies to quantity and/or existence.

[sqykly]

Feature I just mentally happened upon: Transfer can assert a single ResourceClassification and doesn't need to bother with more nuance in its classification, whereas ProcessClassification can support rich requirements and inferences regarding Actions and resources.

[fosterlynn]

@sqykly lots to think about upthread, which I will do, but just briefly:

Location (I know VF doesn't do this, but it would be a nice feature that people will want, I think)

VF has currentLocation on EconomicResource, but we don't really intend to model Location itself if we can avoid it. We've had some discussions about what kind of event would just change locations, but haven't spent a lot of time on it. In Sensorica, they have a map which shows the current location of all the resources (their lab, Phil's lab, etc.) - so you are correct, there is a requirement.

[fosterlynn]

From the semantic perspective, there is a clear enough difference to justify having separate Transfer and Process simply because humans are often reading the output. The computational differences as they stand right now are not significant, but that doesn't mean they can't be, nor that those differences can't be useful.

Agree, thanks for expressing this clearly. I think this will apply to the discussion on use of increment and decrement as actions, too.

[elf-pavlik]

• Quantity
• Ownership/custodianship
• Location (I know VF doesn't do this, but it would be a nice feature that people will want, I think)

Clarification: Transfer would itself affect those axes, and Process itself would target availability, since EconomicEvent only applies to quantity and/or existence.

EconomicEvent currently can affect any 3 of the above, we haven't clearly defined how to express change of location in event. We also only have provider and receiver currently which doesn't allow to specify which 'rights and responsibilities' get provided & received in an event (with any of available actions).

Availability

Could you please clarify what do you mean by that? In one of the ways of using this term, Commitments play role since EconomicResource 30 could have existing commitments that reference it with vf:involves, those commitments can have actions like consume, give, load which all will decrement it when the actual event occurs, similar with commitments for produce, receive, unload which will increment the resource. In one way of understanding availability one would have to take all the commitments into account. I understand that your demo doesn't try to implement actions like work and use which affect schedule (and sometimes quantity as well like in: use 5 electric drills for 3 hours, managed as one resource with 20 electric drills in it). I think we can focus on the specific use case that you want your implementation to handle and for now discuss availability in that context.

[elf-pavlik]

@sqykly I've just published first version of track-trace algorithms implemented in typescript:
https://github.com/valueflows/vf-track-trace.ts#readme

It relies on asynchronous RDFJS Source interface which one could very likely implement over Holochain. It provides asynchronous iterator for tracking and tracking. Feedback welcome directly in vf-track-trace.ts repository 👂

[almereyda]

We have moved the ValueFlows organization from GitHub to https://lab.allmende.io/valueflows.

This issue has been closed here, and all further discussion on this issue can be done at

https://lab.allmende.io/valueflows/forum-valueflo-ws/-/issues/125.

If you have not done so, you are very welcome to register at https://lab.allmende.io and join the ValueFlows organization there.