Introduction

πŸ“˜

The API Docs have moved to a new website

Go to api.safedev.org to find the latest version of the API Docs.

SAFE Launcher exposes REST APIs for applications to exchange data with the SAFE Network.

Access Types

SAFE Launcher provides two network data access types:

Unauthorised Access

Unencrypted public data can be accessed without any authorisation. For example, websites and blogs, which are made available for public viewing, require no authorisation.

Authorised Access

Applications have to authorise with SAFE Launcher to get Authorised Access. SAFE Launcher will grant an authorisation token once the user authorises the application. Applications will use the obtained authorisation token to invoke the REST API calls. These tokens are session based and thus will be valid only while SAFE Launcher is running.

SAFE Drive

The SAFE Drive directory (SAFEDrive) is created by default for every account. Applications cannot access the SAFE Drive directory unless the user grants the SAFE_DRIVE_ACCESS permission at the time of authorisation.

Users can use their SAFE Drive to store private and public data. For example, they can use it to store documents, images, audio files, videos, websites...etc....

SAFE Drive can also be used by applications for sharing data. For example, a camera app can store images in SAFE Drive and another image editing application can read the images from SAFE Drive.

Application Directory

When an application is authorised for the first time, a root directory for the application is created and mapped to the account. The application can store and retrieve data only from this root directory, it cannot access the root directory of other apps.

If the app needs to access SAFEDrive, it must send an authorisation request with the SAFE_DRIVE_ACCESS permission and the user must grant the permission.

Web Development

Since the web pages are supported via a web proxy, the endpoint for accessing the API should be http://api.safenet instead of http://localhost:8100.

The web proxy injects CSP headers to prevent mixing clearnet with safenet.

Here are the CSP Headers:

Content-Security-Policy: default-src 'self' *.safenet; object-src 'none'; base-uri 'self'; form-action http://api.safenet; frame-ancestors *.safenet; child-src *.safenet
X-Frame-Options: SAMEORIGIN

This prevents usage of inline JavaScript and CSS which is a restriction at present.

Limitations

  • The NFS modify file content API endpoint has been temporarily deprecated. Currently SequentialEncryptor is used via safe_core to write chunks as and when available which does not support taking offsets. Once the self_encryption crate can support taking offsets while also writing chunks to the network as and when chunks are formed, the modify file API will be re-enabled. At present the workaround for modifying a file will be to delete and create it again as a new file.