Modularity - Githubissues

bhaugen commented 5 years ago

This is a raw idea. Don't know how far I will be able to take it right now, but I want to lay down a marker. Maybe somebody else can take it farther.

Consider each of the vf: classes or types. Instances of each of those could have a set of functions that do things for and with it.

Just as a GraphQl reference is emerging, it could be accompanied by code modules.

Those code modules could be composed into vf-apps.

We might need to design a bit more about how they could interconnect. Like, vf:protocols.

Then (@fosterlynn says) the classes and functions could appear in UI modules that could be assembled into sentences and network overviews and dashboards.

Then, given an agent-centric architecture, the agents could form agent-centric organizations and select which modules and apps they want to use, and the vf:vocab and protocols could get the apps and the agents to interconnect and communicate.

Thus, also, modular organizations.

Did I go too far here? Or not yet far enough?

bhaugen commented 5 years ago

@fosterlynn has been thinking like this for awhile. I am just catching up...

pospi commented 5 years ago

I like it as a concept; acknowledging that it's interesting / difficult to think about how to define these functions as specifications rather than implementations. Could be done in terms of the vf: grammar and defining what the side-effects of calling each function are, based on the input parameters: as a simple example, calling vf:createEconomicEvent with some input vf:EconomicEvent (e1) results in a new vf:EconomicEvent (e2) composed of (e1 + new system-generated ID). That's the sort of logic that immediately comes to mind, anyway. Surely there is lots of prior art on this, though I've no idea where to start looking...

I also think it would be good to ditch the concept of "classes" when thinking about this stuff; and center thought around "functions". Main reason being functions are the fundamental building block that every programming language has available, classes only exist in OO or (some) prototypical languages. Perhaps considering something like JSONRPC as an interface that behaves in this manner.

bhaugen commented 5 years ago

@pospi

I also think it would be good to ditch the concept of "classes" when thinking about this stuff; and center thought around "functions".

I asked Lynn what word to use and she said they are Owl classes, so I went with that. Don't personally care.

difficult to think about how to define these functions as specifications rather than implementations.

Advice I got for specs is specify expected results. But I think it's better to start with implementations, as in "rough consensus and running code". The graphql will be key.

pospi commented 5 years ago

they are Owl classes

Ahh, gotcha. Overloaded word that one!

"Specify expected results" sounds like what I'm trying to convey; the "side-effects of calling each function" would more or less be "the expected results in terms of how the state of the system as a whole changes", if that makes sense. There is probably some very clever Haskell modules that could do this out there, but that's stepping way outside my comfort zone heh

bhaugen commented 5 years ago

I think the whole goal will take a few iterations to get right. The current crop of experiments (HoloREA, Luandro's work in SSB, and whatever comes out of the ActivityPub track) will tell us a lot. Then I think something from applied category theory. So Haskell would be a good influence, if not a good way to implement.

bhaugen commented 5 years ago

Besides the graphql API, economic sentence structures will be important:

And speech acts.

bhaugen commented 5 years ago

Sentences: sentences-trading-partners

sentence_independent

fosterlynn commented 5 years ago

I also think it would be good to ditch the concept of "classes" when thinking about this stuff; and center thought around "functions".

I'm way behind on functional programming, but I'm thinking almost everything will have something like:

class - type - object - record - row - etc. with attributes - properties - fields - etc. (even if people build it up from rdf triples or whatever makes up a DHT)
functions that CRUD the first thingies, that are all saved, so all versioning is there

Maybe the functions that are conversational will be defined more specifically than CRUD, like "request", "accept", "reject", "reply", those kinds of things. Or maybe those will be CRUD-ing those conversational objects too.

But I'm sure y'all will bring me up to date as needed.....

bhaugen commented 5 years ago

Another angle: https://johncarlosbaez.wordpress.com/2019/04/04/the-pi-calculus-towards-global-computing/

the pi calculus can be seen as a generalization of traditional computing languages; there is an embedding of lambda into pi – but there is an important change in focus: programming is less like controlling a machine and more like designing an ecosystem of autonomous organisms.

[edit] Those slides have way more mathematical notation than I can parse. These links might be somewhat useful. WS-Choreography was a project I worked on when I was employed by a startup called Choreology. The startup failed, and so did WS-Choreography, and so did all the Web Service stuff. But WS-Choreography was heavily influenced by, and somewhat based on, pi calculus, so it might help with understanding.

@fosterlynn might find the model to be interesting. Here's an excerpt: roles

bhaugen commented 5 years ago

So I looked at that model in the comment above, and I think it is wrong. Has a flaw.

Agents will not have relationships with other agents based on relationships between roles.

The VF model is better. An agent has a relationship with another agent and the role characterizes the relationship.

With the model above, if I take a role, I now have relationships with all other agents who take roles with a relationship to my role. So let's say I am a member of an organization. I have a relationship with that org where the role is "Member". The role Member will be held by many other agents, but they are not by that token all members of the same organization, or members of all organizations that have members.

almereyda commented 4 years ago

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/vf-apps/-/issues/2.

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

valueflows / vf-apps

Modularity #2