Hello everyone,
So, we are on the cusp of beginning another sprint, as @Krishna_Kumar outlined in the previous dev update, last week was the second week of the RUST-5 planning and this has overrun a little into the middle of this week. We expect this sprint to kick off in the second half of this week and we anticipate that it will take around 3-4 weeks to complete. The deliverables and duration have yet to be fully finalised, so may still be tweaked and altered slightly, but I will set out in this update where we hope to be at the end of this RUST-5 sprint. The current deliverables and timeframes will be finalised once all the tasks have been transferred from the RFCs into JIRA tasks and time estimates associated with the same tasks added.
You can find all the RFCs here
Active (going ahead in this sprint)
UDP hole punching
Launcher as a service
Connection Management
Agreed (will be happening in future sprints)
MPID Messaging
Rejected
Launcher not as a service
Address relocation
The team (MaidSafers and Community Safers) spent a lot of last week thinking, creating, debating and poking these RFCs, so they would be as detailed and complete as possible and ready to be implemented via the subsequently created JIRA tasks. As we learned from the last sprint, we need to make the task descriptions much more detailed in order that they are easier to understand. This will facilitate SAFE bounty hunters picking up and completing tasks, continuing the drive to increase community involvement in the development process. As ever, this process will continue to be fine-tuned and evolve and everyone’s feedback is welcome. For example, our RFC process has developed as we progressed through planning; improving commenting and implementation blueprints, so that with each iteration of the process we hope to make it easier to contribute and become involved in the people’s network.
The main theme of this sprint is delivering the ability for everyone to easily connect to a stable network remotely via their home desktop computer (tier-one OS only just now). So a lot of effort in RUST-5 will be working toward accomplishing this, whether these are tasks in crust regarding UDP-hole punching; routing tasks related to Connection Management or more general tasks that target overall network stability created from Github issues / bugs that have been found and logged by the community. After this sprint we aim to have a stable SAFE network that is constantly up and that is easily accessible by everyone via desktop installers. So this should be a really exciting one!
As if that is not enough, we also want to focus on making life easier for community SAFE app builders. This sprint deliverable is equally as important as the last and complements the main RUST-5 theme; to encourage and improve community engagement with the network in a stable way, with no dependency on any of the core libraries. This will make it possible for any app from any language to communicate with the App Launcher. The Client guys have been busy outlining this in the Launcher-as-a-service RFC. This is quite a paradigm shift so I had to turn to @ustulation to explain this to me (luckily he is patient) - here is how he explained it to me:
A feature of the Launcher is that an app has to re-negotiate security parameters every time a fresh connection is made. Therefore, apps have absolutely no incentive to cache those parameters for future use, easing revocation of permissions considerably. For example, once a user decides not to give an app permission to mutate the network on his / her behalf then the next time an app tries to negotiate security parameters, the handshaking would fail.
Also account creation and login happen only from Launcher, i.e. it is the SPOC (Single Point of Contact) for the SAFE Network. This means that no app gets to know user credentials and hence will never have any knowledge of a user’s MAID, MPID and other keys and cannot tamper with a user’s login session packet which would otherwise be disastrous as the session packet contains all information needed to know everything about a user on the SAFE network - signing keys, encryption/decryption keys, data, etc.
Another plus is that apps won’t need to interface with any of the MaidSafe rust libraries, they can be built without any knowledge of how to do operations (e.g. create a versioned private directory) on the SAFE network. They will just have to comply with a very friendly versioned Launcher document which exposes JSON structures for performing an action (i.e. create a directory) and parameters that are needed to perform the action (e.g. name of the directory, whether publicly shared or private, etc.) The onus will be on Launcher to do the translation, utilising the MaidSafe crates to complete all network operations, security operations (encryption / decryption, signing and stamping ownership, etc) and interpret data (versioned / unversioned, structured / unstructured, etc). So, this eases the life of app developers a lot! They will not have to overcome a steep learning curve to successfully code and contribute to SAFE.
It was decided to accept the Messaging RFC and this has been moved to Agreed, however a combination of limited resources and the fact that it is adding features and not fully in line with the overall theme of the RUST-5 objectives mean that this will be part of a future sprint, but not RUST-5. A lot of effort has gone into this RFC and this will not be lost, just slightly delayed. In other non-sprint news the renaming of the safe_client module to safe_? as mentioned here is still planned and will probably happen later this week once a new, more accurate name can be decided upon, so keep an eye out for that.
So, a really exciting few weeks ahead and one that will focus on inclusion of the whole community. Keep your eyes on JIRA to monitor our progress and claim one of the tasks if you feel sufficiently able.
we won’t forget to mention that aspect I am sure.
, but this isn’t gonna be the case at least with this sprint. The exact point you mention is currently documented as the first point in 
