Synergy - Project SOLID and SAFEnetwork

Solid is the current project of Tim Berners-Lee who invented the Web.

Latest: SAFE Network DevCon 2018

Links - Solid

Links - LinkedData

The following is cross posted from this topic on the community forum to give it greater visibility to developers.
If you’d like to collaborate with me creating a SOLID backend for SAFEnetwork: testing, bugfixing, writing code or building UI and more… let me know.

The following repositories contain working code for a Solid app running in the SAFE Network, as demonstrated at the SAFE DevCon 2018:

You can watch a video of this app and see the slides from my presentation called Supercharging the SAFE Network with Project Solid.

My thanks to the Solid team for helping me get to grips with the ideas behind Solid and learning how to use their libraries. They have lots of cool stuff!
Update: I’ve been getting to know the Solid project, apps and libraries with help from the team. Now I’m going to put together a proof of concept based on modifying their code to work with SAFEnetwork. [EDIT: this is now complete and was shown at SAFE DevCon 2018]

It’s rather cool to say the least to ask for help understanding Solid and their code, then be answered by the man who invented the Web, and to have the chance to answer his questions about SAFE!

The two projects are different in certain respects (mostly because Solid builds on existing Web protocols) but their aims and application are remarkably similar, so I encourage others to take a look at this project. Especially app developers. Check out my DevCon presentation for more on that - both the video and the slides (many not shown in the video).

Why? Because se we can learn from what they’re doing and vice versa (they have several working apps which already follow the principles of users owning their own data, cross Web/service identity / verification / signing, client side etc). I think it should be possible to write apps that support both projects too, so maybe you can have your app running with Solid as well as in SAFE. Even if not, I think using and building on their standards for data will be valuable for SAFEnetwork and our users.

I’ve extended one of their libraries to talk to SAFEnetwork and enable Solid apps to use it like Solid server.

This will give the Solid community an opportunity to try SAFEnetwork out with their own code, and for this community to try out Solid applications and understand their ideas for a decentralised, user oriented Web, without centralised data silos etc.

They have only a small team but have been working Solidly, ahem :wink: for a long time, and there is of course a larger community around them. And many organisations and institutions are already implementing their standards (RDF/Linked Data, Semantic descriptions), including the UK government. There are some very cool demos to play with, but I’ve mostly been buried looking in their code so far.

I think we can learn a lot from them while supporting and enhancing the open standards they are developing, and I hope they can benefit from the work we are doing here too :slight_smile:. I’m very excited about this and hope others from this community will join me in learning about Solid and maybe working with their ideas, apps and code.

Thought I’d just add this as its a key point of compatibility, from the man himself, Tim Berners-Lee:

@timbl responding to my questions about Solid libs and apps:
"The databrowser apps are stored on the server a the beginning of the day, but they are client side apps. All the code runs on the client. Server as @melvincarvalho says is as dumb as possible but no dumber. IE the solid world grows from new client-side app code, not new server-side code in the medium-long term. "

This, and the nature of the Solid server API should make it reasonably straightforward to get at least proof of concept working for Solid apps with SAFEnetwork. BIG :slight_smile:


There is also this.
It’s almost the same as
I wonder if one of them is more current.

1 Like

Interesting! I had only read a couple of articles about SOLID, without really taking the time to understand the mechanics. I thought I’d read into it this morning.

So, from what I have read so far, SOLID is a specification that defines a standard way to store, retrieve and link data in PODS (personal online data stores) and the client applications which interact with them.

The POD data is represented in a standard Linked Data markup (standard way to link resources, define key criteria, etc) which can be accessed via a standard REST service (GETs, PUTs, DELETEs, etc) in supported formats (like JSON-LD). This is provided by a SOLID POD server implementation.

A SOLID client application accesses the POD service via the REST interface, much like many modern web applications do. That is, the client application is responsible for retrieving and presenting the data from the POD service.

So, in summary, SOLID makes use of existing technology to provide a standard way to host and interact with personal data. Arguably, a SOLID server implementation is a platform, which you write your client applications on top of.

With all the above in mind, I can see why @happybeing is both interested and excited about creating a Safe Net implementation of a Solid.

From reading between the lines, it looks like the SOLID server component is not needed on Safe Net web apps, as the browser can already store/retrieve data directly from the Safe Net. So, it looks like the SOLID client library* would just need to be updated to talk the Safe Net API language, instead of raw REST to a SOLID server.

For non-web applications, the same data would still be accessible from Safe Net too, but obviously a new language specific library would be required.

In summary, it sounds like a nice standard way to structure personal data for applications. Supporting SOLID out of the box would certainly save every application developer figuring out their own mechanisms from the outset. It would also allow Safe Net to lean on these emerging standards and leverage the good will and motivations behind them.

I would say Safe Net is the perfect home for SOLID applications. The nature of the SOLID server gels perfectly with the natural features and security that Safe Net provides. Insisting on clients doing the retrieving and presenting of the personal data also tallies fully with what Safe Net web applications require by design. I see lots of synergies here!

EDIT: * Perhaps a standard SOLID client library could also be embedded into the Safe Browser in due course? This would certainly make it easy to implement SOLID apps and it would likely catch on quickly as the default way to interact with user data at a higher level.


+1, thanks for taking the time to put this summary together, as I still didn’t take the time either :slight_smile:

This indeed looks really promising


@Traktion that’s a very good summary IMO, thanks.

Your right about everything you’ve written. To reiterate in part and add a couple of notes:

  • SOLID-SAFE API - we can provide a RESTful API for SOLID browser apps first as a library, later injected into the SAFE DOM (SAFE API extension). This will also be usable by desktop apps using nodejs. Later for other languages too. I’m planning to build a first PoC JS library for this so we’ll get a good idea of how well it works quite quickly. So far it looks good, but I haven’t got into details yet, just fleshed out the what and the how, and been digging here and there into SOLID and SAFE.
  • WebID (an identity for individuals and groups) is the other big feature of SOLID which I’m starting to understand. Similar to SAFE public name (public id). A WebID can be anonymous (relatively!) but for a group as well as an individual. A WebID provides separate authentication (OICD I think, amongst others atm) and is then useful across multiple SOLID servers/services, as well as being a means to publish/access profile information for that ID/person. I’ve been thinking SAFE public names needed something along these lines for a while, so it’s going to be useful to look at this model.
  • URIs - worth noting that in SOLID a URI is treated as the unique address of an entity (document, WebID, vocabulary/schema). I’m not sure how they canonicalise, if they do, or if there are ways to be robust if say a domain disappears (eg is not renewed).

N.B. I’m probably not stating this properly - still learning basics :slight_smile:

If anyone wants to collaborate on this, testing, bugfixing, writing code or building UI and more… let me know. I’ll be working in the following repository initially:


Always happy to assist with testing once it’s reached a stage where a non-dev could provide useful input.


I’m a web developer. Can I be a part of this project?

1 Like

That would be great. I’m currently working on getting a Solid app to work with SAFE.

Not much to show yet, but watch my forks of solid-plume and rdflib.js for starters.

What aspects would you like to help with, JavaScript, HTML/CSS, design etc?


Thank you! I am a coder, so HTML, CSS, and JavaScript for sure. I can translate mock-ups into web pages but I am not much of an artist, or designer.

I will study those repos and get myself up to speed ASAP.


Found this nice overview of Solid and the projects built around it ( in this case mainly crosscloud )


UPDATE: I met Sir Tim Berners-Lee yesterday. We happened to be in the same area so he invited me to lunch so we could meet offline rather than just online as we have been recently - where he and others from the Solid community have been helping me get up to speed with their project and code.

Tim is the man who invented the Web and has been working on it for 25 years (remind you of anyone? :wink:), culminating in Project Solid (read/write Web, semantic data/documents with built in rules, forms etc)

It was fun, amazing for me to meet the man responsible for the birth of the Web, and to get to know him a bit personally. We talked about Solid and SAFE, but mostly about other things.

It was very helpful for me, to hear first hand what he regards as the stand out features of LinkedData. I’ve read about it but had missed some key features. Some points about LinkedData/RDF that I noted:

  • it’s a graph not a tree (unlike XML). I knew that!
  • can include rules (for transformation, validation?). Not that!
  • can include forms (so a client can create a form for the data in a document). Or this!
  • you can subscribe to documents (but not containers, as yet)
  • although you can represent RDF in XML and Json but I think going that route you tend to lose some of the features of LinkedData
  • adoption of LinkedData and using it to include semantics in documents is inhibited by the extra work involved, but has helped a lot (due to Google’s influence and the benefits in Internet search)

These features make all sorts of applications possible, including multiple views and styles of presentation of the data, as exemplified in the Tabulator (see end).

I’m continuing with work on a PoC demo to show that Solid apps can work with SAFE and will post updates here on that, also as I learn more about Solid. I have only scratched the surface, but it’s more and more impressive the more I learn about it, just like SAFEnetwork! :slight_smile:

[ASIDE: If you want to dig deeper into LinkedData, there is a paper about the Tabulator (see github which I think is a good place to look.]


Very interesting, he knew the SAFE project from before?, can you share some thoughts from Tim about SAFE and this possible (or maybe not) integration between SAFE and SOLID?

We are looking at this from many angles in house. Mark is spearheading the intro and hopefully integration partnership or similar. It gives us a great angle for the client API, if we were able to marry these two projects with their client / linked data API and our back end network it could be a big winner. It’s early days to say the least, but Mark has had the intro meeting, but it is an intro and not a project yet.

There will be more meetings to come, we will share what we can, but as always folk don’t like meetings being too open when they are not aware of it. so we will give Tim his privacy and respect that until we have something more solid ( :wink: ) to share.

Hope you understand.


I understand the interest but it’s not OK for me to share others’ private comments, not that we went into that - just that if we had I would not publicise it unless I knew it was OK.

I will though keep posting updates of what I’m up to! :slight_smile:


Do you have some links describing more of how this works?

I made some prototype a few years ago of adding functions (interfaces actually) to linked data. I didn’t really find any examples of anything similar at the time.

My idea was basically to add the whole program to the graph. For a client side javascript application this essentially boils down to adding an interface to every javascript function and store it to the graph. Javascript in itself doesn’t support interfaces, so the interfaces instead those interfaces are only in the linked data graph. An example is a javascript function that takes a username and email address and output a user object. In the graph I’d then have something like a registerUser interface that has a link from the username entity and the email entity to a user entity. Another example is a javscript function that takes some datatype and transforms it to html. Once you have this you can manipulate the program with queries and do queries to find all existing transformations functions of datatypes you have in the graph. In theory that could make it possible to make a very powerful IDE, where a lot development could be done by querying existing functions for manipulating the data types you want to use in your application, find existing html views for the data types to quickly prototype etc.

I’m wondering if they are working on something similar.


I don’t have more on LD rules yet, but can ask. Or by all means ask in the LinkedData gitter yourself.

I got the impression that a lot of what you describe above is already possible with LD.

I haven’t though read the stuff I’ve linked to thoroughly myself so would like to do that now I realise there’s more to it than I had appreciated. If you turn anything up please summarise or link on this topic and I’ll do the same.

1 Like

@nice thanks for those links about crosscloud. I hadn’t seen this and I think it could be very helpful. :slight_smile:

1 Like

So I did a bit of Googling and found a recent project called the “Function Ontology” that can be used to define functions in a linked data graph, this seems to be similar to what I made a simple version of in my prototype.

They have some examples of publishing and discovering javascript functions in this paper.

This could be a great thing to have with SAFE. You could have lots of JavaScript or Rust snippets stored as immutable data and use the Function Ontology to describe what the functions do and make them queryable with rdflib from Solid.

Combine this with a QA app similar to Stack Overflow, but where you were required to use the function ontology to markup your functions, you can have the basis for making natural language queries. Today in programming, poeple often use Google and then click on stack overflow, but have to manually take the code from there, but with functions marked up with the function ontology this process could to some extent be automated. You could write a natural language query, search the index from the QA app and then get a list of potential functions back. Especially in a more limited domain like SAFE apps this might work. People who publish answers to the app could also include things like a license for the function.


Tim pointed me at this. Not dug into it yet but seems to be a useful set of core applications or app features, and is part of mashlib:

Good technical overview of Solid/Crosscloud platform (client/server, user/application developer, features and example applications). Best intro yet IMO:

  • A Demonstration of the Solid Platform for Social Web Applications (PDF)

Notes to self:

  • LDP PATCH is required according to this, whereas I thought it was an optional server feature and can in any case be simulated in the client (within limitations of the client and connection).
  • LDP SPARQL and link following are optional server features, but clearly powerful, and so we might consider how SAFE API can provide for their implementation - either client side, or perhaps by the network in the future.
  • W3C Social Web Working Group user stories looks worth following up
  • Access Control Lists and WebID authentication are key parts of Solid platform and it would be worthwhile looking at how SAFE API could support similar or equivalent functionality in a compatible way (for example, with fine gained control over access of individual resources through an LDP compatible API).

For SAFE API support of Solid features, much can probably be achieved using a solid-safenetwork client application library, which could later be moved into the main SAFE app APIs, but certain features may require changes to SAFE network client libraries if they are to be supported.

To begin with, it would be very useful to know what the current SAFE network and APIs can and cannot accommodate, and how this would limit or block Solid app features when used with SAFEnetwork.