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.
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
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?
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
Agreed tedious specifications, but isn’t that what we need in the new world wide web? Doesn’t the tediousness of a spec make it better?
I know it’s not easy but, it needed to be more sophisticated in order to function at the higher level of web we are going to need in the future.
Yes, we need a common language for sure. I’m not sure tediousness is required but… that’s the way it is
Funny we talk about this, I’ve asked myself several times how much the illustrations in the ActivityPub spec have played a part in making it so successful. We should A/B test that for LDP and PoP tokens
Tedious specs without a ‘killer’ app will just sit and collect dust no matter how much potential they may have. A ‘killer’ app without tedious specs will be just one of many apps that do things in their own way and end up totally non-interoperable. Can I have both?
Incidentally, I’d love to watch the movie
I think we’re living it
Checkout the Trusted Digital Web as a killer platform that could be built on top of Solid.
Watch the first 3 videos in the Trusted Digital Web playlist: https://www.youtube.com/playlist?list=PLU-rWqHm5p45dzXF2LJZjuNVJrOUR6DaD
Read the whitepaper: https://hyperonomy.com/2019/11/06/trusted-digital-web-whitepaper/
A mobile contacts app based on verifiable credentials. (Please don’t call it a wallet :-))