Proof of Concept: InterPlanetary Service System

[josemi]

IPSS could share microservices across the network like files on IPFS.

If user A has an idea for an application, it does not describe how to carry it out, instead, it describes the problem they are facing, what requirements must be met to solve the problem (service 1). Besides, this same user can propose a solution (service 2) against the description of the previous problem.

If user B believes that this task could be carried out in a better way, B does not have to write a competent application to the first solution to perform the task in a different way . Instead, B writes his own way to solve the problem (service 3).

If a user C wants to execute the aforementioned task, he should not choose between the solutions proposed by A and B, but rather a service (service 1) will choose between one of the two proposals based on a training previously carried out, the user C will end up executing the task in the most optimal way and without having to choose between one solution and another.

This could allow the development of decentralized applications both in distribution and use and in development.

It should ensure that it is as open and simple as possible in terms of standardizations in order to ensure not limit any type of implementation on it.

Comments or opinions about the subject?

[Akita]

On what criteria would service 1 chose to use service 2 or service 3?
Who will do the “training”?
How will service 1 discover service2 and 3? (And 4 and 5)?

[josselinchevalay]

Maybe with a smart contract system where you define parameters in input and parameters output and for dsicovering maybe a system of inherit can help

[josemi]

Who will do the “training”?
Anyone who wants to.
I do not think that there should be any kind of incentives for nodes to share images or previous training, or for better quality services to be developed, or for nodes to give part of their resources in the execution of any service.
This should be taken care of by some kind of system in a higher layer (in the same way that Filecoin is superimposed on IPFS), smart contracts.

On what criteria would service 1 chose to use service 2 or service 3?
For example, I can train this set of algorithms (services 2 and 3) through regression, after a while, I will be able to predict better or worse which is the best solution for a specific input.

If you think that training is better to do using genetic algorithms, you can create a service that meets this, after a while you will predict better or worse than me.

How will service 1 discover service2 and 3? (And 4 and 5)?
You could also add another competent service to 2 and 3 to your training and selection service.

Now the kit of the question lies in how the intelligence obtained by the previous training is shared. With this, the different selection services could learn from each other and the user who wishes to use the application would only have to go to any of these selection services.

I have to emphasize that up to here no type of consensus is required between the parties (as if it occurs in a blockchain).

[josemi]

Hi Josselin, thanks for contribute.

*Maybe with a smart contract system where you define parameters in input and parameters output *
Indeed, the problem could be defined by describing its entry and exit points.
As I said previously in response to Akita, I consider that everything that has to do with consensus between peers (blockchain, crypto assets, contracts …) should be placed in a higher layer because it would force to dictate more rules on the network.

I think services should specify their API to cover the aspect you mention.

For discovering maybe a system of inherit can help
I don’t understand what you mean by inheritance system, could you explain it?

Although I have the following in mind:
If a developer wants to upload a service to solve the proposed problem, he should direct to a node that is running a training service for this problem (if not, take a node and run a training service).
The training would contain the performance of the solver, and as that intelligence is shared by the training services through some type of incentive, new services would be discovered.

I want to highlight one thing, so that there is work on all parties, developers doing good services and nodes distributing and executing services, there should be an incentive in the form of capital, now, I don’t think this issue should be dealt with in the first instance due to to that I consider it of sufficient complexity like treating it a layer above.

Therefore, the potential of the system lies in how open it is, to allow it to evolve and be optimized, and the possibility of incentivizing its various parts in some way.

[josselinchevalay]

hello josemi,

i totally agree with you IPFS manage data (file / DAG) and we need to manage contract etc into another stack.

Inherit system ? For the inheritance story I’m not really thinking about it at the moment I’m testing some ideas on my side.

Let’s take an example: A developer wants to create a service that takes care of adding a tax level on an invoice.

He could declare a contract as follows:

Service taxInvoice1 {
    Amount:Integer
} -> InvoiceWithTax:Integer

un autre developpeur voulant affiné ou amélioré cela pour faire

Service taxInvoice2 implements taxInvoice1 {
   things:[]Object
}

[teknomunk]

This seems very vauge. Is this a proposal for a marketplace for human powered services using IPFS as a backend (i.e. web development)? Is this a proposal for distributed computing? A smart contacts system? Something else entirely?

I think that giving an example of someone using the proposed system with concrete details (instead of an abstract “service 3”) would help a lot in explaining what you want.

[josemi]

Hi Josselin,

I think that taxInvoice2 should not implement taxInvoice1, that is, I don’t think that the service that comes to solve the problem should refer to the one that specifies it.

This is because, if so, it would not be possible to replace the taxInvoice1 service.

I think that I have not extended myself enough before, sorry.
The idea behind microservices is that they can be seen like black boxes, we don’t need to know anything about them, only use them using his API’s.

I would specify a service using the following components:

Container: Specifies the container where the service runs, microarchitecture, entry point and filesystem (DAG?), and environment variables.

Api: Defines how you can interact with the service, the ports where it listens, the communication protocols that it supports, methods and the different errors and responses that it can give.
Perhaps also the cost that the use of each method can have (but for now it is to complicate it a lot …)

Dependencies (optional): Services that it will use during its execution, so the node can mount them during its assembly.

Tensor (optional): Defines “intelligence” that the service can provide, I think it would be a description of a polynomial (without coefficients and describing the variables).

Ledger (optional): Defines the database used by the service, as we speak of a decentralized network at all times, this data must be contained in a blockchain or something similar. I think it would be a class diagram and a consensus algorithm.

The last two are maybe a bit crazy (yes, brainstorming necessary …).

With that said, I am going to use an example to expose why I see necessary design IPSS.

Let me change your example to a somewhat more complex problem, ordering a set of integers. You will agree with me if I say that it is not easy to find the ideal implementation of the ideal ordering algorithm.

Yes, someone could develop a powerful and well optimized algorithm and say that it is the best sort algorithm that will ever exist. But no matter how competent your implementation may be, you may be wrong, there will always be someone who comes up with a better solution at some point.
And it is not only that, but there could be some implementations that serve better in one type of scenario and others in others, therefore the statement of our developer is quite bold.

Therefore, we would like to have a system that, without a central axis, allows us to always choose the best way to solve a problem or perform a task.

The various services that we could have regarding the problem of ordering integers would be:

• A service that implements a bubble sort.

• A service that implements a selection sort.

• A service that implements an insertion sort.

• A service that classifies ordering services through linear regression, randomly generating the entries. It can export what it has learned using a tensor. Its api allows you to add sorting services, order the tensioner and command it to train.

• A service that classifies management services by scoring who performs the least time. It can export what it has learned using a tensor. Its api allows you to add sorting services, order the tensioner and command it to train.

• A service that uses the same type of tensioner and solves the problem. Its api accepts, like the sorting algorithms, a list of integers and returns the ordered list.

I believe that this architecture allows decentralized development and allows the best integer ordering algorithm to be used, even as a function of input data or available response time.

I hope I have explained myself enough.

[josemi]

Hi teknomunk,
thanks for your feedback.

It’s true, maybe I don’t explain it the right way. My intention with the creation of the thread is to brainstorm ideas.

The idea is to develop a distributed computing system that allows sharing, comparing and executing services.

All this with the sole purpose of generating an ecosystem that evolves based on competition between its parts (services among themselves and nodes among themselves).

It is not at all a marketplace of services, the only human interaction should be the development of these. The distribution and the analysis of the performance of the services should be fed back by their own competition.

I start from the idea that no solution to a problem is 100% correct or optimal.. Therefore, something like IPSS should be as open as possible as far as rules are concerned.

Therefore, neither the nodes nor the services should be obliged to be based on any specific type of technology or architecture.

That is why I see a need in the development of a series of protocols that allow covering this aspect without the need for any kind of supervision.

I think IPSS should cover the following aspects:

• Define the specification of a service (perhaps as explained in the previous message).

• Specify the responsibilities of the nodes.

• Specify the responsibilities of the services.

[wolneykien]

Hi! Recently, I’ve made a proposal on the subject — A preliminary discussion of the “Workswap” protocol.

In particular, my answers to the mentioned questions are the following:

On what criteria would service 1 chose to use service 2 or service 3?

For example, I can train this set of algorithms (services 2 and 3) through regression, after a while, I will be able to predict better or worse which is the best solution for a specific input.

1. Each peer, that uses services, accumulates statistics about the service provider peers. These statistical data then is used to rank the providers as “good” and “bad” and for prediction.
2. The providers are ranked with various values including their availability, percent of communication errors, communication rate and communication ratio.
3. The communication ratio between the peers is the same thing as the credit/debt balance in the Bitswap protocol, but this time it counts for both static and dynamic traffic between the peers giving a way to trade static content for dynamic content and vice versa.
4. The accumulated statictic of a peer can itself be made public in a form of a service helping the others to select between yet unknown providers.

How will service 1 discover service2 and 3? (And 4 and 5)?

You could also add another competent service to 2 and 3 to your training and selection service.

I see the discovery procedure following way:

1. service maintainers publish services descriptors on their IPNS;
2. these descriptors include the list of endpoints that actually provide the described services;
3. the endpoint peers (the providers) publish some counter-authorization data on their IPNS to confirm the fact they are active providers of the corresponding services;
4. in addition to endpoints the service maintainer can publish downlinks — the links to sub-maintainers.