I completely agree with point 1. Regarding 2, I am not sure that a killer app for Solid has necessarily to be in a new social media app - but may be related to it.
Idea: at the moment all social media apps use our smartphone contacts to build their/our profiles for ads. Imagine we could store our private contacts in a pod and only give our smartphone, Facebook or Twitter limited and controlled access. In a similar way, we could block our smartphones to share our locations. Solid technology could become a āprivacy filterā in an existing environment?
Limited maybe, but not controlled because once they got data of yours they would consider it theirs and it would be beyond your control.
That would contrast with ābeneficentā apps that would play by the rules and only rely on your pod for your data. At first the ecosystem of beneficent apps would be varied from completely beneficent to somewhat less beneficent where the data leaks to maleficent apps like facebook and twitter, but hopefully eventually by convention or laws or maybe even usefulness that will be prevented.
Having apps agree to terms of use is being discussed in the specification panels. But I donāt think that can be enforced in software, only legally after the fact.
Maybe a browser can be invented that can only play by the Solid rules.
Yes, and that means PHP, like Wordpress. Not Node, not JS/TS. Sorry, bad news
It would be like a parallel operating system next to the native one. Is that the idea of the name SolidOS?
In alternative Android firmwares like Lineage you can fake an empty address book and grant access to that to the WhatsApp app for uploading it. I like the idea. But then there has to be an implementation for Android and iOS (not PHP).
Not necessarily in media but social definitely. I have an app for ride sharing in mind. Ride sharing is probably not a killer app but it has some aspects of gradual sharing of data.
At first youād advertise a ride but without personal details. When you accept riders youād share more personal details, e.g. number plate. And youād even share real time location data an hour before you meet.
To make it more interesting, youād advertise the ride not just on one website but on multiple and your riders would be from multiple website. That is impossible today.
Ha! Iām well aware. Which is kind of my point. Until it becomes more trivial and ubiquitous to install with hosting services or even a NAS like Synology Disk Station supporting it, I donāt see the adoption rate exploding anytime soon. The technology has to become very accessible, and not just for experienced web devs.
Of course, weāre all just spouting our opinions. Nobody really knows what it will take or what that killer app will be, or if it must be easy to install a pod. Iām mainly projecting my own experience and observations on what gets widely adopted and what gets ignored, regardless of how good it might be. And from that perspective, I know it has to be easy and it has to be better than what itās replacing.
I have started following Solid mostly because it seems like an excellent platform on which to build an app that Iāve wanted to build for a while. The idea came from wondering how to get around a HUGE pain point as a parent. Multiple times each year I need to enter a bunch of personal information for myself and my kids for school registration, school activities, extra-curricular activities, other activities. It goes on and on. Importantly, most of this information is duplicated on many of the forms, even for different activities with the same organization! For example, I have to enter an āemergency contactā for school registration in general, and then again for a day trip registration that the kids are attending, with that same school. This happens for many different data elements with many different organizations.
The organizations donāt share data among themselves, and I wouldnāt want them to. It would be nice if an organization would at least keep a centralized database of my information so I wouldnāt have to enter it in triplicate for different activities but I understand the overhead that might introduce, and most organizations simply donāt have the resources to set this up. So, sending printed forms home for parents to fill in with a pen, the way itās always been done, is the path of least resistance even if it involves a lot of parental cursing and frustration.
My initial thought was to create a website that organizations would subscribe to which collected personal information online. The organization would build their input form with all the required data, and would ābindā the form inputs to standardized things such as āfirst nameā, ādate of birthā, āemergency contactā, and all sorts of other things they needed for legal, regulatory, or other reasons. The end users (we, the parents) would access the organizationās form and would automatically populate the form details based on the bindings (if this is making sense). This auto-population is where I got a little stuck, because the information has to be stored somewhere in a somewhat standardized data format. I had thought that an encrypted file on the userās device might be a good approach - the user chooses the file, code on the website decrypts it based on the userās password and automatically fills in the form.
The other sticky thing is that sometimes the parent doesnāt want to permanently give the organization access to their data, or they want to be able to revoke that access at any time (āshred the physical copies of their dataā). Just having a form to submit doesnāt do it - what would be ideal is to give the organization access, like OAuth, that they can retrieve at any point until that access is revoked. For organizations there would need to be some extra authorization given since frequently organizations need to have printed hard copies of data to bring with them, and in case network problems prevent direct access at any point.
Anyhow, at this point I discovered Solid and thought that instead of a user uploading an encrypted file (or maybe as an alternative option) a user could direct the form to their pod. The app (which hosts the forms and such) could possibly host pods as well or it could simply be a broker, reading data from a user pod and presenting it to the organization.
This sort of app would be most appealing to organizations that donāt monetize user data such as schools and other educational institutions. If Iām dreaming, I would like this pattern to become common enough that users would begin to demand it from other sources who do actually monetize. For example, I have to sign up for Pizza Hut online and for some reason provide them with some of my information. If Iām used to only ālendingā out my data to schools Iāll be less inclined to āgiveā my data to these other places and maybe want to push them to adopt the ālendingā model instead. Maybe Iād even go so far as to choose a different place to order pizza; one that did adopt the lending model. This could put a little bit of pressure on organizations to change their behaviour.
Whether or not I get an opportunity to start building this or whether it continues to be just a dream, itās something that I would absolutely be thrilled about if it started to be used.
Exactly. In our pod we have our complete contacts organized by categories (spouse, family, best friends, work1, work2, providers, etc.) On our smartphone we sync only the categories we want and we establish several filtered virtual address books (Lineage?) for each social app (FB, Twitter, Whatsapp, Google) we have. Most social apps already have all our contacts, but may be this could be a first step to regain control over our personal networks.
Iām not sure this is the case. I take your WordPress comparison to be āas easy asā not āimplemented the same way asā. Thereās every reason to expect pod applications to be simpler to āinstallā (because you donāt need to install them - you visit a web address and give it permission to access your pod).
When talking about installing pods, there are more issues than this and many reasons to look for a way of providing the Solid protocol as opposed to either installing and running your own pod, or signing up to a pod service (which should be as easy as signing up to any web service - trivial).
I donāt think any of this is a barrier to adoption, unless users are savvy enough to spot problems with the pod as a service model, which only a small percentage are likely to.
The problem for me is less one of barriers to adoption, but to missing important goals around decentralisation, privacy, security, longevity, surveillance, censorship etc. because the easiest way to adoption and on-boarding will be to slide into a service based model.
Returning to the OP, I agree that killer apps tend to be social and with the comment that to overcome inertia something special will help a lot, although inertia can be overcome in various ways so I donāt see it as the core issue. For me thatās building a platform that those developers with understanding, experience and means can see is worth building on.
@jonhenshaw
I see that you are missing a big part of what is Solid.
The separation of data (on the POD) and the App (many apps can access the same data)
Some good reads from @RubenVerborgh could help you
and Designing a Linked Data developer experience | Ruben Verborgh
You donāt need to install a Solid server to develop a Solid App.
A Solid app can be a simple html/js page that interact with the data that you store on your POD.
( pod provides space storage & identity)
This page can be a simple form to store, retrieve, classify your contacts on a private folder on your POD or it can be a more complex app that use those contacts, or other ressources of your POD and even remote ressource.
You donāt need to be able to install a Solid server to get a POD. You can grab a POD on the provider you want, some are referenced here https://scenaristeur.github.io/solid-vue-panes/providers.
AND everyone is able to become a POD provider installing a node solid server. Perharps you are not a system expert, iām not too, but iām sure anyone can find one in his friends or company and collectivelly manage a POD provider in which you can trust.
So if you let the server aside, developping a Solid app can be done in any langage that can do https requests.
Here is an example with vuejs, using some great tools developped by the community or Inrupt.
You only need to install nodejs (not harder than installing php/ composerā¦ @frankgerhardt ) and follow this page Portfolio : How to create a Vuejs Portfolio App on Solid
For other langage I donāt know if there are tools but you can find here the kind of request to read/write data on a POD solid-spec/api-rest.md at master Ā· solid/solid-spec Ā· GitHub
Perhaps, but my first point is being able to easily install and control my data (a POD for one), the same way I would host my own site and control that data. And an app would be separate, in the same way email apps are. I definitely see the two as separate things.
I may be wrong but as far as I know, right now in the case of NSS and CSS, single user pod servers and multi-user pod servers share the same code base. That probably makes it more complicated to install a single user pod server, and its probably heavier that way.
@ewingson has installed his own POD provider on an hosting service and documented his experiments https://gist.github.com/ewingson/c6e97a996aa51eac9f7fd1b7eaf14dc4
@aveltens have build a docker image of Node Solid Server š Running nginx+letsencrypt+solid in less then 5 minutes and (Official) Solid Docker Image?
and some other like @bourgeoa Docker solid-server on Synology How-to have some experience in maintaining the community server
Hope this could help you build your POD
So far, all Solid related installs I could see are far too complicated for normal users.
We are not even in an early adopter stage.
We should be able to go to our provider and click on a button to install our pod. Another possiblity could be to unpack a zip file in a folder.
Once we are in our pod, we should be able to install themes, plugins and dev platforms (like documentor in WP) to get all necessary features into our pods.
At the moment, I see only Solid apps - which are like basic āpluginsā of something bigger. So far, I was only able to get a very basic pod, but cannot see the " highly granular access control" mentioned in Rubens nice vision document.
I really liked reading your thoughts on this. However I would add, that a ālendingā model only works if the different actors follow it. Everyone could just copy your data before the access is revoked. Therefore when it is implemented, some kind of contract that prevents (unrestricted) copying will be needed.
I like the topic!
I believe this app is live alreadyā¦ https://hubl.world/
I hate to inform you but, solid is the killer app!
Oooh, this looks interesting, thanks for sharing!
Yes, thatās a very good point to raise. I had thought about how to possibly restrict data copying or make it harder at least (showing raster versions of data that canāt be easily copied). But, if someone wants to make a copy of your data against your wishes there are not really any technical challenges so it may not be worth doing anything beyond requiring acceptance of a ādata useā license when lending out.
One thing I thought might be useful would be to allow granting an organization access to your data, but donāt show the data immediately. Sort of like a sealed envelope idea - if the organization needs it, such as your emergency contact information, then they access it right then. As the data lender youāre notified at the moment the organization actually views your data so you can keep track more easily of whatās being shared. Of course, at that point the organization can copy the data and use it from then on (even if theyāre breaching the contract) but again, I donāt know whether itās feasible or even desirable to prevent that.
All this said, for the use case of streamlining data sharing with school-type organizations itās moot since we are currently giving the organization carte blanche with our data in the form of a physical hard copy so thereās no decrease in data ownership from the current state!
Hmmmā¦ I guess you can phrase it that way at the onset of the Solid movie. Otherwise Solid is not really an app but rather a slew of tedious specifications