Newbie perceptions on Solid: App framework vs Web standards effort?

After my newbie remarks on licensing and community positioning, some more first impressions as feedback that may be of value.

When Solid wasn’t launched yet and following announcements and the MIT page from a distance, my expectations of Solid were additional (W3C) standards to fill in missing parts of the web foundational layers, with the key USP’s of providing true Data Ownership and Reuse in modular fashion - i.e. the features mentioned on the MIT page.

Expectation: Standards and reference implementations. Building blocks that are universal and applicable anywhere on the web, and would become as ubiquitous as, say, HTTP, HTML, etc. etc. Allowing the web as a whole to be ‘re-decentralized’.

Now, I am sure Solid is all of that (you are the best to tell, as I am just a newbie). But - and here I am talking about impressions that other newcomers may have too - there is a lot of talk and focus on building apps of all kinds, using Solid ostensibly as the ‘app framework’. The Docs point to the Solid spec github repo (which is a bit hard to browse and place in context), but the remainder of the docs is some Linked Data background (a hugely broad subject compressed in 2 pages), and rdflib.js API docs, solid + angular and server install + run.

A NodeJS or other web / back-end dev may confuse Solid for ‘just another’ web application framework (especially in Node world every other week a new such framework is launched).

In fact, writing this, I am confused myself. Is Solid the web standards, core technology initiative I thought it was, or is it an application framework based on best open (W3C) standards implemented with best-practices by the experts that helped create them?

Note: All of this is not criticism, but honest feedback of my perception.

Standardization effort, app framework, or both… it may be worth considering making the distinction a bit clearer?


I’ll take a shot at explaining why there is so much talk about apps. The monolithic model we operate under now has a single site(e.g. Facebook) which stores everyone’s data and fairly dumb apps which just need to know how to talk to Facebook. Facebook does all the aggregating of data and the apps just retrieve it. In the Solid world, everyone stores their own data and there can be a variety of aggregating apps which present data for a specific community of users. The apps need to know how to speak to a Solid server and what data they want to present, not any specific service like Facebook. So the model becomes one where the data is owned and stored individually and apps aggregate it without a central service. This is a complete change in the relationship between apps and servers, not an app framework.


What jeffz said. The webid and webacls are the new thing. They make it possible for silos to be broken into little pieces of data that can be hosted separately and presented together according to who has permission. That means that the apps, which act on behalf of webids, will become bigger and more important and the servers will be limited in function.


Thank you @jeffz and @tag42git for the explanations.

But I didn’t post this feedback, because as a developer I couldn’t figure this out. I have some experience with most underlying standards and have been well-fed in the course of time with excellent content and announcements served by @RubenVerborgh (i.e. in the run-up to Solid’s launch).

I am rather looking with the eye of a Product Owner placing my perspective on the user persona’s of people that first encounter Solid and need to make informed decisions on what it is, what it does, and how I can benefit from it.

Landing on the MIT or Inrupt website they should, ideally, very quickly come to the conclusion that “Yes, this is something radically new, the missing parts of the web, and we must evaluate how to be an early adopter of this great work, incorporate in our products and services”. And then burst with enthusiasm, start collecting more info, bringing others on board, etc.

So this is about positioning, content strategy, onboarding (‘customer journey’) and marketing / promotion, rather than a real technical question I had. I’m sure that I could go right ahead to create an OSS side-project, with the information I find on the sites, if that were my intention.

As a developer or architect that does not know about Solid and is perusing the multitude of technologies and frameworks to find the interesting ones for a shortlist, a quickscan of the website might lead the developer to say “Nah, that other app framework had more features and better documentation” and the architect “Meh, it is an app framework. Too bad… thought we had something here”. And move on.

The heavy terminology use of “App” is IMHO problematic, because nowadays in IT everything is casually called an app. Smartphone app, web app, server app, cloud app. Etcetera.

All this, together with licensing and community positioning issue, makes it really easy to interpret Solid in the wrong way, and IMHO may hamper its quick evolution and adoption.

If I land on the website(s) I would want to see much more about the underlying concepts, the specifications and benefits / USP’s they will bring me. Using eye-catching, attention-grabbing diagrams that entice me to dive into the specification texts, and these presented to me in an easy-to-read, comprehensive format and typography. That should come first, and only afterwards I should be taken by the hand to a ‘Let’s us show you how to incorporate all of this in your own work and create some prototypes’ (the ‘Hello World’ tutorial, if you will).

A final note about specification layout and format: ActivityPub did not have a strong accompanying website presence (and still does not have that) with - which is quite minimal, doesn’t really ‘rock’. Yet it had a really nice W3C-style specification document, that - I think - pleasantly surprised many developers in the ‘informal’, friendly style it was written and its use of diagrams:

ActivityPub: How it works

With texts like these:

“So, okay. Alyssa wants to talk to her friends, and her friends want to talk to her! Luckily these “inbox” and “outbox” things can help us out. They both behave differently for GET and POST. Let’s see how that works.”

(Not the typical, tough and dry W3C standards text)

And then after Mastodon was launched, people started ‘dogfooding’ that platform to continue the discussions around further ActivityPub discussions. Has become quite popular really quick in OSS circles, and best way to inform yourself on new initiatives is by participating in the Fediverse. I get always really excited reading the chatter about this tech.

What Solid has going for it and AP had not, is that - from the early start (now) - you have potentially strong web presence (and of course, with @timbl and others, you have great name recognition). Solid movement should capitalize on that, if you ask me, and it needs putting aside the expert technical mindset for a while :wink:


I think you are right, @aschrijver. I find myself having a hard time explaining people why Solid is not just another mastodon or diaspora. We have to make this clear.


What Solid is and isn’t sounds like a great topic for an Introduction to Solid presentation :smile:


This is a great topic and yes, more should be done to clarify what Solid is, and what it isn’t. @tag42git a presentation would be great.


That sorta boomerang’ed on me :smile:


I’ll make a dokieli document soon. I need to learn the ways of dokieli though.

1 Like

Could this type of document help. experimental solid-wiki for newbies
I made this to learn Wikimedia but is usable by all


Yes definitely! Thanks!

I think part of the problem is that Solid is many things, not a single thing. Here’s my rough understanding of what it is. I think that in addition to defining Solid, we need to specify which parts are ready for prime time and which aren’t.

What is Solid?

  • a philosophy of information flow
    • everyone controls their own data (decentralization)
    • links specify relationships (semantic web)
  • a game-changing model of how to implement the philosophy
    • distributed data storage on servers supporting linked data (PODs)
    • no centralized aggregating services like Facebook and Google
    • browser-based apps do the aggregating
    • fine-tuned identity and access controls support a read/write web
  • standards that make the model explicit
    • RDF, LDP, Solid REST, …
  • software that implements the standards
    • Solid Server (ready to use)
    • Mashlib Browser (rough but ready)
    • Tools for app developers (rough but growing)
    • Apps for POD maintainers (not too many yet)
    • Apps for end-users (need more)
  • a plan for world domination
    • grow communities of developers, users, supporters
    • partner
    • develop strategies for migrating from existing central services
    • develop a plan for educating & lobbying policy makers
    • … Profit!!!

Agreed and fair.
Your last point (a plan for …) is actually represented by Inrupt Inc and not the community.


I was trying to be funny on the last part, and I meant “profit” as in “mentally enrich the human race”. I think the community needs to play an active part in growing the community, developing migration strategies, and lobbying policy makers. Inrupt may take the lead in some of those areas, but it’s up to us in the long run.


As the OP said, pretty pictures help. Not pretty yet, but here’s the kind of pictures I envision:

The Web

   page --link--> page

The Semantic Web

   page about Herman Melville --authorOf--> page about Moby Dick

The Centralized Web

  p1 --+
  p2 --+--> Facebook -> Facebook App -> Other people
  p3 --+

The De-Centralized Web

  p1 -> Solid.Storage.p1 ->           	         ->
  p2 -> Solid.Storage.p2 ->  Many different Apps -> Other people
  p3 -> Solid.Storage.p3 ->                      ->

I haven’t got that far, but here’s what I have

Solid is a specification for servers. The Solid specification is intended to describe servers, also called pods, that are as simple as possible, but no simpler, that will provide access to data resources by WebId in a hierarchical file like way or with Sparql queries, with notifications on changes.

WebId’s are the new thing that enables Solid. They are how people can identify themselves on the web. A WebId is a uri, a link, to a profile that describes a person or an agent that can access resources on the web.

A WebId is not a government issued id. It is more like a persona, one that describes the person or agent to a pod or pods. It is invented by its owner. It identifies that owner only according to its use with a pod. So you can create any WebId, but if a pod knows you by a WebId then you must consistently use that WebId in order to claim or grant access to any data you put on that pod. You can have any number of WebId’s.

Data on a Solid pod can be associated with a list that controls access to it by WebId. The list can be a complicated recipe involving one or many WebId’s. Each resource on a server can have its own access control list, or lists can be applied to containers of resources.

In this way, Solid servers can give rise to many client applications that have all of the features of current social media platforms, and more than that, access to each item of data can be designated for exactly specified users or groups of users. This will cause data silos on centralized servers to be broken up into small servers for each individual or project where data access is controlled by that individual or project.

Solid will precipitate an inversion of control from the current regime of powerful centralized servers and simple clients. Client applications will aggregate and present data according to the WebIds that they have authenticated, and they will become bigger and more highly evolved, and servers will be simpler and smaller and more decentralized.

So how are, to take one example, user comments, better on Solid? The short answer is they aren’t. Yet. Because the apps are not built yet.

But they will be. And user comments will be better because each user can have their comments on their own pod and have complete control of them. No one can delete them. Only those of the users choosing can even see them.


Can I add my little screed to your Wiki under the title “What Solid is and isn’t”, to help newbies who may arrive thinking that Solid is a ready made social networking site? Sorry I don’t know how to add it or if it’s possible.

For me, to catch on I had to reduce all the dross prototyping on github to what is active and likely to go on to make solid.

[ok I couldn’t resist the pun]

1 Like

For the time being everybody can edit the solid-wiki.
Just create an account and log in.
Each page as an associated discussion page. I suppose it is made for exchange.
Mail is not working for the time being


Added some derails about Spoggy to wiki