SAFE Network Dev Update - March 28, 2019

NodeJs, Web, Android, .NEt, Xamarin and soon python. These technologies have their own communities. What happens when you turn up to a community and give them a new toy?

In see stellar adoption in the near future.

So exciting.

Edit: Now this is a versatile graphic, poster, online advert, Twitter post, Facebook status post. This graphic is clean and professional, puts accross it’s message well.

Should be placed up on university computer science notice boards.

“The distributed internet needs you”

16 Likes

I think he’s talking about making some soup. Sounds tasty!

9 Likes

:slight_smile: Will definitely do once we are there. Sorry, I was just trying to bash in a reply before a Friday afterwork pint and enthusiasm got the better of me… I simply meant that one of the most used python web frameworks (flask) can be hooked into the library and work well asynchronously. Incidentally, Celery (the job/queue library) is also used in many distributed applications, so future is bright!

7 Likes

Fantastic update team! Lots of good stuff happening here. Two thumbs up.

11 Likes

Ironically, the Rust logo is also missing.

I already asked this question in December: Is there a place where the way to use the authenticator in a rust program is explained? I didn’t get any answer on this specific question (but it was part of a much longer post).

3 Likes

Hi @tfa, is the auh CLI of help to that particular question? or you meant a Rust app which needs to authorise against the authenticator (either auth CLI or the one in browser)?

3 Likes

will this delay of publishing the whitepaper (up to 1 year) caused by the academic review cause any delays in the relase of the SAFEnet?

No it won’t, any delays in publishing won’t impact the release of code.

13 Likes

Well done you hard working devs. Sorry to see some of the team move on but I’m sure they will keep an eye on things. I can smell Fleming. Can’t wait to see where we will be at the end of April. Possibly a good lunge from the milestone.

6 Likes

Are these parsec publications written by some mathematicians working at maidsafe?

That would make a lot of sense - wouldn’t it? You might even be able to just import and use safe_app/safe_authenticator instead of contacting the client libs and benefit all the way from rust and it’s security …?

Haha - and @dask is hiding nothing xD pySafe will make your heads spin :smile: :stuck_out_tongue_winking_eye:

3 Likes

Maidsafe, and beyond. To write a paper you need to use maths, if that makes you a mathematician then yes, but none of the authors is pure maths only people. So I am not sure what you mean really, maths is part of Engineering, just a tool like any other :wink:

11 Likes

It was a simple rust program creating an account in the network, but not an app that needs to authorize against a running authenticator.

If you follow link to my post in dev forum, you’ll see that I wanted to use safe_authenticator sub-project from safe_client_libs crate but I don’t know how to do that.

I found a workaround by creating an example program inside the crate, but this is certainly not the proper way to use an external crate as a lib.

The safe-authenticator-cli has just appeared and could be used as an example but:

  • A complete real program is not a documentation (a proper documentation is composed of explanations illustrated with small examples)
  • It is too complex for my need
  • It only works on mock (my need was for a real network)
  • It isn’t ready yet (because there are references to personal GitHub repositories)
4 Likes

Right, trust me, I can see and understand your frustration, we effectively faced the same type of problems when developing the auth CLI, and this is why I believe it’s a good thing to do, to uncover any missing piece/feature, and learn/understand better how is it that the Rust API in safe client libs can be enhanced/improved.
Thus, our so far experience with auth CLI triggered some internal discussions about this specific aspect you brought up in that thread (and now), and there is already a plan to start looking at how to expose a similar type of user facing API to those you can find in FFI layer, but from the pure Rust layer. As you noticed already, the reason there are references to personal GitHub repositories is exactly because all this. So we had the option of saying “let’s first solve those issues before sharing a PoC CLI”, or “share it so people can learn, help us in the process by testing it, providing ideas and criticism, just like we also do ourselves”.
So what I mean is that, as you correctly say, this is not finalised and there are several things to work on yet, like those you point out: documentation, Rust APIs in safe_client_libs so you could depend on them from an external crate, make it function with real network and not only mock, etc.

Now, there are also some other aspects to all this, which I believe will be a big challenge for all of us if we want to support our SAFE users:

It’s clear that as we progress in the project there will be more and more different type of applications with different type of requirements. Such requirements could simply be “have a simple UX”, and such a req could lead devs to try to create alternatives to how users log in to the network and authorise apps.

This is a big topic I’d say, and we could even start a thread for discusing this, but in summary, we have to be careful and try to work on solutions that end users can effectively trust, e.g. if every application embeds an authenticator, meaning that you have to enter your account’s secret and password in each of them, we are creating a very risky environment for users, no doubt about the bad UX due to user exhaustion.

This is why we believe we need an authenticator which can manage the credentials, and apps only connect to the network after credentials were provided by this authenticator, thus apps never get the account’s credentials but just their own and the fixed set of permissions. If having embedded authenticators in apps becomes the norm rather than the exception, it’ll become too risky to use any application out there.

We have to work on having solutions that support our users (good UX) and applications (good integration protocols, we have now only one which is the system URI protocol) so they can manage credentials and permissions solely from a very well trusted authenticator.

16 Likes

Hate to see folks leaving in key positions yall just had been fighting to fill such as networking but such is life, hope he did not take a look at the ask and go holy hell we need to make what work how?!? :open_mouth: , :laughing: . Road to Fleming continues onward, best of luck on the path forward. Maybe enough internal talent to pick up some of the slack too if needed or those eager to learn and try new things.

Some of these dev updates begin to blend to me, we updated __ lib from 1.1 to 1.2 etc, or change __ protocol to __ or we did some testing here on this and saw this behavior, would be good if we could see we have a simple checklist view of ____ features/functionality left to code for Fleming listed somewhere. Doesn’t matter if week to week things don’t get checked off, as many times it takes 2-4 weeks to knock out a hard feature but getting a view and perspective on what features we lack would be helpful.

1 Like

Engineers do not think this way, at least not decent ones. We look and say hey a challenge that I am going to succeed in.

3 Likes

Technology always has limitations in a given time period(which do adjust for the better as time progresses), current modern day if someone said Jeremy I need you to write an API that needs to call 20 distinct data sources and the hosts are on 5 different continents and aggregate all the data its a 1GB payload and I need a response in under 1 millisecond to my client server and I will pay you 1 million dollars, I am going to tell you hell no, that is impossible and a waste of my time with current technology limitations. Maybe that makes me not a dreamer, I tend to stay rational, just like I think building SAFE network is entirely possible as a distributed secure network on top of the internet is entirely possible, do I think I could stream videos or download content as effectively as clear net? To me the rational answer is likely no, not for a long time until lots of complex caching happens between requester/source destinations and we have a large # of nodes in the network hosting data. But you gotta start somewhere :slight_smile: .

This is just a basic application of the paradox that if God is almighty then can he/she/it create a rock so big that even God cannot lift it.

Your example does not fit with the current project and yes there will be problems out there that cannot be solved by todays technology. But hey how do you think new technology is developed, its by engineers applying physics and creating that technology. Your “too big rock” is possible with known physics (barring the impossible 1millisecond in all cases) but needs to be developed if its not already by engineers. Also the process of design takes the paradox into account and only designs projects that can be developed with current or create-able technology. Otherwise it usually fails early on due to a lack of funding, since funders take the time to consider the paradox as applied to engineering. As an example I created a new technology for my thesis that people are still using today on the internet. And no one had done it before and did not exist, yet the University put up the 500$ (1970’s $'s) for me to actually do it, because the proposal showed how I could apply known physics/maths to do it.

But back to the project, the word from the developers is that the problems (research) needed for the project has already been done and its now the hard work of writing the code, testing, adjusting, testing, testing, testing, writing further modules (eg safecoin), testing, adjusting, testing testing, testing. So no I do not accept your possibilities.

Also smart people are looking to expand into areas that interest them that were not necessarily areas that interested them 5 or 10 years ago. Being in one project for too long can present problems for young, highly motivated, very smart people because it can limit their development in broadening their expertise. As such they need to move on if they wish to not be stuck in one area of employment.

EDIT: so expect more to move on before safe is launched. Its not a negative and any good business manager knows some people will move on within the life of a long project.

3 Likes

At least you understand most of it. I dont read most of it since its alien to me. But try to read i must, even if understand i do not :grin::see_no_evil:

1 Like

I agree with this, and the Authenticator app is perfect for this, for the reasons you mention.
I just want to point out that there is more to the picture than this. I’m sure you know, but I’ll just put it here for the broader discussion :slight_smile:

There are use cases (I have now with the SAFE.NetworkDrive for example), where the flow is completely different, and it just doesn’t make sense to use the Authenticator app for it:

The user gives the SAFE.NetworkDrive app a mnemonic, an entropy, to derive n SAFENetwork credentials from, since every new drive is a new account. When creating new accounts like that, derived from the mnemonic that the user is supposed to remember, it makes no sense to create those accounts (or login to them) through the Authenticator app - it gives no additional security. It would be to try press a square peg through a round hole.
Also, there’s the new accounts for creating drives that are supposed to be given to others as a thumb-drive, i.e. sharing drives. This does not use the mnemonic, but this also would make no sense to use the Authenticator app to create it.

I’m sure there will be more cases like this, which is part of why I made a NuGet pkg out of it (another part is that it’s a cleaner way to keep it separated from my app(s)).

10 Likes