Ecosystem technical architecture

Here's a long and complex conversation about this topic from the Telegram Community Software Interoperability group. I'm posting this is several parts, and will signal when done.

Mat Slats:

@lynn the Solsearch API is doing something I don't think any other platform is doing becuase it is indexing content from any other platform. Platforms by nature tend to be self referential, rather than interoperable. So the whole thrust of my work is to create an interoperability layer, function by function, so that diverse platforms can interoperate using commons services with simple platform independent APIs. I know very few instances where platforms are talking to each other in this way and so solsearch isn't duplicating anything else going on out therE

Bernini:

Hi @matslats sorry if im asking you to repeat for the n times the same concept, where i can find documentation upon solsearch? Do you have a github repo or a wiki?

Lynn Foster:

Mat Slats
@lynn the Solsearch API is doing something I don't think any oth

Yes, I agree completely with what you said, so perhaps I wasn't very clear. My question is then how should we best make offers/wants interoperable with other important functions? How to think about interacting api's across a software ecosystem? How to mesh all of our visions?

Mat Slats:

the api is documented here. https://app.swaggerhub.com/api/matslats/sol-search/1.0.0 I wonder if it deserves a web site of its own. For now Community forge is runing an instance of the solsearch service, but only deployed on a few cforge sites for testing.

@lynn this approach doesn't very well support the more workflow oriented approach that value flows and wezer and support. Solsearch is simply an index of extant offers. So if you want to universally rate those offers, or connect them to inter-group transactions, or move them through workflow states you would have to build all of that into your own platform.
Those things are very hard to support between platforms because there are so many different ways of doing them. What we can do between platforms with very different internal views of the world is only a minimal feature set without things getting very complicated very quickly.

Lynn Foster

Mat Slats
@lynn this approach doesn't very well support the more workflow

Well I'd like to try! And maybe we'll find out that a "minimal feature set" is enough for a lot of what people want to do, I don't think we need a complex set of models. I'm not saying it is an easy task, but I think necessary to move towards supporting an actually running fair economy.

Mat Slats:

Right so my hope is that various platforms will choose to contribute to a simple global index of offers and wants simply for the purpose of helping people to exchange, regardless of platform, currency, or the movement they happen to be engaged with. I would like to see Freecycle stuff indexed there, for example, but they didn't answer my mail, also MAN, also timebanks, and I can dream all the projects listed on http://matslats.net/barter-software-reinventing-the-wheel

Bob Haugen:

@matslats - I think I have not understood your proposal before, possibly because I did not understand where you thought it fit into a software ecosystem.
I assumed it was an API into your existing mutual credit software.
Do you mean it as a possibly-global intent-casting service, where many apps could publish their offers and wants and match them up, and then the matching counter-parties would conduct the conversation about a possible exchange between their "home" apps?
Like, how would this work in the Mutual Aid Networks, where they are using your mutual credit system as well as Wezer, and both systems have offers and wants?
(But I think only Wezer tracks the states of conversations about offers and wants...?)
This also gets back to @fosterlynn 's questions about the intended architecture.

Eric Doriean:

Great and needed conversation everybody. I got into this because @ AnyShare we are soon going to integrate Loomio and laters others via their api. The idea of sso for both AnyShare, Loomio and others would be great, so you could click on a Loomio poll in AnyShare and not have to login again on Loomio. That is if Loomio chose to use the same sso. Something that would be more likely if we a lot of us came together and worked on the same sso solution. Although this would all be great, there's an opportunity to kill a few birds with one stone here. A massive issue on the net is users data as you all know. We at AnyShare have a goal, like I'm sure others do here, for users to have complete ownership of their data. So they can choose who, can or can't use their data and for what. In researching this I came across Solid (https://solid.mit.edu/) In a perfect world a sso system that used Solid or something like it, so that the data could be used by other apps if the user chooses. That way data could be tagged with value flows or other vocabulary like they are using at the Ceptr project could be added to the data. User signs into the apps they want using the sso and then choose what data they want to share. Love to hear peoples thoughts, whilst were talking vision

Mat Slats:

@bob Yes a global intent-casting service. But very simple, there is no matching service provided only the ability to filter results on location, keyword and a few other things.

Bob Haugen

Mat Slats
@bob Yes a global intent-casting service. But very simple, there

Ok, thanks. I might finally get it. Sorry if I should have understood faster, but sometimes I am slow, and there are a lot of moving pieces in this potential software ecosystem.

Bob Haugen:

Eric Doriean
Great and needed conversation everybody. I got into this because

https://anyshare.coop
Welcome @solarpunked
Are you doing anything with Solid or Ceptr? Or just looking?
(I'm just looking at both...;-)

Numa
To me it seems clear that APIs to connect apps to existing platf

@numa_gopacifia I agree that strategy is important at this stage, and I like APIs, but I don't think they are a practical strategy.

If every app publishes their own API, and you are using many apps, you pretty soon run into a combinatorial explosion of APIs that must be somehow integrated.

That's why at least some of us prefer vocabularies and protocols for app interoperability.

But getting agreement on those is hard, too, so we are also interested in vocabulary translation systems like what Tibor of Communector showed us.

And I am always ready to be proved wrong about any of my opinions...
But also, in practical terms, if somebody publishes an API, I can usually derive a vocabulary and maybe protocols from it.
Still, I'd like to see more common agreements on these kinds of things in the commons...

Mat Slats:

Numa an app doesn't publish an api. A rest service publishes an API and an app is a client that implements the API. So to rephrase what you said:
If many REST services publish an API, and an app is using many rest services, then instead of an explosion of APIs, you can have a an explosion of interoperability. Every common function an app does could be done in a standard way and maybe even in the same database, instead of one app, one big api, one backend, many functions one user community, you can have many apps, many small APIs, many backend services giving a choice of function serving a much wider community.

Bob Haugen:

What I mean by an app publishing an API is an app as a service that you can communicate with thru its API.

If you want to define App as Client, that's ok with me, but I want software that can provide services, too.
If each ReST API has its own vocabulary (sets of fields with different meanings, different messages you can use to POST or PUT), then your client app using them all has a combinatorial explosion.
The HTTP(s) protocol helps a lot with a standard set of methods, but over the top of those methods another layer of protocols emerges.

Mat Slats:

My understanding is that the app is on the client side of the API (e.g. the mobile phone) and the service on the server side. The whole point of this architecture (I think) is that the two are separate, independent components conforming to the same spec.

Bob Haugen:

I am ok with using those definitions, if it will help you understand me better.
I understand client and server more easily.

Mat Slats:

So, ignoring solsearch, which is only indexing content from existing platforms. Imagine if all the offers and all the wants from all the apps were stored in the same db. It wouldn't matter what app you were using under what brand with which business model, you would have de facto access to the whole marketplace. You could even switch to another app without losing access to that market. Compare that with say, Pollen or a typical local exchange in which you only have access to Pollen users or members of the local system...

Bob Haugen:

Disregarding the database angle, if everybody used your offers and wants api, that would constitute a common vocabulary for offers and wants and some part of a common protocol.
What would emerge on top of that protocol is the layer 8 protocol for economic interactions, where offers and wants find each other and engage in conversations where they either do or do not exchange resources.
Like in the Mutual Aid Network, where I think their Wezer app handles the economic protocol.
And I think in at least some mutual credit systems, that is all handled informally.

Mat Slats:

Yes, and the APi would probably need to be a bit more accommodative of variation, for example by allowing user-defined fields. But I can't design that myself very well.

Bob Haugen:

Yeah, vocabularies are hard, and common vocabs are harder, and need to be defined collaboratively.
And then redefined collaboratively....

Mat Slats:

you have flexible fields as well so the db can have a plain text field called, say, 'extra', and each app could store the unspecified fields & values in a serialised array. Then any client could render those fields legibly without understanding them. Better still, in a nosql database every item can have different fields and they are still searchable.

Bob Haugen:

Bob Haugen
Like in the Mutual Aid Network, where I think their Wezer app ha

I probably used app differently than you do, again. Wezer performs both client and server functions.

Mat Slats:

Wezer is what I would call a platform that delivers ready-to-render html. rather than the service/app model which passes json back and forth.

Bob Haugen:

I've been using app in the sense of Layer 7 in the Internet protocol stack which is the application layer, not in the sense of a phone app. But I'll change if that confuses people.
Anyway, I think we are getting too deep in the weeds, and I need to cook breakfast.
But I'm glad I finally understand your ads api proposal a bit better...
Not too interested in arguing definitions...

Mat Slats:

hey bob I didn't consider this an aargument, and not the first time between us it has been very necessary to clarify how we use words. It was months before I understood what you meant by vocabulary for example.

Sybille Saint Girons:

About ontology remember to see what is going virtual assembly with Communecter and Simon Louvet
They have defined PAIR (projects actors ressources ideas)

Bob Haugen

Sybille Saint Girons
About ontology remember to see what is going virtual assembly wi

We met with Communector this week, and are meeting with Guillaume Rouyer of Assemblée Virtuelle next week. Haven't met Simon Louvet yet.

Mat Slats
hey bob I didn't consider this an aargument, and not the first t
Yeah. I understand. And most people have no idea what I mean by protocol, either...

(more to come in next comment)

This last part of that long comment was garbled, and Loomio apparently can't edit something that long. It should have read:

Me responding to MatSlats:

Mat Slats hey bob I didn't consider this an aargument, and not the first t

Yeah. I understand. And most people have no idea what I mean by protocol, either...

(In other words, as you can see from several parts of these conversations, it takes awhile before we understand what each of us means by the words we use.)

Bernini:

does this diagram represent the vision you're expressing so far ?

Mat Slats:

yes thanks a lot bernini. You've got the relationships exactly right. I would add brand names to the apps e.g. LETS app, timebanks USA App, MAN app.
I would name a couple of the APIs Acccounting API, P2P adverts API, Authentication / group membership API
And instead of 'backend' I would say 'REST service'

Bernini:

I think it wouldnt be only rest service, because for backend I mean also server logic and db
is it the same for you?
anyway I'd like to propose a slightly different diagram:

Mat Slats:

For me a REST service includes business logic and data storage - maybe I'm using the term unusually I don't know

Bernini:

ok at least we know its the same :)

Mat Slats:

I don't understand the extra layer you added. And the backends wouldn't necessarily talk to each other. They just need to have a common authentication method - something like. The client passes a token that proves the current user is a member of group X

Bernini:

What you said is how the first diagram works, but I think it would be foundamental in order to create a true ecosystem to provide a unique set of API / graphQL / .. already structured and organized with all the data coming from all the different apps, merged to specific endpoints.

The reason why is if you have 2 endpoints from witch the client need to GET the same list of data (that represent the same items) the frontend should be dumb enough to retrieve the list from a unique endpoint that contains the merged items
if not, the frontend would be really complex and sovrastructured
for this reason we would need the extra layer that should allow the communication among backend

Sybille Saint Girons:

caan you give example of apps and backends please ?

Bernini:

pretty the same of Mat

an app could be a lets app with an exchange market integrated
a backend could be the backend of the LET, where all user balance and transactions are stored
and where there is the business logic to update user balance and infos

Mat Slats:

can you give a more practical example of what the extra layer would do?

Bernini:

USECASE: we have 2 separate backends that offers a list of wants/offers and we have a client app that need to show a unique list of wants/offers
with the diagram 1. the client should GET data from endpoint provided by the backend 1 and make another GET from the endpoint provided by the backend 2, then add logic to normalize data (because normally the json retrieved from different endpoints are formatted in different way, with different information and different methods)
and then display the list of wants/offers
with the diagram 2. the logic to normalize data would be made on the extra layer, in a way that the data that arrived to the rest api are already normalized and merged togheter
in this use case, the client app would make a unique GET to one endpoint and show the list as it arrives

Mat Slats:

In the case of two seperate backends storing offers and wants i have already built an indexing service (SolSearch) which I judged to be easier than syncronisation or making multiple requests

Bernini:
I need to find the time understand how it works :)

anyway that example is possible to replicate with every kind of data
in an ecosystem of apps, replication and normalization of data is one of the first challenge we'll find imho

Mat Slats:

the solsearch doesn't normalise the data, it is a searchable index of the data. It is populated not by crawling but by each database updating each item as it is changed.

Bob Haugen:

One of the things that will happen in the middleware is that different clients will be handling a lot of different data, not just offers and wants, and some of the other data will be related to the offers and wants.

And likewise the different backends will provide different data sets, some about offers and wants, and some about resource production, etc etc.

We just finished a conversation about blockchains that are starting to handle different mixes of "assets", for example, with all of the history of all the assets.

Eric Doriean:

Bob Haugen
Are you doing anything with Solid or Ceptr? Or just looking?

With Ceptr eagerly awaiting the alpha of Holochain and getting across the Ceptr grammar. Am seeing grammar like what they use as well as open values as key for interoperability. Api's are nice and we have one, but only part of the solution imo. Ceptr white paper on their grammar is very good. http://ceptr.org/whitepapers/grammatics

Not much in terms of Solid yet. Only recently came across it. The need is there and makes sense to use w3c standards and piggy back off Tim Berners Lee fame.

Bob Haugen:

Thanks for Ceptr paper..

Same basic idea of common vocabularies between Solid and Ceptr (I think - need to study this latest Ceptr paper...)

Grammar is necessary too.

@Bernin1 has been working on sentence structure for apis

Eric Doriean:

We're mostly thinking open values and in particular rea, as short to medium goals. Ceptr still very much a wait and see, but getting across it now

Lynn Foster:

@solarpunked just looking at Anyshare, will study it some more, maybe joining is the best way to do that....?
Yes for Ceptr and Solid, it is a question of readiness I guess

Bob Haugen:
3 people who are pretty deep into Solid in the Value Flows gang (but not me)
Lynn is deeper than me

Lynn Foster:
I'm deep into VF but not into Solid

Bob Haugen:
I'm thinking Pavlik, Kalin, and Brent.

Melvin comes around some, too, and he is way in deep.
We got nobody who's into Ceptr yet.

Eric Doriean:

Yeah, easy to get mixed up with all the acronyms. REA (Resource, Event, Agent) is simple and makes a lot of sense for interoperability and being the basis of circulatory economics. It's one thing an app using it, but need others to be able to get/use the data. Hence why were keen on sso and a way for users to choose how they share their data.

Bob Haugen:

REA is our core, as well.
And was one of the main topics on that blockchain call we just finished.

Mat Slats:

OK yes middle ware is where the business logic happens

Lynn Foster:

@Bernin1 great pictures, really helps the discussion!
Question: what is the communication between the backends on your second picture?

Mat Slats
OK yes middle ware is where the business logic happens

I think of business logic happening on the backend... ? Is middleware the api / vocabulary layers?
(just making sure I get the terminiology)

Lynn Foster:

@matslats where does solsearch sit on either of the diagrams? does it include any user interface? I am thinking it is a backend thing?

(I had misunderstood earlier, I hadn't realized the backends are responsible to write to the index, now I understand more why there is one api dictated by the index. And that makes me understand why you talk about big databases of different sections of information.)

Mat Slats:
Solsearch would be underneath the backends on the diagram. it is a service to platforms (or other services)

Pospi:

A very interesting discussion being had here! On using multiple APIs- some seem to be suggesting that this is an appropriate low-friction way forward. @bhaugen is absolutely right about the "combinatorial explosion" that comes with many different (competing or complementary) APIs being implemented. But such an explosion isn't free, and in practise I think we'll find it falls flat. Developers don't often implement apps which talk to multiple APIs because of the considerable effort involved in doing so- connecting to 1 API is enough work, let alone several. If apps connected to multiple services was a useful and appropriate way of achieving interoperability, we'd have already seen it happen. The tech has been there for decades.

I'd also add that creating a translation layer on top of existing APIs that normalises the data for end-user apps only partially alleviates the problem. You might be able to share the normalised data with more apps, but really you're just pushing the problem further down and requiring a complex intermediary be built which must still do all the translation work. Of course this will be unavoidable to some degree, but I think it should be looked on as a backwards-compatibility measure and not a forward-thinking solution. Indexing and normalising with "helper" services like Solsearch is also a great way to bring older apps up to date.

In a pinch, you might be able to get something workable with a single set of APIs/services chosen for each purpose (1 service for signon, 1 for offers/wants, etc), but it's never going to be an ecosystem. Nobody is going to come along and integrate offers/wants services #2, #3 and so on.
In my view the current pragmatic & inclusive solution is common protocols & vocabularies, or systems like the ones referred to earlier which translate between. Once you've defined some grammar for communicating what "user data" looks like (eg. solid), then developer effort at the application level is potentially reduced to adding some extra URLs to integrate additional services. It needs to be that easy for the application developers, or it just won't happen. But this requires the service developers to understand and build to the specs, which is often easier said than done.

The long-term, more tightly integrated solution is to just have a single system / database as @matslats describes. The tradeoff you have to make there is accepting a single global world-view. This is where blockchains & potentially holochains come in- but such solutions are only going to reach widespread adoption if they are designed by communities with extensive amounts of feedback to ensure that they work for all users. Otherwise we're just creating new sets of silos with weak glue between them but doing it on top of new tech.

The nice thing about such projects which integrate code into the network is that developer error and failures become "harder". Which is to say- it's really easy to mess up conforming your data to some protocol in a way that makes some of the interoperability not work; it's less easy to mess up code which talks to other code directly because (if the tooling is right) you can't avoid having the language & compiler in there to error check a lot of things for you.

Here's some kind of attempt to visually describe the landscape as I hope it unfolds.. I'm not as good at pretty pictures as @Bernin1 though :D

(I'm leaving blockchains out of the picture for now to avoid overcomplicating it, but interchange between those systems would probably look much the same anyway)

Lynn Foster:

@pospigos thanks for the thoughtful post

Sybille Saint Girons:

+1

Gustav Friis:

@pospigos very good description, thanks I learned quite alot. I agree very much on your silo platform/protcol concerns, which is not pr. default solved by new technologies such as blockchain. Below is a simplified outline of the architecture we are currently working on - illustrating a mobile application interacting with a smart-contract on the public Ethereum blockchain - mediated through a belt of federated relay servers.

I agree that designs like this, at least in the short term, are likely to suffer from a 'silo syndrom' as well - where other silos are likely to be solutions based on other underlying consensus protocols than Etheruem, say fx Faircoin or Bitcoin RSK.

For the longer future I think this syndrom will become less of a problem due to interoperability between different BFT blockchain protocols - forexample enabled through sidechains based on two-way pegs.

Bernini:

:heart::heart: both for pospi and gustav solutions...:smile::+1:

Bob Haugen:

This is getting to be an interesting discussion..

Lynn Foster:

:+1:

Pospi:

@Gfriis for your reading pleasure here are some other interoperability efforts underway, with Gavin Wood's Polkadot probably being the most ambitious:

• https://polkadot.io/
• https://github.com/cosmos/cosmos/blob/master/WHITEPAPER.md#cosmos-overview
• http://bitcoinmagnates.com/the-value-of-sidechains-and-leveraging-their-potential/

(mentions xrelay, which people at Consensys tell me is the generic version of BTCRelay currently in progress. Can't find much other info on it though)

• GitHub cosmos/cosmos
• Internet of Blockchains - https://cosmos.network

Pospi:

the team tells me xRelay is still in "stealth mode", so I guess you'll have to wait to hear more on that front!

Gustav Friis:

Cool, @pospigos most appreciated. I am slightly familar (will proberly never fully understand them hehe) with Cosmos and Polkadot already - and have met a few of their team members, definetley capable projects! xRelay is news to me too, will ask a bit around for info on that one!

For Cosmos, they rely heavily on Tendermint, with strong similarity to Hydrachain. That is, so to speak, a factory of creating customized blockchains (permissioned/permisionless) with different consensus.

Solutions that in the future will allow for pluggable consensus, which is also the long term vision of the Enterprise Etheruem Alliance, so that the public chain can be used.

Both are already a bit old, and the newer evolvements here are espcially CITA from cryptape, Hangzhou I recently visited. Cryptape also help to develop the Casper PoS Ethreum update.

https://github.com/cryptape/cita

Another one is from Taiwan, and the mysterious AMIS group, who recently released this Istanbul Byzantine Fault Tolerant EIP:

https://github.com/ethereum/EIPs/issues/650

I also recommend to take a look at OmiseGO, this whitepaper is mainly written by Joseph Poon, one of the creators of the lightning network protocol.

https://cdn.omise.co/omg/whitepaper.pdf

Omise is a very powerful commercial entity, they have sponsored forexample the development (in parts) of Raiden Network and Cosmos Network + various other Ethereum initiatives through Dev Grants.
GitHub
cryptape/cita
cita - A fast and scalable blockchain for production.

Pospi:

thanks heaps! I will take a look at those links for sure. Have heard of Omise before but not the others

Eric Doriean:

Thanks @pospigos and @Gfriis

I never thought about translation for grammar. Very cool. Feeling a good step 1 is start with a grammar and to me value flows and REA makes a lot of sense. Ultimately we'll see a lotv of different grammars come and possibly go, so do see how translation would be needed.

Know were still in vision/discussion mode, but at some stage would be good to start thinking on steps, that app devs like us at AnyShare would need to implement

Bob Haugen:

I think it is necessary to think both strategically and tactically.

Strategically: something like the diagram @pospigos just showed us. And people start to build software components that were designed from the start to be part of an ecosystem (which is actually starting to happen: the Kamasi project is like that, and I think also @matslats Ads API, and likewise the projects working on SSO),

Tactically: start to integrate different existing software that is used in a community, as FairCoop wants to do with OCP, ChipChap, and FairMarket, and the Mutual Aid Network with Hamlets (mutual credit) and Wezer. That will probably be done more opportunistically at first: just make it work. And then when the ecosystem practices get more developed, maybe change over to the ecosystem architecture, or maybe not.

The SSO component might also do some evolving. All the components will evolve as we get better at being an ecosystem.

I think maybe the Kamasi project might be the first app that was designed to fit into something like @pospigos 's diagram...

Lynn Foster:

Eric Doriean
Thanks @pospigos and @Gfriis I never thought about translation

Know were still in vision/discussion mode, but at some stage would be good to start thinking on steps, that app devs like us at AnyShare would need to implement

@solarpunked do you want to also join in on the loomio Open App Ecosystem conversation? The focus there tends to be more action oriented - https://www.loomio.org/g/exAKrBUp/open-app-ecosystem

And as always, there is nothing like a good use case on the ground to move things along. Mutual Aid Network has one to make existing software interoperable, but that will involve people doing api work on other people's software, and will also need a single signon piece. FairCoop at some point will also want to make several things interoperable.

Is there some group using AnyShare that could fit in somewhere? Or some other way you have in mind to explore how to plug Anyshare in to the "tactical" steps, either here or in loomio?

Bob Haugen:

@pospigos 's diagram describes a stack-based architecture, if I understand correctly, where "client" apps would use a protocol adapter to communicate with what to them are "server" apps (although in some cases the "server" apps would communicate with other "server" apps, too).

(I am using "client" and "server" in quotes because each of the apps could potentially play either role.)

Pospi:

Check!

Bob Haugen:

I am very interested in working out the second situation, where open apps communicate with each other by switching roles in conversational (message-passing) conversations

A Conversation for Action protocol is like that:
https://www.valueflo.ws/introduction/cfa.html

In the state machine diagram on that page, A and B alternate being client and server.

Pospi:

Same! Do we build "push" or "pull" services for this? Push seems preferable, but pull seems more pragmatic, possibly?

Bob Haugen:

Pospi
Same! Do we build "push" or "pull" services for this? Push seems

Good question!
How would pull work in that state machine diagram?

Pospi:

I guess the service reading would just poll the other? So less efficient in terms of resource usage..

Bob Haugen:

How would the conversation get started? By responding to an intent, maybe?

Pospi:

Push seems ideal, for immediacy too. But it requires producing services to know about all their consuming ones. Maybe theres a way to be clever about it using something like PubSubHubbub (or whatever is in common use these days)
Hm you might need to put that into concrete examples before i'm with you. Off to dinner, will pick this up later (:

Bob Haugen:

Couldn't the initiating app A POST a message to the initially responding app B via some designated URL of B?
I'll write up a concrete example.

Eric Doriean:

Lynn Foster
Know were still in vision/discussion mode, but at some stage wo

Well said and thought out. Don't have a case study that would be the right fit just yet. But I will work on that

Ps. Have joined the Loomio group and will get active in that during the week

Bob Haugen:

Concrete example: Lynn is A, Pospi is B, in CfA.

Lynn posts a request for help in debugging her graphql mutation, on her personal app. Also gets posted on @matslats solsearch ads service.

Pospi sees it on some link to Lynn's request on the solsearch ads service, and responds to Lynn's personal app using the link in the solsearch ad.

After that, the conversation continues between Lynn and Pospi's personal apps.

Pospi's response says that he offers to help debug this problem, but that he can't reproduce the bug.

Lynn explains more about how to reproduce the bug.

Pospi says, ok, I finally get it. Then he pushes a change to the graphql api code that he thinks will solve the problem, and notifies Lynn.

(These are messages in the Negotiation stage of the CfA state machine.)

Lynn tries the proposed solution and says to Pospi that it still doesn't work. They go around a bit in messages about how to make it work, and finally arrive at a working solution.

(Those messages are in the Evaluation stage of the CfA state machine.)

@pospigos - Clear enuf?

Bob Haugen:

Lynn and I talked about this on our walk. A couple of additions:

• An organizational app might have many such conversations going on at the same time, even about the same intent. Personal apps might have them, too. So each conversation will need to have its own unique identity, and each of the apps involved will want to keep track of the state of the conversations and the message history.
• One way I have seen that done is via a traveling document, where each message gets appended to the traveling document, and then each participant signs both their message and the traveling document when they post their next message.
• Also, some kind of maybe paxos-like consensus mechanism, or maybe even simpler, will be required around each message send and receive, so the sender knows the message was received and understood, and if they think it has not been received and repost, that the message appears once and only once in the conversation.

Ok, that was 3 additions...

We should harvest this chat into some ongoing document...
document shd be shareable both here in the open app loomio group.

(This is that document.)

Bob Haugen:
P.S. Lynn and I sketched out an even-simpler 2-agent post exactly once setup awhile ago.

2-agent transaction protocol:
https://docs.google.com/document/d/1g8NUOziTtFJIzVc2uJTcwQycC_cuTKTbErkCXW7JegM/edit?usp=sharing

...and that was the end of the harvested conversation. Hope it made sense in this context, and that you found at least some of it to be interesting and possibly useful.

Short version of that long and rambling conversation:

Three approaches to technical architecture have been discussed and tried out among participants in OAE-related projects:
1. Stack-based: many components combined into the same stack, all working together, and presenting themselves to users as a whole system.
2. API-based: each component publishes an API which other components can use to communicate with it.
3. Vocabulary-message-based: components share a common vocabulary and send messages to each other using that vocabulary.

[edit] approaches 2 or 3 could present themselves to users as a single system, or not.

Those approaches are not mutually exclusive: can be mixed and matched.

Here is a Loomio conversation from three years ago about vocabularies:
https://www.loomio.org/d/5WOvZfEq/linked-open-data