Code Samples for using the API?


#1

Looking at the Github repos, I wasn’t able to find any documentation about the API aside from a description of the features of each major component. Don’t see any examples or anything specific. Also there is a link to “API” and that is confusing because it seems like you are saying there is a module that aggregates the rest of them or something, but really looks from what I get linked to that you are just saying “use all of the modules”.

Anyway, for example, do you have some code that demonstrates using the Vault, or Drive?

Also, which am I supposed to use, Vault, Drive or Network File System? Seems like they all have a similar purpose.


#2

Heya,

If you’re looking for Examples you want to check out. MaidSafe-Examples Gitbook. Currently it only has the Network Setup example which helps you setup a local network on one machine. As more examples are added they will start appearing in the same gitbook and the documentation should give instructions on how to expand on the features and how to get it setup.

This project will mainly show examples of using the API project and yes as you mentioned the API project is in simple terms a top-level API which exposes the other sub-module functions in an easier to use mode. If you choose to use the submodule API’s directly, then you’re of-course free to do so and skip the API project to access the code-base with. (Note: The API project and examples are currently being worked on. So do take the project with a pinch of salt and as examples start getting released, expect the reliability to increase.)

Network Setup example does just this(for Vault setup) by setting up a local network using a variable number of vaults which you can specify when you run the tool, it then stores the PMID keys for these vaults on this network. This tool will also be used for any of the new examples that get added on to serve as a testbed.

For Drive currently best place would be to look at the tests in the Drive project. However if you’re just interested in the usage of the project in your own code, then it might be best to wait for an example project to cover that.

They are quite different. In simple terms:

  • Vault - This is what essentially forms the backbone of the network. It’s your node(s) that you run to contribute / be part of the system where you store other user’s data/manage their data with the Vault’s various personas.
  • Drive - This project provides a VFS to access data on the network. This data could ofcourse be yours or shares which you’re part of and so on.
  • NFS - This is a network file system project that helps structured data management on the network.

What you use depends on your project and the platforms you’re going to run this project on. Like a mobile platform might not be able to provide a VFS for you. We have plans to provide an alt access layer similar to the Drive VFS for such cases. Again do remember these are being worked on currently, so if you’re looking for an example to walk you through the various parts of the system and teach you along the way, then stay tuned to the MaidSafe-Examples gitbook and it should serve just that. Hope that helps you a bit.


#3

Ok, thanks, I saw the gitbook and looked through the network setup thing before I asked the question.

Still unclear about which of the APIs to use for storing/accessing data. They can all be used for storing/accessing data right?

If there is a way to programmatically initiate or verify an existing MaidSafe Network File System, based on the name of that, it sounds like I could use it as if it was just an ordinary distributed file system, and therefore perhaps I could use it with any application that stores data? This seems the most flexible and straightforward option for most cases to me.

Why would I rather use Drive than access it like an ordinary file system?

Why would I rather use the Vault API to store data?

Thanks.


#4

Hi there,

You’re right that “MaidSafe Network File System” is a misnomer at the moment. It provides a psuedo-RESTful interface to the vault network - it’s not really a NFS.

It probably is the most straightforward way to immediately put and get data to/from the network just now. However, we’re keen to steer devs more towards the API project for a couple of reasons:

Possibly the most compelling is that we’re thinking about making the existing NFS interface private, and replacing it with a “proper” NFS interface. This would take over from “Drive” as being the way to store, update and delete files from the network. Drive would then just become a VFS whose callback functions would each call a corresponding NFS function.

This would make the NFS accessible on all platforms - even ones which don’t allow VFSs (e.g. mobile platforms). It would also fix our other main issue with the existing NFS RESTful interface; namely that the data stored via these methods is assumed to be already encrypted.

Unfortunately, there’s no real way to validate that data passed to NFS::Put is encrypted. Our concern is obviously that a dev writes an application which sends unencrypted data onto the network, expecting that it’s somehow encrypted by the network. Another problem is that a malicious actor could put unencrypted illegal content onto the network this way, content which would end up on innocent users’ PCs. We can handle that by having all chunks obfuscated locally with a machine-specific (i.e. non-deterministic) function, but that adds overhead.

The advantage of the Drive interface is that it is a proper FS interface, and it takes care of encrypting the data before putting it onto the network.

So, my recommendation would be to have a shot at the NFS API in its current state if you’re really keen to start validating the network, but to expect this to change/break in the not too distant future. The best option is probably just to watch the Examples project - it will show how to create user accounts, authenticate onto the network and mount the Drive VFS.

All the best,
Fraser.