[Zero]

Introduction

Hi all,

In this thread, I'd like to suggest something to everyone working on AI here on AIDreams. Also I'd like your feedback on this, so I can make it fit your needs.

It is both a software architecture, and a way of working together. Let's start with the software architecture.



Software architecture

It's a social networking service for software components. I can't say it better.

It revolves around the principle of followers. When ComponentA chooses to follow ComponentB, ComponentB's output is sent to ComponentA's input ASAP. If ComponentA follows 20 other components, its input will receive a mix of outputs from these 20 components.

If you're the developer of ComponentC, you cannot choose which (already existing) component will follow yours. You can only choose which components your new ComponentC will follow, and what will be its output.

In other words, it's a data market. When you sell things, you can't force customers to buy your products, all you can do is create the best product you can, and hope customers will buy it. It's the same here: you choose where you take your input from, and you make your output available to the system. One day, another component will follow yours, and so on.



A way of working together

Now, let's look at the "way of working together" side of it.

If we work long enough in this direction, we'll have one single system, able to do a lot of things, instead of a lot of independant systems able to do... what they're meant to.

I'm not saying that making it big is enough to reach AGI. I'm just saying that size matters. Now, the bigger the slower, but computers are getting faster everyday, so I believe we should not worry too much about this.



A component's interface

A typical piece of software has 1 input (stdin) and 2 outputs (stdout, stderr). This is old design.

A software component should have 4 ports:

Code

  DATA IN:     data the component works on                 (stdin)
  DATA OUT:    data it puts on the market                 (stdout)
  DASHBOARD:   input to decide what to do                  (stdin)
  EVENT LOG:   log of the component's activity    (stdout, stderr)

There are 2 new things here:
- We split input in 2, one for deciding what to do (DASHBOARD), one for what we work on (DATA IN)
- We don't log only errors, we also log what has been done successfully, whatever we do

Example:

Code

                             DATA IN
                           a broken car
                                |
         DASHBOARD              |               EVENT LOG
       A car needs to    -------+-------->   I successfully
        be repaired             |            repaired a car
                                |
                                V
                             DATA OUT
                          a repaired car

A component can choose to connect its 2 inputs to any port of any other component. It can be connected to another component's outputs, to work in chain, and also to another component's inputs, to "spy" it (receive what it receives).

Connecting to another component's DASHBOARD allows understanding why (or when) a component does things. Connecting to another component's EVENT LOG allows understanding how a component does things.



Commmunication

There are 2 ways for a component to communicate:
- through its standard IO, stdin stdout stderr
- through sockets (TCP)

A component gives orders to the system (send this message, give me a list of components, connect me to this port of this component) and receives messages from the system (here is a message from this port of this component, here is a list of components, you're currently connected to this and this...)

The language used for giving orders and receiving messages is currently under development (it works already). It is a stack-based concatenative language, that allows tacit programming by function composition, and featuring usual data types: strings, numbers, ordered lists, associative arrays.



Drivers and inner nodes

A component doesn't have to speak the system's language. Incoming and outgoing messages can be translated by drivers, which are written in Javascript by the component's developer, and delivered with the component. Drivers can make things easier if you develop something with, say, Prolog.

Also, it is possible to develop inner nodes in the system's concatenative language. Inner nodes have the same capabilities as regular components. They can be created by regular components.



A component's purpose

A component can have any purpose. It is a regular software, that should be useful to the user. You can have components to play music MP3, to read e-mails, calculate things, chat, surf the web, ...etc, whatever.

The only thing special about a component is that it is also part of something bigger.



Conclusion

I'm posting this sketch here because I believe AGI is not a one-man job, and because I would love your thoughts on this. So please, whoever you are, don't stay silent!
 

EDIT: typos

[Korrelan]

Hi Zero

Sweet idea… but isn’t this the outline for Ben Goertzel’s OpenCog initiative?

https://en.wikipedia.org/wiki/OpenCog

http://wiki.opencog.org/w/CogPrime_Overview

https://groups.google.com/forum/#!forum/opencog

I’ll give it more thought. 

[Zero]

Hi korrelan,

I would answer no, because in our system:
- We don't define what components are, how they work, ... (developers are free to bring anything)
- Components can have a direct purpose (and be useful to the user) like any regular software
- A component's inner activity is visible to any other component (through its EVENT LOG port)
- There's democratic fun even without claiming holy grail

Also maybe, we can think of it as a modern Supercharged Expect.
Thanks for your interest

[Korrelan]

Hi again...

Wouldn't the schema of this system be parallel?

Aren't you going to require some global method of Synchronisation?

Two machines can sync easily, but if either is already synced with another machine it gets very complicated, especially when network latency etc are a factor.

Using delay loops while an app is waiting for processed data is going to cause bottle necks all over the place.

Aren't you are going to require a global sync from a master machine/ time server?

Still thinking… 

[Zero]

I understand what you said about bottlenecks, but no, synchronisation is not required. Simply, when data is available at a component's input port, or when the user interacts with it (if it has a GUI), the component starts working and emitting data. That's it.

A component can be seen as a REPL... if you talk to it, it works. If you don't, it stays silent. So components don't need to work at the same pace.

EDIT: Trying to explain myself better

EDIT: Thinking about what you said... the only thing that could go wrong is if incoming data arrives too fast for the component to consume it, resulting in an ever growing amount of unconsumed data. So, here is an idea. Incoming messages are queued. When the component says "Ready", the system delivers all queued messages.

EDIT: Here is a taste of the concatenative language as it is today (and translated from french, because yes, the original source code is in french):

Code

<Unlist and interpret> <loop>

<Memorize the list> |loop| [[

	<If then else> <Not> <Equal> <x> (11) [<Unlist and interpret> <loop>] [|ok|]

	<Memorize the element> |x| <Add> <x> (1)

	<Write> <x>
]]

<Memorize the element> |x| (1)

This source code works and prints numbers from 1 to 10.
You read it bottom-up. The beginning of the program is at the bottom, and the end of the program is at the top. I hope you'll like it 

[ivan.moony]

Just thinking at loud... A modular crowdsourced hardware / software development... Let's see how Metafigure can handle this...

Code

ZenOS <= (
    ID <= @Integer,
    Input <= (
        Mouse <= (
            X <= @Integer, 
            Y <= @Integer, 
            ButtonCombination <= @Byte
        ) <- (
            // Logitech | MS - implementation modules
        ),
        Keyboard <= (
            Key <= @Integer, 
            State <= @Byte
        ) <- (
            // Logitech | MS | Omnikey - implementation modules
        )
    )
    Output <= (
        Display <= @ByteArray <- (
            // Belinea | Adi - implementation modules
        ),
        Sound <= @Byte <- (
            // Hercules | SoundBlaster - implementation modules
        )
    )
) <- (
    // Specific runtime machine instances

    // Machine 1
    (
        ID <- 1, 
        Input <- (
            Mouse <- @Logitech,
            Keyboard <- @MS
        ), 
        Output <- (
            Display <- @Belinea,
            Sound <- @Hercules
        )
    ) |
    
    // Machine 2
    (
        ID <- 2, 
        Input <- (
            Mouse <- @Logitech,
            Keyboard <- @Omnikey
        ), 
        Output <- (
            Display <- @Adi,
            Sound <- @SoundBlaster
        )
    )
    
    // Machine 3 ...
)

... Good, i like it... 

P.S.
I don't know when will Metafigure be out (I work at a slow pace), so you are welcome to use any promoted ideas as you wish

[Zero]

In this language, I use a modified version of the syntax I described recently in another thread:

Code

  Syntax    Name        Example                  Description
  ------    ----        -------                  -----------
  < >       Sign        <Square>                 Variable containing a list of elements
  | |       Text        |Hello world|            String constant
  ( )       Number      (3.14)                   Numeric constant
  [ ]       List        [<One><Two>]             Constant list of elements
  { }       Dictionary  {|Act|<Todo>|Time|(21)}  Constant associative array

Metafigure probably can handle this very easily 

EDIT: Thanks for sharing your ideas, ivan.moony

Here is another version, not translated, with a square function named "Au carré". It shows function composition (square is mul-dup):

Code

<Délister et interpréter> <Boucle>

<Mémoriser l'élément> |Boucle| [

	<Si alors sinon> <Non> <Egal> <x> (11) 
		[ <Délister et interpréter> <Boucle> ]
		[ |ok| ]

	<Mémoriser l'élément> |x| <Additionner> <x> (1)

	<Ecrire> <Au carré> <x>
]

<Mémoriser l'élément> |x| (1)

<Mémoriser la liste> |Au carré| [ <Multiplier> <Dupliquer> ]

It outputs:

Code

==>(1)
==>(4)
==>(9)
==>(16)
==>(25)
==>(36)
==>(49)
==>(64)
==>(81)
==>(100)

[ivan.moony]

Code

<If then else> <Not> <Equal> <x> (11) [<Unlist and interpret> <loop>] [|ok|]

Is this Polish notation?

Edit:
If you are thinking about crowdsourced platform, it would probably be wise to build up some security system for code ownership, sharing, change announcement and group editing. I think that world misses a platform like that. It could be an opensource platform, but why to restrict it? Why not to include commercial amplifications too? That way people would be motivated for development and even for small code updates like extending existing program functionalities.

[Zero]

Code

<If then else> <Not> <Equal> <x> (11) [<Unlist and interpret> <loop>] [|ok|]

Is this Polish notation?

Yes, it is reverse-reverse polish notation. It means:
- Push [|ok|] on the stack
- Push [<Unlist and interpret> <loop>] on the stack
- Push (11) on the stack
- Push the content of <x> on the stack
- Pop 2 elements from the stack, if they are the same, push |True| else push |False|
- Pop 1 element from the stack, if it's |True| push |False| else push |True|
- Pop 3 elements from the stack, if first is |True| unlist and interpret 2nd else unlist and interpret 3rd
It reads backwards.

About security, I do have an idea. When you download an app on Android, the app needs permissions. You read the permission list, and you decide if you want to install it or not. Here on our system, low-level functions could be marked as "needing this and this permissions". If a component doesn't have required permissions, some functions (orders given to the communication service) won't work.

I believe the real cool thing here would be a component store...  like PortableApps
 

Edit:
Maybe someone with PHP/MySQL skills could build such a store? 

[ivan.moony]

Maybe someone with PHP/MySQL skills could build such a store?

I think that it would be a great idea (with some polishing and add-ons), but I'm busy with my own project right now.

I thought for a while now of extending my project as a little self sustained operating system that runs over javascript/php. It would have in-browser window manager, a kind of start menu, some task bar and a whole infrastructure for running different apps made explicitly for executing inside browser. Different apps would be distributed over web servers (that run in the same OS fashion) and they would be installable to a specific node server by some package and version manager. The same package manager would have built in programming editor with collaborative capabilities. Some security and sharing mechanism would apply, which would allow forking and extending existing apps if authors choose to share their source code. A sort of Github with editing capabilities.

So a new user would go to the mother site and would ignite an installer that sets up (by FTP) a specific web server for running apps. Because it would all be ran inside browser, apps would work in the same manner on win, linux, osX, android, win phone, or whatever other technology that hosts web browser. Each user would have her/his own web server for hosting private or sharing public data that lives on the server.

Something like Google Apps, but users would own their own servers and data. And I think I have a thing rolling with Metafigure, allowing to compile whatever programming language to HTML/Javascript at the time of execution. And when a centralized collaborative editor comes into the equation, I think that programmers could be satisfied with the proposed solution.

But first things first, so I have to finish programming Metafigure core firstly.

[Zero]

Interesting project. Every once in a while, I go back to the main thread of Metafigure (a language to describe other languages). The more I read it, the more I understand it. Do you believe Metafigure alone would be enough to host AGI?

[EDIT]
Hey, I have a TCP REPL now!

[Zero]

Emitting component activity reports

Each component should emit actitvity reports on its EVENT LOG port. It means that anything it does, it should tell the world about it. In other words, every function call should be reported. That's a lot. Do we have to report absolutely everything? I don't think so.

Imagine you have 3 loops:
- A loop L1 which runs 10 times a second and which contains L2
- A loop L2 which runs at 100 hz and which contains L3
- A loop L3 which runs at 1000 hz

Like this:

Code

for i1 = 1 to 10
  for i2 = 1 to 10
    for i3 = 1 to 10
    end
  end
end

If you report things too often, the system will be slower. So, to find the right level of granularity, a component's developer should wonder what messages make sense. Sometimes, one message saying "I did this for each that" is enough. Also, if you emit more than 30 activity reports in a second, maybe it's too precise.

[EDIT] Typo

[ivan.moony]

Do you believe Metafigure alone would be enough to host AGI?

Last time I checked it was able to handle deduction and induction (I think those two are crucial to AGI) through variable pattern matching.

[Zero]

Impressive. I also think induction is crucial, and more difficult to implement that it seems, when you work with versatile data. If I could help you, I would. But honestly I don't fully understand your work yet (you're into tough stuff).

About our communication service here (which still needs a name, if anyone has an idea), what bothers me is: how can we integrate components that are highly parallel by nature. Take korrelan's neural nets for instance. You can hardly plug each neuron individually into the system... Generally speaking, some components could need really high performance links with other components. In those cases, maybe it would be wise, sometimes, to use the DATA OUT port not to deliver actual data, but to tell interested components how and where they can connect to get data. Say, if you have a video feed: the best option is probably to use shared memory, in which case the DATA OUT port would provide all information needed to connect to this memory.

korrelan, you're used to highly parallel systems, you got a comment on this?

[Zero]

I think I'll name it:

Code

	 -------------
	| SIMPLE TECH |
	| COM SERVICE |
	 -------------