MaidSafe Dev Update - 12th July 2016

Hiring more MaidSafe employees? Great!

This must mean the funding situation has improved. News on that front?

I actually misread that line from Francis (it was early AM ) I saw “any more testnets” not “many more testnets”… my bad


Glad you said that. And I do not have the excuse of early AM [quote=“Savage, post:14, topic:10246”]
if (testnet6 < alpha) {alert (‘most likely’)} else {alert (‘Booyakasha’)}

Sadly no. It is “test 6 -> … -> test n -> alpha 1” Just that “n” is not far from “6”

“many more” unfortunately and not “any more”.

I made the same mistake.


Fish are not biting so I thought I would share the sunset :laughing:


This post was flagged by the community and is temporarily hidden.


I walk it every evening. Lucky indeed :slight_smile:


too cool…luv it… Looks like Sanibel/Captiva Island SW Florida

1 Like

Any word on when the API docs will be written for the new launcher API? Is there an issue tracking the effort that I may watch?


Any comment on the fact that the network was predicted to be destructive and run only a short time, but it is still alive and fine?


My bad!
I was expecting that the decision to never drop data relocation messages would cause pretty bad congestion problems in the network during churn (joining and leaving nodes). But it didn’t. :slight_smile:

We certainly will implement a smarter prioritisation mechanism at some point, that doesn’t just either silently drop some kinds of messages or keep them in the queue forever. But it’s good to know that the network can tolerate even that.


ETA on test net 6?

1 Like

If you have a few minutes left somewhere could you shine some light on the priority thing. We did some guessing/brainstorming in the topic below, but it’s quite hard to understand how things are now and why they are as they are. Will changes be made again before we go to alpha? Like I said, only if you have a few minutes :yum:.


(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)

There was a comment (I think by @frabunelle) that people didn’t use it a lot, so there was not much to become destroyedo of.

If you have a few minutes left somewhere could you shine some light on the priority thing.

When a node with a low upstream bandwidth is trying to send or relay lots of big messages (e.g. GetSuccess responses with immutable data chunks) that would take an hour to upload, that’s often useless: In an hour, the recipient might not be interested in the message anymore. And I certainly don’t want to wait an hour for a website to appear in my browser!

So eventually we’ll have to make the different network layers share detailed information about what bandwidth they have and what bandwidth they need, so they can make smarter decisions about whether, when and where to send messages.

But for now … we just drop messages! We introduced the priorities so that e.g. we never drop messages that are needed for maintaining the network structure itself. But less important ones are currently just dropped when the load is too high.

It’s not as bad as it sounds:
Redundancy - resending messages via different routes, storing data on multiple nodes, not trusting individual nodes etc. - is the responsibility of the upper layers anyway, and they will always have to deal with it: If a user kills their vault or gets disconnected, all the messages that node had in the queue will also be lost. The current crude prioritisation approach just adds a little more unpredictability of that kind.


Where can I get the latest launcher and vault for windows 7 , 64bit ?