MaidSafe Dev Update - March 1, 2018

See my post above. If you want distributed computing, it doesn’t have to involve the SAFENetwork client at all, beyond regular data get/put operations. It would require the authors to define how everything is coordinated though. Perhaps there are existing compute apps out there that could be customised for SAFENetwork I/O?

For full general purpose compute, there are definitely advantages of integrating tightly with vaults, especially where permissions and data sensitivity is an issue. However, using SAFENetwork client side messages and encryption libs could externalise a lot to a separate layer. For example, using JavaScript promises, you could wait on a compute event completing… the agent that handles this could be custom or 3rd party.

Many ways to skin this rabbit I think!

4 Likes

We are talking about renting CPU cycles aren’t we…a separate entity to a vault?

Yes - decentralized computing and using safe as large super computer

If you do it at app level you obviously would need to run a different software than a vault (or the vault+computing bundled software for safe miners)

I do struggle to understand how an app can access CPU without a compute API

Well, it depends how the billing is setup. It doesn’t have to be that fine grained to be useful. In the least general purpose sense, you can literally run an agent on your machine, waiting for messages from the client (which could be a website, safecms, Java app or whatever). In the most general sense the agent is integrated into the vault and the network decides who executes the code. There is ground in the middle where a third party run so your agent (or a customis generic agent) to execute the code.

Also consider that an agent as described above has parallels with services run on servers. However, as the data store isn’t distributed and agents can be ran anywhere, it does not need to necessarily sit in a data centre (but it could).

The important bit is how the client app communicates with the agent. Using messaging on the SAFENetwork, you essentially have a message queue (like rabbitmq, Kafka, etc). These are asynchronous message buses, which the client can push something onto, then wait for a response to come back. This can’t be done via JavaScript already I believe, so integrating this flow in Peruse should be relatively simple.

Note that this style of client side development isn’t already becoming popular on the clear net. Using web sockets to connect the client to the server, with a message queue at the server end to control what I said sent where. With SAFENetwork, the client potentially has direct access to the message queue, just as it does with general SAFENetwork data.

Hope that fleshed out the bones a bit?

2 Likes

Yes. Nice discussion. You guys should head to the dev forum and add some thoughts there too : (Decentralised computation app - how? - General - Safe Dev Forum )

The webrtc video client MaidSafe just released has essentially the communications seed/prototype for a way of doing a basic “SafeCluster”… at least at the sapp (safe app) level. A basic SafeCluster and a more sophisticated SafeCompute module don’t necessarily need to do the same things, but both could perform general computation services. One might be a stepping stone to the other. SafeCluster would probably need a basic SafeOS to be safe and secure.

5 Likes

Thank you makes distributed compute into more of a marketing buzz word and less of a grail.

From the above getting a picture that it will eventually happen on machines with a full SAFE OS that themselves may be virtually unlimited with compute and storage (obviating the point) and it may happen at the app level for security-stability again on already outrageous nodes. Maybe on local q neural net machines that have extended long range instant EPR busses etc. As if S.I. discovers an early chunk of data in SAFE as it builds out sufficient computronium but might need very little matter so no build out…

Doesn’t seem so pressing anymore. More like a box that needs to be checked to tell non expert young people considering vesting in the system that the designers built the system with the practical distributed compute limits in mind so it wasn’t an oversight that will obsolete the new user’s sunk cost. Approach Etherium seems to have taken with it.

Is there a true killer app for distributed compute that isn’t just about cheaper or earlier access to cycles and storage? I mean clear cloud Q might do that. Q nodes might even bridge what is fundamentally broken in Etherium.

Distrubted compute in a way seems like regressing a brain to act like a neuron or getting it to simulate a single neuron assuming brains compute anything and aren’t just fictions.

So upshot of the question seems to be when we there be a SAFE OS to run regular aps more optimally on today’s classical nodes at the app level locally. And the implication there is going from the ground up like Peruse, what is the optimal hardware target i.e. custom ASIC? And what will be the retrospective implications of having built SAFE from the upper middle up and down instead of from the bottom up- impossible as that might be in the first go?

How to get that stuff built into commoddity platforms or spread like a more popular Raspberry pi. Maybe an SAFE OS that runs in parallel on dedecated hardware for com but capable of more- but would implie adjacent legacy systems stripped of leaks?

1 Like

hmhmmm - supporting scripts from other platforms for easy migration of already done work would be cool too i guess :open_mouth:

2 Likes

Yes thanks, sounds a bit like how a backup agent works in a client/server network.

3 Likes

Thanks for the kind words of welcome @riddim, @Traktion, @19eddyjohn75, @Nigel, @jdabcarr.
I’m really excited to be joining such a positive and talented team.
Looking forward to getting to know you all once I start and get settled in.
David.

25 Likes

Have to admit that photo is pretty cool @DGeddes - don’t think I’ll be able to use it as a pro shot though…

1 Like

Why not? There are many @maidsafe members with a cool photo.

3 Likes