Here I’m looking to get some feedback on ideas for improving the client facingAPIs. Building atop the RDF API implemented in the recent RDF proof of concept work, with the aim of simplifying creation of data, abstracting away some boilerplate functionality that comes with saving mutable/immutable data to the SAFE Network.
This scrappy wee chart aims to clarify just what would be built atop what: https://docs.google.com/drawings/d/1fbnE4tVPhfjfpXg4Ipzrkmzt12_3M7O61ShYpkbh2Ro/edit?usp=sharing
And while everything here is noted in javascript
style. These APIs (I should think), would be applicable in many languages.
Does that make sense? What are missing? What changes would you want to see beyond these?
And just to reiterate: I’m suggesting building atop current functionality, so we wouldn’t be losing anything. Just making life easier for app devs out there (I hope! :P)
Finally, to note, throughout:
MD = mutable data, ID = Immutable data.
Data
PUT
ting some ID on the network should not involve four lines of code (with a call for a cipher?!). I just want to save a file!
const writer = await app.immutableData.create()
await writer.write( data )
const cipher = await app.cipherOpt.newPlainText();
const address = await writer.close( cipher, true )
:(
An ideal may be something like:
await app.data(<data as a string>).save()
:)
It’s this sort of simplification (which we have abstracted in various apps in various ways) that we should aim to standardise.
I’m not suggesting where these live (at this moment), though if these abstractions are considered useful across all platforms, then I’d say there’s a strong argument for developing a RUST version of these and using bindgen to generate the abstractions across platforms.
Immutable Data
Creating ID should be as simple as something like:
-
data.add
/data.add(encrypt)
data.save
Mutable
Mutable data could by default apply some RDF schemas (the application name/version, eg), which could be useful when accessing data by other apps. But it could also not return this by default. Providing a simple way to work with objects/arrays.
-
mutable.add
// with option to encrypt or not -
mutable.schema
// ?? this instantiates the graph… (built atop the RDF layer) -
mutable.update
// or create or update the data mutable.save
RDF
As found in current RDF POC branch, but abstracting away the need for creating/managing a MD reference. More clearly to offer:
rdf.add
-
rdf.setId
// et all. All RDFLib apis would still be exposed as they are. -
rdf.schema
// ability to utilise a schema (that the API offers, eg:WebId
, see below for more. -
rdf.save
// when finished.
The data apis can be built on top of this (MD specifically, ID potentially).
I’m no looking into how exactly how we’re storing the RDF data (that’s for an RDF RFC).
RDF Schemas
As an start, schema
functionality would allow for easily creating an RDF with vocabs from a known type
. For eg, a WebId.
const profile = {
uri: 'safe://mywebid.gabriel',
name: 'Gabriel Viganotti',
nick: 'bochaco',
website: 'safe://mywebsite.gabriel',
image: 'safe://mywebsite.gabriel/images/myavatar',
};
The profile properties are all properties of a WebId. So we can automatically setup the RDF object using this mapping for a known schema type.
I’d propose built in schemas be only those needed for SAFE to function:
-
safe/web-id
(WebId) safe/ResolutionMap
safe/ResolutionMap/FilesContainer
Though we should build this functionality in such a way that it could be extendable. For example, imagine importing schemas defined elsewhere to use in your app:
import {Album} from 'schema.org-schema'; //pull in schema from another project
// Built in 'safe' schema
mutable.add({
name: 'josh'
uri: 'safe://lalallaa'
img: <xor url>
}).schema('safe/web-id').save()
// using an imported schema to easily create data:
mutable.add({
title: 'Muswell Hillbillies'
uri: 'safe://lalallaaasdadsaasdadad'
img: <xor url>
}).schema(Album).save()
Questions
- Do we need to log all file updates/creation in an MD? (How could a file manager know where all your data is? [that wouldnt work with a modified core that removed this, though…])
- Should we add version / app info to RDF data by default?
- Do these seem helpful?