MaidSafe Dev Update :safe: 28th September 2015


Planning phase for the Rust-5 sprint began last week and slack channels have been noisier than ever! The reason for the noise is that the team are now following the RFC process with all significant changes moving forward and the new process is having the desired effect of increasing discussion and collaboration! It is great to see some external RFCs being submitted, awesome to see the community getting in on the act!

Last week was the first of the two week planning phase of the Rust-5 sprint, the maintainers started to plan for the features that would be implemented during the sprint. The RFC for the change/feature is raised by the maintainer with a detailed description including code snippets to explain how the feature is expected to be implemented. There were few main RFCs that have been raised last week, Messaging, Launcher Approach 1, Launcher Approach 2, UDP hole punching, Address Relocation in Routing, Improvement to Unified Structured Data and one more in the pipeline for Connections Management in Routing.

Few RFCs are confined to changes only within the library such as UDP hole punching in CRUST. At the same time there are RFCs like Launcher and MPID messaging which require changes to be made across multiple crates.

Two RFCs are raised for launcher implementation, both of them explaining different possible approaches. Both the RFCs are actively discussed to identify the best suited one.

During this week, the maintainers will be reviewing the RFCs raised from other dependant libraries. For example, Launcher RFC will be reviewed in detail by members from Vault, while MPID messaging will be reviewed by the Client guys. This process of reviewing peer RFCs is to ensure that the RFC provides sufficient information needed for implementing the feature. With this process in place, we are hoping that the community members will benefit from getting more input from the RFC before they pick up a task and execute it easily as a part of the bounty program.

The scope of Rust-5 seems to be big in terms with the features and also the time that would be required. We are therefore planning to get the RFCs merged by the middle of this week after the review is completed and then fully spec out the tasks in JIRA. Finally based on the total story points the actual scope of the sprint will be determined(maybe move a few RFCs if needed to the next sprint for implementation). We would likely see rust-5 sprint span 3-4 weeks, but we must wait with our fingers crossed until we decide the features that would actually make its way into the sprint. We will of course let you all know as soon as this has been decided.

On a sidetrack, I have been working on a tool to help the QA guys. As most of you would be aware, we are testing our binaries/examples in the droplets (more like a small network wide test). Setting up each test cycle has been a time taking process and the same manual work had to be carried out on 10-20 droplets. Phew! that seems to be tiring. So we decided to pull out a simple command line tool that would help in setting up an environment across droplet endpoints that would facilitate with running our libraries examples / binaries. Hopefully this reduces the time taken for us to set up a throw away debugging environment.

One more exciting sprint is shaping up.

Here is the link to the weekly transcript


Rust Bitcoin Recently published a new iteration of the rust-secp256k1 library which is used for Bitcoin’s ECDSA encryption system(for making public and private keys and for making and signing transactions with those keys).

So, with a little UI magic we’re going to have an intuitive bitcoin wallet all rust. and having a bitcoin wallet also means its also a maidsafecoin wallet.

Looking forward to sharing this asap, and for this sprints process seeing messaging and routing and udp hole punching take hold.


Sounds like exchanging maidsafecoin will be easy peezy!


What does RFC mean? Xxxxxxx

It’s Request For Comment :slight_smile:



I’m sorry for bothering, but…

Would it be possible to ask people SAFEcoin for Messaging?
For instance something like 0.01 SAFEcoin per character or 10 SAFEcoin to message you.

In this way you can allow family & friends to message you for free, while strangers have to pay you to message you.

It already solves the underlying problem you address here, the sender pays until the message is accepted by the recipient.


Can you explain that better please. It sounds like the sender gets their pays back. I thought the sender paid a set amount and the receiver paid nothing. No reversing when message is accepted.

The senders outbox is limited creating a max which is like paying. Then any message larger than the max message(100KiB) is chunked and the sender pays for the chunks. Like todays postal system where you pay for the stamp.


I cannot marry this with what @seneca said :frowning:

Are you saying that they don’t pay anything but are just limited to 100KiB per message. (Larger pays for chunk storage).

[This is the option that I thought it was]
Or is it you pay for the message, and if the message is <100KiB then no more is paid and if larger then sender also pays to chunk the data and the message contains a datamap to the chunks.

Yes, but unless a receiver gets the message from you then you are limited. So this is like a payment in that you cannot spam like mad as the network only allows you a limited space to send. If messages are less than 100KiB (in total for full SD + serialisation) then they are free, but still limited to the size of your outbox.


  1. Outbox limited in size (you need receivers to read and retrieve the message.
  2. Messages limited to a few Bytes (depending on other things in SD) or they create chunks and you pay for these.

@dirvine, Go away! Aren’t you supposed to be on vacation? :wink:


My guess is he couldn’t keep his mind off SAFE for all that time and got itchy to continue. :wink:


Yea that’s all done and dusted, so back again to add in some nonsense to the forum again :smiley:


Sorry to keep at this, but I need to fix my thinking on what happens.

So are you saying that a user gets one SD for all the messages they are sending and beyond that they can send no more till the receivers receive some messages? OR that the message overhead uses up most of the SD space and the user gets “a few bytes” for the message, and the user is limited to a set number of messages outstanding??

What if I message my kids and grand kids about a BBQ? am I going to be limited to the first (say) 10 sent until one of the lazy sods reads one, then I can send another?

In the long term I was thinking that messaging would allow IoT devices to send short communications to each other, but that would be almost instant reading of a sent message

EDIT: is there already a document that has the up to date messaging described/protocol

Yes (sorry in mumble rfc meetings just now so going fast)

Yes but the limit will be several thousands of messages so you will be fine. Here is the full convo so far which will help.


Ah it is making sense now. Free messaging, my IoT devices will like that and be able to sent intelligent messages rather than trying to put it all in one cryptic message using 3 digit codes. :smile:

Whew thats a relief. I did have a lot of kids but don’t have that many kids and my eldest grand kid still has 5+ years before we can expect him to have kids.


And, If the RFC don’t change, the size of inbox/outbox is 128MB. Remember that only the MpidHeaders is stored in this box.


I am so impatient about the SAFE mail and instant messenging solutions!


Woh, so if the email was sent as a fake but didn’t come from the actual senders outbox it’s canceled! Am I right on this? Very cool if so. Also limited outbox stops spamming, also very cool. But if someone’s inbox is full they won’t get mail?? And if you are the sender your outbox is emptied automatically? If anyone could explain the reasoning behind these or if I misinterpreted, I haven’t checked out the rfc yet so if the answer is there simply direct me to there.

Edit: so if it’s only the headers stored in inbox and there’s 128MB then you’d have a ton of unessasarry Mail likely so I could understand not sending to inbox as it could be vacant and be seen as unnecessary junk to the actual network. But I wonder about archiving