SAFE Network Dev Update - July 4, 2019

Thanks so much to the whole team for all of your hard work!


Every week it seems like there’s new people. Once it seems to settle down, I think everyone would love a little video with just maybe a 2 sec clip of each official MaidSafe-r. Feels like there’s lots of hidden heroes :heart:

Or is the company page being filled in with a little on each person? Genuinely interested in the company growth :+1: :100:


Another phenomenal update. It’s hard to believe how much has been accomplished in just the last month or so. From all the progress on GitHub, it looks like things are going to be outrageously exciting from here on out. Congrats to Dug and Ceilidh on the promos. COO and Head of Marketing at MaidSafe…talk about dream jobs!


That’s sad. Maybe this is why they introduced Figma mirror application but sadly it requires login and sharing doesn’t work.


Amazing progress! The version history history :heart_eyes: super feature rich yet understandable. Looks absolutely fantastic and it’s honestly so so so much more than what I had imagined. Glad this paradigm shifting tech will have the UX to match :smile:

This project, or should I say movement? Becomes more and more inspiring by the week(ly updates). Cheering you on @maidsafe


I’ve raised this as an issue on github BTW, hopefully we can get it fixed soon. Thanks!


Loving that video :slight_smile:


Great job team. Was waiting to comment until those Figma slides worked, but boy-o-boy are they fantastic. User cards, version history, integration into messaging… just wow. It was always part of the dream, but seeing it mocked up and knowing how close the code is to making it a reality is really, really cool.

Any chance of getting a simple ffi hook for the cli? Just ‘send line’ and ‘grab output’ would be great; some of what it does is really laborious and likely to be bug prone to implement with the python bindings and would be a great out-of-the box hack for some high level stuff like syncing. Can’t wait to get the updated libs and march onwards.


Congrats @Cgray!
Loving the Perpetual Web Browser UX, really brings things to life


I never expected to see this level of sophistication, starting to understand what all the buzz is about.


Everything moving forward on so many fronts I honestly find it hard to keep up! Thought if I focussed on this project it would be manageable, but not so!

Yay for another Glasgow meet-up though! I’ll try and bring some more folk along this time as well…


This is just the tip of the iceberg. More to come in the coming months :wink:


This is one of my favorite updates as it continues the past couple weeks’ fervor without slowing, and I’m overwhelmed by the sheer amount of content to where I must continually revisit it, and every piece of it is enthralling. The best feeling of being overwhelmed one can have! No more messing around!


look forward to the next 3 of those milestones posts. Really hoping to see the market react to progress being made and not just the “poloticing” of the few daytraders that make up the small volume. The last little while has been all about decisions exchanges have made, but I think soon people are going to focus in more on the actual project itself and price in some major accomplishments by buying more for long term HODLs.


I cannot really tell exacty when, but we are already thinking of our next milestone for CLI to be about DNS stuff towards having everything we need for uploading and publishing websites using the CLI, and then be able to fetch it from the browser, i.e. once we have the CLI with first implementation of DNS (probably in the next 2-3 weeks), we can start coding some FFI on top of this crate’s API which is what we need to bind the browser functionality to start showing the pWeb.

Exactly, this is why we strongly believe we need the API that we are coding in the CLI crate, we need all efforts to be put in one single implementation of all these concepts like FilesContainers, Wallets, SAFE-IDs, wallet operations, if all the effort is put by us and community to make sure this is error-free on the CLI crate, we then only need a thin FFI layer which is just a 1-to-1 mapping with no logic, just converting form one lang to Rust and adding no other extra logic which increments the chances of introducing bugs, and different bugs in different languages. So we are on the same page, and very happy we finally are on this path now with client APIs


Nice update Maidsafe devs,

Congrats @Cgray :+1:

Great to see The Perpetual Web Browser :exploding_head: :clap::clap::clap: can’t wait to play around with it…



Using my laptop I can access the Figma mockups :tada: and am very impressed. Good ideas and a very understandable presentation.

WebID v SafeID

There’s one feature that doesn’t appear to follow conventions to maximise Solid compatibility, and I don’t think this has been discussed with the community - so am curious: what’s the proposed SafeID implementation, including naming, and what is Maidsafe’s approach to compatibility with Solid/WebID?

For clarity:

  • Safe ID appears to have the form @name
  • Figma mockup shows browser recognises this directly given a URL with the form safe://@name
  • a Solid ID / WebID is a URL with a fragment, and I don’t think URLs can contain ‘@’. So a SAFE WebID would be something like safe://id.happybeing#me

If we deviate from the latter, it makes it harder to provide compatibility with Solid apps and harder for people already familiar with WebIDs, so again I’m curious about @Maidsafe’s direction here.

I realise Solid compatibility is not the b-all and end all here, but would like to understand where @Maidsafe are headed.


Glad to see the merge into one format including data type and type tag :slight_smile: @joshuef @bochaco
Getting rid of the separator looks like a good thing to me =)

Little annotation: I’m not sure if encoding should be used in this context because it might be confusing with the byte encoding itself… Data format might be less confusing and more accurate anyway? (and doesn’t sound like you somehow thought you need to come up with your own data encoding because the rest of the world is doing it wrong for all those years… )

Very very cool those concepts for the perpetual Web browser!! =) (while in this line of changes even the change of ownership for the continuous auction naming system would look very nice - would be awesome if a name resolution plugin could come with its own history view too :face_with_monocle:)

Ps: just checking @joshuef - the bytes

Are being "cid"ed when being encoded to base32z aren’t they?

Because if not the correct version of the sentence would be ‘[…], base32z base encoding once and forever because there is nothing indicating the base encoding and even the first byte indicating the version of the link is base32z encoded thus we have no option to change the encoding in the future’ (only wanting to make sure we’re on the same page - choose the encoding of your liking but please don’t produce statements that make it look like it could be changed easily if it cannot)


Great update and great work! The dev updates become more and more impressive as time goes by. I have been very excited to see so much emphasis on a good cli implementation. Just to second @happybeings statement, IMO the following service.pubname format should be the default representation, ‘safe://id’ is literally the root of the URL.

The @happybeing format provides a means for having a convenient shortcut to someone’s safeid that could be recognized by the browser in the same way we use those links in forum posts here.

So rather than either/or, can we have both formats?


No, they are not in this implementation, moving forward we can have something like CID or our own version of it so we can also encode the base encoding chosen. With this you have no way to know which base encoding was used but just assume it’s base32z.

EDIT: I have to correct myself, I just double checked, and even that we are not using a CID, but since we are using multiformats::multibase which does prefixes the encoded string with a code that tells you which base encoding was used (, we are able to generate XOR-URLs in different base encodings and be able to decode them (regardless of the version we have for our format). We allow to choose different base encoding from the CLI with the --xorurl <base> arg