SAFE Network Dev Update - June 20, 2019

Las time I heard it come up in one of his qa sessions was years ago. He really liked the “idea” of it and wanted it to happen, but it was way early in development and he was skeptical. The word vaporware may have been used


It has been, I met Andreas in Texas a while back, interesting to say the least. SAFE is huge, it takes a lot of time to understand how we do this, but not why. The very best we can do is show it running then why is obvious, how is for the techies,


I just moved and got a killer deal $39 per month for 200/200. Bring on those vaults!!

Great update again folk


I’m hoping his opinion has changed. Just quoting what I remembered. My interest in following the day to day has come and gone, but I’ve always had faith in the team and long term vision. Glad it’s finally all coming together.


nice I am sure an event headlined by andreas got some new people and old friends to give MAID a look. And like verified on exchanges people at that lol. I think one day marketing should shift focus to the no-coiner but for now crypto people are the most likely to invest.


I’m pretty sure if the tech is proven to work he’d be more than willing to investigate and embrace it. He was afterall willing to risk his reputation somewhat in the Bitcoin community by writing ‘Mastering Ethereum’ with Gavin (after first having written ‘Mastering Bitcoin’ of course). This didn’t happen until 2018 however, over 3 years after Ethereum launched.


Wow, I am 26th,…,… great news here, today , again . huh ??


Ah, the ol’ “Create hype and marketing by actually getting sh*t done” tactic. Nice. :smiling_face_with_three_hearts:


Thanks for sharing weekly updates.



another great update! thursday is my favorite day of the week :blush:


That makes two of us. And I’m sure many more of our comrades share the same feeling! :business_suit_levitating:


The WAY the community goes lit for each of the dev updates! :fire: Damn!
Thank you guys so much for resting your hopes on us! We’ll be sure to get this ship going with your support and not let y’all d’r’own in this ocean of threats and breaches called Clear-net ! :wink: :slight_smile:


Nice one @yogesh :clap:


Really loving the way we are steering all the Front-end & Back-end projects, doing every bit to stay on top of the game! Cheers to the team and a big thank you to the ever inspiring community.


I won’t believe it till I see it… :wink: Update good as always…


Nice to see more interaction from the dev team. Definitely seems a lot more positive around here! Can’t wait to see the safenet for real!


may I inform you there is an alpha and a mock network and vaults that run locally? all you need is to download a file? (and follow instruction to reproduce the network and all the components)


Aye, we really want to avoid disruption as much as we can too.

Some ideas we’ve had are that the ‘low level’ APIs should stick around and will be updated for new data types etc, as this will form the basis of a layer above that, which we really want to make much more dev friendly, and that will probably be the initial focus.

(eg, the idea that you could do put_immutable_data( <data>) and not have to worry about creating a writer, writing the data, and then adding a cipher before closing the writer again… removing as much boilerplate as we can in this new layer).

We’re writing this in Rust as we’re building out the CLI (, so this is hopefully what will become the basis for the new, more streamlined API (though I doubt it will stay in the CLI crate). And we should be in a position to more easily create the FFI for other languages from this.


Thanks Josh. For me the relevant part atm is any breaking changes to the lower level (ie safe_app_nodejs) API rather than what is built on top. So any changes to existing API operations at that level, and ways to learn about and try out additional low level APIs for new data types.

Later I can start to use the higher level / CLI API and consider changes to the SafenetworkJS API which I’ve built to do a similar job.

I think it is good to maintain both levels. :+1: Most use cases will be fine with the higher level, but I’m sure there will be some requiring low level access to optimise for performance, PUT costs etc too.


I’m also interested in how services will be supported in future (as you know :smile:), and have adopted my own conventions for this right now.

I’ve realised that in some cases I want to create a service that can fall back to ‘www’ when accessed by apps which don’t understand the service. To achieve this I create a normal web service on the subName, but pass it through my own fetch and will handle it differently if the subName fits my naming convention. So for safe://files-ldp.happybeing the standard webFetch() will serve index.html or list the container, but an app built with SafenetworkJS will provide an LDP compatible fetch() response instead. I’m about to try and integrate this with storage added to the SAFE WebID profile, so that’s why I was wondering if I should wait for breaking changes.

So can I also assume that the current experimental APIs will also remain supported/unchanged for a while? If those disappear it will break the Solid compatibility I’m working on.

I think that’s all my questions. :wink:


Totally agree. For the lower levels, things are fluxxy right now. But I think the aim is to maintain very similar apis to what we have now. There will of course be changes, but I believe that’s the aim. Maybe @lionel.faber you can give more detail there.

For my money services should likely be handled by RDF. So getting any ResolveableMap schema could list many potential services, and your application could choose what it prefers or grab the default. In that way a browser visiting safe://happybeing can choose to grab the website entry, or an email app might choose the inbox entry. Though non of that’s set in stone. It seems like a nice way to leverage RDF to me.