A standard sharing experience?

Build a Solid App Developer Experience
1

As an app-developer it would be nice if Solid offered some advice on how items should be shared between friends, such that I could easily offer sharing of my app’s items in a standardized way.

Example:

  • I am playing with a web-app that allows me to register aircraft models, flying locations and writing a journal of when I flew what, where and for how long.

  • At some time I am invited over to a friend and gets to fly some of his aircrafts,

  • Now I want to register my flights with his aircrafts and I want to use the models he has registered in his journal, directly in my journal, by linking to his models instead of my own.

  • So I ask my friend to share his model with me. How should he do that?

You could repeat the scenario with an app for slideshows where I want to include my friends slides, or photos or articles or …

Ideas:

  • Sharing starts with a standard “Share this” widget I include from a Solid library.

  • The “Share this” widget generates a little “Share” icon which I can click and get a popup with a few choices.

  • I can share the item by copying the item’s URL and sending it by e-mail to someone.

  • I can share the item by entering the WebId of the recipient. The system can then grab the e-mail from the recipient’s profile card, add the recipient’s WebId to the access list of the item, to grant access, and copy the item URL to send by e-mail.

  • I can share the item by entering the WebId of the recipient and then the system will both grant access to the WebId and post a suitable message in his/her Solid inbox where I will be available to use.

The last thing is some kind of “Copy here - paste there” functionality. Unfortunately it opens up for spamming.

3 Likes
2

Great point, glad you brought this up. A few of us working on the solid developer kit had this exact discussion earlier today. We’re planning on incorporating some mechanisms that I believe addresses much of what you’re proposing. What we have in mind is:

  1. Helper library that makes it easy for developers to manipulate WebACLs in an intuitive, straightforward way. While these are just RDF and technically you can use something like rdflib to manipulate them directly, for many reasons we think it improves the developer experience and quality of the code to provide something specific for people.
  2. To your point about a “widget” - in solid parlance we call that a pane, and we have one planned for sharing that can be easily incorporated into apps and provides some interface actions for WebACL management / sharing.

This is just emerging from the planning stages now so can’t point you to implementation on github just yet, but we’re not very far off either. Will be posting updates with pointers to github (and supporting docs) in here as stuff gets pushed.

2 Likes
3

Hi @justin, are there any public resources to take a look at regarding these utilities/library you are planing to provide?
We are working on similar ideas around such type of utilities for the SAFE Network client apps. @joshuef has been working on a PoC already, so perhaps we can share/exchange some ideas if you are interested in.

2 Likes
4

Not as I write this, but in a matter of weeks there will be. Always interested in exchange of ideas!

4 Likes
5

Hey @justin,

Here’s what I’m imagining could form part of a web dev toolchain (so a JS focus):

I’ve set about defining schemas as JS modules. The aim being that we can then use these at run time to provide feedback to devs / warnings etc, and provide validation.

So using a Book schema pulled from schema.org, using a POC lib for sheperding data

import shepderd from '../src/shepherd';
import { Book } from 'schema-doter';
import rdflib from 'rdflib';

const sampleObject = {
    'id'            : 'safe://here',
    'author'        : 'Josh',
    'publisher'     : 'Somebody'
};


let rdf;

rdf = await shepderd( sampleObject, Book );


rdflib.serialize( null, rdf, sampleObject.id, 'text/turtle', ( err, result ) =>
{
    console.log( result ) // Logs a turtle graph as a string
} );

The idea here is that the dev doesn’t actually need to worry about RDF that much. If you have data and want to ensure its portability, all you need is a schema for your data and you should be able to get going.

After choosing a vocab they can easily convert their data without having to worry about turtle/json-ld etc at all.

There’d be no URLs to be resolving for validating the schema once you’ve gotten your schema package installed (so this could work offline, eg).

Having a package available can allow for some validation checks and documentation to be generated for a given schema also.
So I’ve another proto-lib: https://github.com/joshuef/rdf-check-mate which could be hooked into a toolchain to throw warnings on invalid data types eg.

Validity:

// Checking against Book schema from schema.org
import { Book } from 'schema-doter';

const sampleObject = {
    'numberOfPages' : 4,
    'title'         : 'Dave',
    'author'        : 'me',
    'published'     : 'now',
    'publisher'     : 'yes '
};

valid = validate( Book, sampleObject );

// This warns in console:
//
// There is some incompatability between your provided object and the schema...
//  title , published do not exist on this schema

// But (potentially still...):
console.log( valid ) // true

Invalid:

const badObject = {
    'numberOfPages' : 4.1,
    'title'         : 'Dave',
    'author'        : 'me',
    'published'     : 'now',
    'publisher'     : 'yes '
};

valid = validate( Book, badObject );
console.log( valid ) // false

// also throws:
// Candidate data type error: 4.1 is number should be: Integer

All of which, I’m hoping could just make it that bit easier to get going with RDF. As above, that’s all proof of concept modules at the mo, but for me, it seems like a simpler way of getting folk to use RDF data, as there’s:

  • Less decision paralysis
    • no, schema serialisation to worry about…
    • if there’s limited vocab packages, it’s that much simpler to choose from popular ones, NPM etc can already act as a measure for this.
    • simpler to publish your own schema… as simple as an NPM package anyway…
  • Feedback!
    • Get warning or errors when attempting to parse invalid data.
    • Potential to provide/generate a simpler set of documentation for any schemas
  • Just use your JS, but with the potential for full RDF.lib objects / serialisation so you should be able to hook into any RDF styled apis easily enough…
    • An no need to get _into _ RDFlib and start wondering about literals etc…

Any feedback/thoughts on the above appreciated! And I’m super curious to see what yous have been up to :+1:

6 Likes
6

This seems like a very good idea. I recently realised that not all ontology RDF files are available all the time (and are not stored on traffic resilient servers). Therefore not having to download those files for type-checking is a huge plus. This can be compared to http://definitelytyped.org/ efforts to provide typescript typings for as many npm packages as possible and I think their approach works quite nicely.

2 Likes
7

Just wanted to bump this thread by linking to the Solid React SDK, that has Access Control on the roadmap :slight_smile:

8

I’ve made a acl library some time ago and then used it for two projects which might be interesting. Please note that you shouldn’t use them on important data as it might break things (I don’t remember how far I got with developing it)

Solid Share

It’s an UI for the acl library, you can easily give someone permissions for a file. The source code for it is here and there is also a live example.

Sharing via link

I’ve also tried out how one could share a file via a link, similar to how dropbox does it. I’ve started writing a library for it but didn’t finish (here is the prototype).

Here’s how the library would work when someone wants to share foo/bar.xyz:

  1. owner specifies which file to share, what permissions it includes and where to store the sharing information (e.g. foo/bar.xyz.shared)
  2. the library creates foo/bar.xyz.shared and allows every user to APPEND it
  3. library creates a random group id (e.g. group-12345 and gives this group the specified permissions in foo/bar.xyz.acl. The acl will read group members from foo/bar.xyz.shared
  4. the owner can use this random group id as sharing link, sending it to a friend
  5. the friend can add his/her WebId to the group-12345 in foo/bar.xyz.shared and will have access to the file
  6. optionally the owner can remove the group from the acl and shared file after some time to revoke the sharing

So in other words: You grant some permissions to a random group id and everyone who knows this ID can add themselves to the group.

If this is included in a nice UI sharing files should be as straightforward as with Dropbox and co

4 Likes