Looking for the killer app for Solid

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?

4 Likes

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.

1 Like

Yes, and that means PHP, like Wordpress. Not Node, not JS/TS. Sorry, bad news :wink:

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.

2 Likes

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.

6 Likes

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.

2 Likes

@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ā€¦ :yum: @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

1 Like

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.

1 Like

@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

2 Likes

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.

4 Likes

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/

1 Like

I hate to inform you but, solid is the killer app!

2 Likes

Oooh, this looks interesting, thanks for sharing!

1 Like

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!

1 Like

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 :sweat_smile:

1 Like