Kendraio

>What I would now like to do is identify a practical thing we can do together. You've already seen we can build forms from the ValueFlows schema. What next? What else do you want to visualise? What else do you want the user to be able to do? Maybe think of something specific in one realm/domain and we can riff on that theme?

@Daniel Harris yes! ❤️❤️❤️ What kinds of visualizations can you or do you want to show? There are some structures in VF that would seriously benefit from some good visualization. For example, the economic activity tends to form directed graphs. One thing people have wanted for a while is something to fill the same requirement as a gantt chart like for visualization of your project or some piece of work. Or, what other kinds of UIs are you most interested in building? But @pospi let's chat on the side and see what you think makes sense for HoloREA projects, and might fit into the UI component approach....

Good information @pospi . We are not bound by what JSON Schema or GraphQL support. We can find other ways of encoding configuration for rules or validation or error or interface. For example UI Schema is another up and coming way to add interface cues to JSON Schema when rendering in a form. So, we can play other tricks like that.

What I would now like to do is identify a practical thing we can do together. You've already seen we can build forms from the ValueFlows schema. What next? What else do you want to visualise? What else do you want the user to be able to do? Maybe think of something specific in one realm/domain and we can riff on that theme?

@pospi Can you think of one GraphQL API that you would want us to integrate into Kendraio App? Something that is close to what you are doing? Something that would be useful to you to visualise? Something that we could perhaps work on collaboratively now?

Would be really amazing if there was an open source version of something like this!

Could that be what we are doing? Just a possibility given the resources. OneGraph looks great. Nice name too. 🙂 We've been thinking about integrating these iPaaS/iSaaS providers into Kendraio App – to give us a 'leg up' so to speak. I've forked a list in one of our docs. Feel free to add any others you can think of at Kendraio Adapter API Registry | API gateway providers .

It's not just the ValueFlows community that is aligning with GraphQL... it's a trend in distributed systems in general. Scuttlebutt folks just built PatchQL and there are projects like https://thegraph.com/ in the blockchain space. There has also just generally been movement away from RESTful APIs towards GraphQL over the last 5 odd years since Facebook started marketing the tech more.

If you connect to an existing backend, validations will probably happen there and you'll get an error message back if something won't work.

Check. The nice thing about GraphQL is that it has a standardised way of handling errors. So that means you can integrate upstream errors from the services you're wrapping pretty easily into your UI.

I think json-schemas may have some syntax for validation beyond required fields

They do, but I'd debate the usefulness of implementing them. There might be reasons to avoid back-end round trips for invalid payloads if dealing with blockchain systems (very long request times); but for other stuff like Holochain and Scuttlebutt there's really no reason to since the "backend" is on the local machine anyway and requests are pretty much instantaneous. There are quite a few oneOf type validations in ValueFlows (which I know JSON Schema supports) - you could potentially move those into schema validations, but IMO it's just another place you have to maintain. GraphQL itself doesn't support validations that are any more complex than "required"- its goal is to be a minimal backend-agnostic schema layer and so it foregoes a lot of this kind of power for flexibility.

For completeness, @Lynn Foster has been defining validation logic for ValueFlows apps. Most are quite simple, but there are also some complicated ones which need to check against several related records.

Awesome. It'd be worth checking out https://www.onegraph.com/ btw- they have done a heap of work to integrate an array of web2 services into a single query API. Would be really amazing if there was an open source version of something like this!

Re: ValueFlows, Kendraio, Validations and Tasks...

Hi @Lynn Foster

One question I have has to do with validations and making sure what gets saved makes sense and will work. Let's say you are creating form and list interfaces from a specification, like VF in json-schema and graphql are on the table in this discussion. The economic stuff is a bit less forgiving than say your basic social interaction, and needs to be way tighter than "anyone can say anything on the web".

So, how does that fit in with how you think about your work? If you connect to an existing backend, validations will probably happen there and you'll get an error message back if something won't work.

Yes, if not right now, we definitely will be able to handle error codes sent from a remote API endpoint that is doing the validation logic.

But, I'm wondering, and don't have the experience to know - I think json-schemas may have some syntax for validation beyond required fields, but I'd have to look again, never actually used them. I don't know what can be done along those lines for graphql? The only one I wrote relied on compiled code for that.

And we can already do type and pattern matching validation logic within the local App and this can expressed either within JSON Schema or UI Schema, I can't remember right now.

Maybe the question is, what if the thing you are doing on the web is more than what you have observed most of it is, lists and create/update/delete? With apologies if I missed something you said about that.

Ah, but that's actually an entirely different question and one that probably deserves a whole new post in itself but I can't be bothered right now. ;-) So, I'll answer here...

The short answer is that we'll create an interface to let you interact with the service that is performing the logic of the "thing you are doing on the web" that "is more than what you have observed". ;-)

One of the things I really want to have in the App is a list of all the tasks (human and machine) that I am involved in on the various services I connect into. Maybe a GitHub issue, or a complex P2P search, or uploading my latest song release to 10 different online stores, or observing the state of holochain/blockchain transactions. So I can see progress as they happen (or not/fail). Not sure if that relates to what you are asking but the question inspired me to mention what we are calling Tasks – instances of Flows. Maybe. We're all working it out. ;-)

Re: ValueFlows, Kendraio and GraphQL

Hi @Lynn Foster

I'm bumping this to the top because comments were getting lost at the bottom. If I was viewing this in a future Kendraio App (or similar) then I'd plug into the Loomio API and I'd be able to set the rules about how comments were listed and in what order. Oh heaven! Anyway...

Right now most of the people using ValueFlows are using GraphQL, partly due to @pospi 's influence on several projects. And it's a nice tool. So that means you could potentially plug something from your user interface(s) directly into some soon-to-be-existing-at-least-to-experiment-with "backend" and it would work.

That's great. I spoke to Kendraio lead developer and he says that we can do GraphQL without much/any changes. ;-)

>PS: I think "sybmol" is spelt wrong but I don't have the guts to change it on GitHub. 🙂

Fixed it 😬 - thanks @Daniel Harris !

Anyhow, I got through the whole thread, and appreciate all the thoughts from everyone. As for the big picture, I understand what you're doing could be a piece of the "let's make it lots easier and safer for users to connect into the economic networks we choose" or something like that. Economic as in trading, sharing, creating together, using, consuming, etc. etc., with a goal of being within our ecosystemic bounds and outside the bounds of surveillance capitalism. Or something like that. Little bits now, so we can create some fair tools that will work larger scale when we need them. I hope and think that fits with what you and @mike_hales are both saying.

But, I'm gonna be focused mostly on the details. 🙂

>Would it be better for us to speak native GraphQL?

I don't know, and you may want more than one interface, but here are some thoughts and questions, maybe for both you and @pospi.

Right now most of the people using ValueFlows are using GraphQL, partly due to @pospi 's influence on several projects. And it's a nice tool. So that means you could potentially plug something from your user interface(s) directly into some soon-to-be-existing-at-least-to-experiment-with "backend" and it would work.

One question I have has to do with validations and making sure what gets saved makes sense and will work. Let's say you are creating form and list interfaces from a specification, like VF in json-schema and graphql are on the table in this discussion. The economic stuff is a bit less forgiving than say your basic social interaction, and needs to be way tighter than "anyone can say anything on the web".

So, how does that fit in with how you think about your work? If you connect to an existing backend, validations will probably happen there and you'll get an error message back if something won't work. But, I'm wondering, and don't have the experience to know - I think json-schemas may have some syntax for validation beyond required fields, but I'd have to look again, never actually used them. I don't know what can be done along those lines for graphql? The only one I wrote relied on compiled code for that.

Maybe the question is, what if the thing you are doing on the web is more than what you have observed most of it is, lists and create/update/delete? With apologies if I missed something you said about that.

@mike_hales So many vectors. So little time. ;-) Some random thoughts on what you said.

I'm enjoying you posts. I did ask for a challenge I guess. ;-) Every other word I'm having to look up! ;-)

Remember, we may be trying to solve different problems. If we are to know if something is "appropriate" or not then we need to know the context/aim/goal before we can judge. I'm not sure of your goal yet. What's your goal? In simple terms. I mean, what do you want your experience to be? Yes, I think that's the better question. The human experience?

For me, I am trying to solve the problem of app bloat for users and duplicated functionality across multiple services and lack of data portability for users. It is from my (the user) point of view that I am coming at this. Hence my first interaction with any service is via an interface. I have a gut feeling that this approach may contribute to a much bigger goal of freedom for individuals to decide how they live their lives but I'm not sure yet.

Don't get me wrong. I love architecture. My Dad and brother are architects. And I am not advocating one method over the other. We all have different skill sets. I was never going to be the one to build an open protocol for media/music but I was really good at getting people together to think about the problem for a while. And then I realised my skills might be far more about adoption strategy. We can build the best technology but if it don't get used then what's the point? So, now I'm working in another way: develop a little, integrate real people/organisations, develop, adopt, develop, adopt. In Kendraio's case the adopters are now driving development. And that's what I want. Also, in some ways, this is much more of an art methodology of the journey. But it's a bit of both.

There is not only one way. All ways are stronger if they interconnect how they can. Each can help uplift the other. That's my strategy for Kendraio: get as many adopters as I can and make it work for them. It's paying off.

Things we can talk about in our call:

• Interface vs architecture: both are necessary and needed but not necessarily in that order. ;-)

• Software development: I have a hunch that development is not efficient. There is a tendency to build discrete chunks that can be branded and marketed. This is just as much the case for FOSS too. Most likely due to ego and money. If I just say "yes, like, I'm just interconnecting everything" then it's hard to sell the idea to a funder (either grant or investment). But if you say I have a thing and it's got a nice blue badge then it sells like hot cakes. Yum. Yum. But is that the most efficient? I don't think so.

• One tool vs many tools (monolith vs interoperability): interoperability is hard and takes agreements between people – which is always hard. So, much easier to build a tool to rule them all. Much harder to get all existing tools to work together. I think I've found a middle way.

• Goal orientated vs art orientated: err... both?

• Ground, ground, ground!: I'm really cautious about working with developers. My experience has been mixed. Suffice to say I now have a rule: whatever you do make sure it works in the app so I can test and demo it each day. Of course I'm flexible with the rule. But I'm very cautious of letting a feature take ages to make work. And I'm all for keep it tidy as we go. All this takes longer. Many developers love to hide away for months and then come out with the thing. That doesn't work for me because, though we have alpha (experimental) code. We are live and have users and I am demoing every new feature every new day.

Look forward to our call in a month.

Cheers

interface first . . interaction is about listing stuff they have or want, performing an action on it, adding a new one or editing an old one. And I want the same interface no matter what service I am interacting with

My intuition is signalling some kind of hacking aesthetic here (which I resonate with -bricolage, maybe. Something fundamentally materialist, stuff-oriented. Not unconnected with the WIMP-desktop paradigm). I have an intuition that practice within a ValueFlows network - organising the provision of X in a manifold of supply possibilities, from here, now - would have something of this kinaesthetic quality of handling stuff. Equally intuitively, I have a sense that the experience of working with federated wiki has something of this in it. Maybe that’s why I brought the fedwiki thread into the OAE forum.

But @Daniel Harris I don’t think it’s appropriate to speak of this as ‘interface’. Seems to me, this is basic architecture for a profoundly powerful kind of tool, needed in a world of basically ‘wild’ or feral material. The One Tool to Rule Them All. Well maybe not! But at least, a Swiss Army Knife. I’ve been searching, all my computer-using life (user and active configurer, not coder) for this kind of bricoleur, palimpsest-making, scrapbook-compiling, hypertexting toolspace. ‘Interface’ is such a mistaken construct here. This is basic prosthesis-design for life in a world of feral digital material? A prosthesis can be regarded as interface, I guess. But for the ‘wearer’ it’s Self? It’s the means of constructing the entire practical world, in actual, hands-on, autopoetic practice. Interface, schminterface 😉