0data appears to be a curated collection of five best-in-class libraries/frameworks that enable building SPA apps with user controlled data, rather than Big Tech controlled platforms and services.
We are developing both server and apps for [3] https://solidproject.org/ The effort is backed by Tim Berners Lee, with great auth libraries including dPop and PKCE token exchange
If it's a web app, you can check whether it's sending data anywhere but your Pod - but of course, by then it's too late.
In practice, Solid is only the technology that enables control of your data; it doesn't provide the incentives. It's still up to apps to actually provide you with that control, and reasons for it doing so can include customer demand or regulatory pressure.
But Solid can't force apps to give you control - after all, they might just choose not to use Solid in the first place.
So these services/libraries are meant to be included in apps to provide this capability?
The solution, help, I'm looking for is to be able to easily integrate this into development - to give users control of running the apps with their data but also for the ability to give access/send the data to a centralized platform - or request/command for it be removed; obviously that decision will be if they trust the platform, the governance and leadership of it.
I'm not sure exactly what you mean by "these services/libraries", but yes, in Solid, apps need to be explicitly built to support Solid, and data can only be stored in Solid Pods.
Although it's not Solid, an older project is https://remotestorage.io, which is a library that needs to be explicitly used by apps supporting RemoteStorage, but does allow users to store the data on Google Drive or Dropbox too, IIRC.
Why is Solid architected such that your data resides on a computer that you don’t own, when people own computers and phones that are plenty capable of storing data and communicating via the Internet?
There are a number of reasons you might prefer an architecture like this. The main two are resilience (don't place all your eggs in one basket -- if your computer is damaged or lost you don't lose your data) and availability (if your computer is shut down you can still access your data from your phone, tablet, or another device).
It would make great sense to have a non-hosted backend option, though, for power users who prefer to self-host their data.
Resilience and availability are two great reasons, but even then, why not get those by utilizing end-to-end encrypted sync, such that the server does not have access to the data, but the devices do?
Decoupling data storage from the application layer has some advantages, yes, but keeping the data in the clear server-side brings along many of the problems of the original:
- Data is still centralized in large repositories maintained by a company, and these repositories are still valuable and still open to attack, from both inside and outside of the company.
- There is a pinky promise between the data storage company and the consumer to treat their data properly and not to look at it or sell aggregated versions of it, but it is, at best, a pinky promise.
I agree that the open nature of the protocol making "self-hosted" an option is absolutely fantastic. But until that is accessible and easy for every single person to use, then only smart tech people will truly "own their data". That's really all I'm proposing: self-hosting being considered the default.
I'm not sure how e2e encrypted sync works in this context. Someone needs to own a key. If the app is open, then it can't be an app key (or else it doesn't protect against bad actors on the server). Is there meant to be a tertiary party that holds the key then? Probably it would be difficult for most normal people to use a product like this.
Apple syncs iMessages and Health data between a user's devices in an end-to-end encrypted manner, and plenty of normal people use those apps. They don't even need to be aware that those are end-to-end encrypted.
Imagine the device has a (non-encrypted) database, and the app runs locally and interacts with that database, like normal. Think localStorage if you are web-oriented.
The sync would be a separate background process (i.e. managed by the "Solid server" part) that handles encryption and decryption. As for how to manage a "circle" of devices that share the key without revealing it to the server: you can add a device via a key-exchange with the untrusted device asking a trusted device for the key. You can perform a key roll to remove a device. This can all be done automatically, though, where all the user sees is a control to add or remove a device. The hard part is key escrow (you throw all of your devices in a lake), by password protecting a copy of the key. Apple uses HSMs and Signal uses SGX to prevent brute-forcing this backup key.
I guess this is a design decision. Some services might be ok with the "if you lose your password you may lose everything without recourse" approach. I think it would be a tough sell for a lot of customers. Is iMessage really handled this way? I can believe that Signal is, considering how often they remind me to remember my PIN.
I said this in another comment. A small open source project I love is https://Nomie.app. Every iteration has been made so the creator can’t see any data. It has been handled well enough that two friends were able to set it up before. Though they used hosted couchdb services to store their data.
Yes, Solid comprises open specifications and anyone can implement it. The open source implementation that sees most development atm is https://github.com/solid/community-server, which is nearing a 1.0 release.
Perhaps so. I don't know the details. I was operating under the assumption that the parent comment was correct in its accusation that there was no self-hosting option.
Most users will likely prefer a secure way to sync data. There should be a self hosted option.
I am a huge fan and even started looking at Svelte to contribute to https://nomie.app. It is going back to syncing with your own CouchDB instance or just locally. Right now it’s local or to some blockchain company. I don’t remember the exact details any more but it seemed like no one had access to the data.
With Devonthink for Apple ecosystem, I synced between LAN/bonjour only for a while before switching to iCloud sync this year.
You can run the pod service on your own computer as well or on your own VPC in any cloud. Our TrinPod Server can be run on any ubuntu machine anywhere, we plan to get it to install on Raspberry Pi too. The Solid protocol is a peer to peer protocol. You just need to have 80/443 open to collaborate with the rest of the world.
As someone dabbling with such an app right now, there are several hurdles if you want to exclusively use self sovereign identity.
1. Local data gets lost, so you need to sync for backup. But when your device gets lost or when you need to access it from elsewhere, how would you login to the said backup service? The most intuitive option is still a username and a password.
2. It's hard to transfer data from one device to another. And to asynchronously share data with friends and family. Solutions like ipfs exist, but in practice they rely on many centralized services (eg: for pinning). And besides, securely sharing private data is not an option on any of them.
3. Lay people being able to safely handle cryptographic keys is an unrealistic assumption.
So IMHO, perfect 0-data is not going to happen. It used to work earlier (pre-internet) because we had only one device, didn't have a lot of media, and could carry floppy disks for the rare occasion.
What I think would make a difference is: browser apps being able to do TCP/UDP (with safe-guards) and sandboxed local disk-access. This allows web apps to do things like SSH, and login to the vast storage infrastructure that already exists - such as GitHub. Data remains fully under your control and becomes portable. Git IMHO is a better path to where Solid wants to go. Especially once SHA256 commit hashes land - to become your personal, consensus-less blockchain.
The internet also fundamentally changed how people perceive of their data being accessible. When I was trying to give advice to someone after their Chromebook bit the dust (from being dropped too many times), doing things like using a thumbdrive to maintain portable copies of the local data on the device... It was met with a can of worms of further questions starting with:
a) what's a thumbdrive?
and
b) what's local data?
Each answer resulted in even more questions. Why isn't it in the cloud? What do you mean I'd have to copy it again? I can run out of room?
I could understand needing to get across to some people that not all data ends up synced (eg, saved memes are not necessarily automatically backed up to Drive)... but reaching a point to where people could be completely unaware of USB storage media actually shook me to my core.
People now expect it all to just "be there" after they log in.
I lived through having to move data using flash drives or by emailing files to myself. Heck in some cases the data had no easy way to transfer so I had to pick what device was the most convenient to have the data on. During that time it was my dream to just have everything automatically in sync.
I very much do not want to have to go back to that crap. Having it all "be there" is exactly how I want things to be.
Ah yes. The cloud that we (society) have become so accustomed to. Keeping in mind, this definition often always refers to either Google's or Apple's storage plans.
I believe one of the reasons for phones nowadays that come with 64GB or less storage, is you can push this limitation with cloud backup.
If you're looking for secure sharing of private data on IPFS you should check out Peergos [0][1][2]. Disclaimer - I'm a co-founder. The model there is each user needs at least one Peergos instance storing their data, normally their home-server. We've designed it so that people should never have to see an encryption key, or cryptographic hash, nor know what pinning is. As far as apps go, we plan to build a sandbox and api in the browser for running untrusted apps served directly from Peergos which you can grant fine grained permissions to your data in Peergos. The sandbox here would be designed so an app couldn't even exfiltrate data via loading an external img tag.
A few years ago (~2017) I built an app that uses a hybrid backend. As a user you can choose if you want to use a WebDAV server of your own or simply the builtin AWS backend. That way, people who care about their data can use their own server (e.g. a Nextcloud) as a backend and everyone else doesn't have to bother.
Sadly the code quality is prototypical at best and while I still use the app multiple times per week, I never released it and have quite a few leanings which I want to implement (like rewriting the sync logic in a separate library, changing the server side data model to improve performance, completely reorganize the user interface and add more features to the app), but aren't coming to due to other priorities.
However, what I also learnt is that it is possible to build something like it, even if your use-case includes advanced topics like offline collaboration. My hope is that one day we will have a library that make these things for developers as easy as firebase and every app will have it out of the box.
The data (in solid for example) isn't local - it's just controlled by the user. The key point is that the user's data is decoupled from your service - it's not necessarily decentralised.
Backups are handled (by the user) - the user can purchase cloud storage through a provider (like https://inrupt.com/products/enterprise-solid-server/, though there are other free services - or you can host your own wherever you want). Users don't have to safely handle cryptographic keys or deal with device syncing.
For (1), why not have all your devices sync up when they are on your local wifi network? If your phone automatically backs up to your NAS, and syncs with your home desktop, your data should always be up to date and backed up in multiple places. Then if you really have to sync while not being at home, you could do something over ssh/using a vpn.
Very few people have a NAS. Even among the tech literate, there aren't that many people who use SSH or VPN. If this isn't transparent to the user, you'll see very marginal adoption.
Is that really true? Are there tech-literate folks that don't have a NAS and use VPNs? If so, count me surprised. How would you BitTorrent without a NAS configured with VPN?
What if I told you that the world is bigger than your subculture?
Why do you automatically assume that someone uses BitTorrent, for example? Your comment reminds me of the dark time in our past when people who used Visual Studio just assumed that everyone else used it, too.
I understand that there is a spectrum of tech-literate. Perhaps I'm on the "hacker" end of that spectrum. I've mentored my tech-literate friends on the other end of the spectrum, and got them comfortable enough to acquire a NAS and setup a VPN.
I have a Synology, and use their "DS File" iOS app to backup all of my photos. And scheduled backup jobs on desktops. Great peace of mind. I backup my NAS to Backblaze and to a local USB drive plugged into the NAS. I'm on my 2nd generation of Synology and am a very happy customer.
3. The crypo space is actually doing this fairly well: end users remember a 12-word seed phrase, and that can be used to recover the multiple private keys that make up a “wallet” (bad term since wallet already means something, but that’s what the hardware vendors went with).
Otherwise I’d say it’s clear you’re in the space and I agree with your assessment.
For the vast majority of users, isn't having solid export options enough, or even better than this? Your average non-techie isn't going to want to configure each app to get syncing with NextCloud or Dropbox working just right, they just want to perform a task with the app and move on with their lives, regardless of where the data lives. And with an export option, if the app dies, you've still got your blog posts or pictures or drawings or whatever it is you were using the app for.
I think being in this bubble of working in and thinking about tech 24/7 can often make us miss the point - these apps are just meant to be tools to do a task.
No, because exporting is not automatic. Most users won't do it.
It's true that most users don't want to configure remote storage for each app. That's solvable though. There should be a way to store your remote storage preferences and just give each app permission to store there in one click.
"Just make it one click to store it in a wide selection of remote storage options" is easier said than done. From the standard user's point of view, they don't need to be reguarly exporting, they can just use that option if they want to change apps or if the app itself is at end of life.
I think the idea is also to prevent the centralisation of data. Because then, the entity that owns your data can create service plans to expose sections of it. The biggest example is LinkedIn. They charge a ridiculous amount of money to just share someone's job preference - open to work, etc. Paying for a smart aggregation or filtering or any meaningful transformation of the data is acceptable. But not for just sharing the raw data when it is user generated.
I have some vague plans around building a job portal just for startups looking to hire ex-startup founders where the data is not owned by my platform and freely available for everyone to leverage as per user preferences.
Maybe yes? I’m not seeing anything on this page that describes the intended audience. I know some people care about data privacy, so this seems like it’s for those folks.
I’ve been thinking a lot about the difference between a product and a project. I’m launching an open source project and we need to make it a bit of a product, but I’m hoping to maybe grow a following on patreon or open collective so we don’t have to focus on selling things directly.
Anyway this seems like a cool open source project that might not be trying to be a “product” for the masses.
If you're doing trivial things, or things where the data is the content itself, then none of this matters and you would be right. However, if the data is something more "meta" or is tied to the product itself, it becomes a bit trickier. If the app is not just a tool, but the whole workflow of a team or organization revolves around a workflow the app provides, it can be tricky, because the data is not just the content, but the result of the workflow.
Just imagine. You use Duolingo to learn a language and it shuts down. What do you do? What's the export format. Will the new product have the same levels / trees/ etc? Very unlikely. You'll have to start all over again. It's not about the raw data, it's about the data that your work has generated.
If you're doing machine learning, then there's the raw data, but there's also all the other data resulting from your hard work: training jobs, experiment tracking, parameters and artifacts and metrics, models.
The question becomes... First, how important is your product in the user's life? If it's important, they'll rely on it a lot and use it a lot to do things that are important for them, or for their organization.
Then, the service needs to provide export options and send you a shutdown notification. These are not always true but, assuming they are, you'll have to scramble to exfiltrate your data.
Then when you exfiltrate your data, it's an export. You'll have to find another product or service, and then somehow hope you can import that data to the new product, and then set up another workflow.
And here I'm talking about consumer products. For enterprise, there are many parameters including who the vendor is, procurement, team size. Meaning if you are Google/Amazon/Microsoft/etc, then a lot of people will treat you like a utility that will continue to be there, even with the track record of some of these of shutting down products and services (how many products has Google shut down over the years).
Look at this thread[0] I posted about our machine learning platform and the conversation that followed. The person objected that as long as it wasn't open source, they wouldn't use it. But digging a bit deeper, it turns out what they wanted wasn't really open source, but open source was one solution/implementation to their underlying problem. Trust you'll be there or control.
I'd argue that if the data is that specific to the app (e.g. which trees and courses of Duolingo you've completed), then if the app dies, the data is irrelevant. Either the data is useful outside the context of the app, in which case it tends to have standard formats (.png for images, .md for formatted text, etc), or the data is not useful outside of the context of the app (e.g. Duolingo) in which case the data is no longer of value and can be discarded, as no-one is going to be able to offer the exact same courses and trees and in-app cosmetics and gems etc etc etc.
It's true that the limited period of time between end of life and servers going offline may be a problem, but that tends to be a long period of time (3-6 months in general from the services I've used that have shutdown).
As I said, the examples you chose are for the simplest use cases, and fungible applications/features for which the raw data is pretty much the whole thing and having a database dump is enough.
Valuable applications more often than not simplify complex things or do hard things behind the scenes. Their value is in the workflow/experience or the processing that takes place on the data, including APIs and integrations to unlock users' creativity.
>It's true that the limited period of time between end of life and servers going offline may be a problem, but that tends to be a long period of time (3-6 months in general from the services I've used that have shutdown).
Again, have you used these as an individual relying on them lightly, or heavily, or as a business/organization where your work relied on these? Have you used them as a user, or as the person who was involved in making the purchasing decision for the whole team/organization?
The only example you gave for app such as you describe was Duolingo, for which I pointed out that the data is useless outside the context of the app.
For business applications, the conversation may be different, but for the consumer ("average non-techie" as the original comment said) I believe what I said holds true.
Pre cloud, this was just apps and local files. Just because an app stored a file on your hard drive didn't mean you could do anything useful with it outside that app, if it was a proprietary format. I'm not sure the typical user misses dealing with files.
I imagine that most users dramatically prefer the sharing, backup, and organization capabilities of proprietary cloud apps to local files.
You are correct of course about apps that were able to interoperate on standard file formats, but I think most of those workflows were fairly complicated for typical users.
"I imagine that most users dramatically prefer the sharing, backup, and organization capabilities of proprietary cloud apps to local files."
My mother has burned family photos to optical disk 20 years ago, we have physical photos that lasted generations. Tell me which app or cloud product I can trust with data for my grandchildren?
Which app will not dissapear, be discontinued, ban you or delete my data if I stop paying?
I uploaded my medical records to microsoft health, now it's all gone.
Paying with credit is convenient, voting in demagogues and populaists is convenient, blind patriotism is convenient, signing contract without reading is convenient, but they all have consequences.
I agree with sentiment but the last time someone handed us a optical disk with memories in it we had to ask a relative for a device they had in the basement for us to read that disk.
Okay but you didn't address their point you just made a think of the children argument. It doesn't change the fact that most people use and prefer, google photos, amazon photos icloud etc. You're one person.
"In May 2017, Google announced that Google Photos has over 500 million users, who upload over 1.2 billion photos every day."
Do they actually prefer it? I am talking about my elderly mother as an example here. People are becoming increasingly more aware of the issue.
Also many phones come woth google photoes preinstalled and enabled by default, I am counted towards that statistic because it uploaded a few things before I disabled it. Even if they really use it, I am betting most of them Also use store same photos as normal files.
I would like to see fresh numbers now that you have to pay for google photos.
> Even non standardized stuff like word and excel documents could be shared, backed up, organized using these files.
Yet you couldn't collaborate on or generate a link to these files - sharing them with your family or a coworker most likely meant starting an email chain mailing the file back and forth with changes.
While some people care about privacy, huge majority doesn’t (even if they say they do), as you can see be various services that have billions of users.
The only way to make privacy happen is if it’s dead simple, works out of box, and not only doesn’t regresses your experience, but meaningfully enhances it. I’ve failed to see projects that would do that so far, and same here - it adds extra complexity for end user, with no tangible benefits to the experience.
Im working on something that also have the goal to give the power back to the user in terms of control, but i've also understand it the same way you do.
That in the end the platform have to provide a better experience to the end user and also give more power/flexibility to the developer, otherwise no one will use it.
That's the reason i think it requires a lot more work to make this feasible. Only "iterational innovation" wont do it.
I hope that what i'm almost about to launch here, might reach those goals.
AND it goes against economic incentives for the typical dev (i.e. make migration harder to engender lock-in)! But, for devs who have portability and openness as priorities (volunteers and altruists, in other words) it seems very helpful to have a precompiled model of how to build apps that respect these priorities.
people don't care about privacy, but at the same time if facebook (or whatever) didn't mine your information when you signed up first and you had to go deep into the settings to turn on tracking, nobody would care about that either. they just care about being able to do xyz for free.
do you know about the safe network? that seems relatively easy. the way its being designed is that you will have to log-in to access the network (which does add complexity compared to now) but the idea will be that you can sign up for websites and services using your log in ID. so you dont have to share your name or email address and there will be no need for a service to store your password
Hostage? You can export all of your Google Photos collection (I did that myself a month ago, to migrate to my NAS). It’s little annoying, and had some bugs with metadata, but possible.
It removed the feature that syncs my photos with storage I control, and the only option left is an export tool that tends to forget some photos, or exclude some metadata.
The removal of that feature certainly wasn't accidental.
The message is good but the name makes no sense, and is almost the opposite of what’s described. In a traditional web app, the client has zero data, or just some cache. But in a "zero data app", in the way they mean it, the app has all the data, so certainly not "zero".
Go explain the concept to someone unfamiliar with it with a nonsensical name like this.
> It's zero data from the perspective of large tech entities.
I understand that, and in fact most developers do. However if they invent a new term, it should be something that makes sense to everybody (not just developers or large tech entities), or at least that doesn't require a complicated explanation to define it.
It's nothing new either, the trend for self hosting and offline first apps have been going on for a while. In my opinion they failed at finding a good term that encompasses all this.
when looking at different data management approaches i see the following:
- third party manages encryption keys and data custody, users manage none (dropbox, G drive et al)
- third party manages data custody, users manage encryption key (e2e encryption, icedrive, pcloud, 1password etc)
- third party manages none, user manages data custody (and eventually encryption) (0data and more generally "storing files in your computer")
the 0data is just like going back to what we used to do a decade or two ago and we all know it has its drawbacks (data can be lost, stolen, corrupted, difficult to move)
the most popular data custody model where a third party has total control over our data but we don't also has its drawbacks (data misuse, data breach, data mining, data transfer etc)
the second approach which i am surprised not a lot of providers adopt is where we delegate data custody to a third party but we still have e2e encryption over the data contents also has its drawbacks (data can be lost if keys are lost) but it's what i think it's more compelling compared to this 0data philosophy.
One large reason that option 2 isn't great is because people will forget or lose their key. And at that point you'll have a very angry customer when you tell them that you can't let them in or give them their data back (or at least not any useful data). People don't truly understand just how impossible it is to regain access to their data.
I can't speak for all projects listed here, but usually with option 3 you can also choose to e.g. pay someone to do the hosting for you and effectively get option 2, provided that data is not stored locally and can be encrypted.
I'd like to see this applied to online advertising, making cross-site tracking against the law and forcing advertisers to bid per real-time request for user data and the money is paid to the user themselves. Currently advertising platforms make more money by allowing advertisers to better target their ads. I have nothing against this as long as I'm paid for access to my data at the price I think is right (might be MAX_INT, to each their own).
1. Each user would have a "data pod" configured in their browser, storing has as much structured information about the user as the user wants (can be empty, or it can have all the structured data fields you want to insert).
2. The user can update any fields at any point and how access to the data pod is done.
3. The user can setup a BID MINIMUM or MARKET value for access to its data pod, perhaps even having different bid values for each set of data. For example, an advertiser wants to know my name? $0.000001 per request. You want to know my address and what TV shows I like? $0.001 per request. Want my bank data? $1000 per request.
Further this data could be authenticated cryptographically by certain authoritative entities. My government could authenticate that I am indeed from country A, and my pod's data would be signed by them (netflix and spotify could authenticate my media consuming history, etc). From that point onwards advertisers know that this field has been validated and can be incentivised to pay more. This should get rid of the incentives where everyone will self-report as being a US citizen just so their requests have larger bids.
>My government could authenticate that I am indeed from country A, and my pod's data would be signed by them
This is gonna happen sooner or later, but I really don't like it. Once most users have a cryptographically signed national ID on their PC, a lot more websites will require you to provide it. Sites like Netflix that region lock media will force you to show your ID just to sign up
Won't be long before companies get away with the invasive crap they tried and failed to do in the past: "Users Revolt Over Blizzard's Requirement Of 'Real Names' In Forum Comments": https://www.techdirt.com/articles/20100708/03054610123.shtml
Won't stop massive copyright holders like Disney from forcing their licensees to region lock. Their actions have shown that they don't give a damn if their policies encourage piracy
Netflix region locks content that they have to license, not their original content. Sometimes content is restricted because of previous exclusive licenses given to traditional channels (e.g. cable).
I imagine that as everything moves to “streaming first”, and old licenses expire, we ‘ll leave región locking behind. Video games are not región locked, even though prices are adjusted for different markets.
Movies and series should move more and more towards a global market. When I was a kid movies took months to arrive to theaters in my country (for various reasons, like reusing celluloid or making better predictions of performance)... now big blockbusters premier simultaneously everywhere because a good portion of marketing is global.
The problem is someone making good money will likely not bother with that system - they will just say “my info is not for sale” instead of trying to figure out settings which would earn them them 0.1% of their regular income.
So this system will mostly be used by the people with little disposable income, enthusiasts who enjoy gaming the system, and scammers with tricks to maximize earnings. Those people are not going to spend much money on buying expensive products, so the advertisers will find out that this bidding thing is just not bringing any results.
I have a unique ID to netflix, I can be authenticated through that because I know my netflix credentials. They do not need to know my "data pod" ID for this - the server just needs to reply to the data pod that queried it with the right credentials.
Depending on "data pod" implementation you could also have the "netflix.com" managed fields only be editable by a call from "netflix.com" API, which I then decide to approve for bidding or not and at which price, without me being able to directly edit those fields. Basically write-only from the vendor side to prove authenticity.
I think you could do something like this with web.dev/trust-tokens (same idea as PrivacyPass), where the server can vouch for you without saying who you are.
Storing information in the URL itself is a grossly underutilized way to allow users to control their own data. If data is stored in the URL, there is often no need to send it to a server. And since URLs are so widely-supported, sharing the data is inherently easy.
For example, it takes about 3 lines of JavaScript to store and retrieve a base64-encoded, stringified JSON object in the URL fragment (the part after the # – https://en.wikipedia.org/wiki/URI_fragment).
This is great. For wide scale adoption of this (or any other tech for that matter) there has to be a way for people to make money. What are some business models that this enables?
Such sites are a distraction from the real problem that the non-tech users have:
They want the app to work forever, even if the underlying cloud storage service gets killed.
Hence, being able to transparently transfer your data to another underlying storage service without the app changing at all is what most normal people want.
They want a box saying "This app's storage expires on 20th of April. Please choose where you want to transfer your data without disruption of service (and where it will be hosted from now on): Dropbox, Google Cloud, OneDrive, pDrive, Mega, ..."
I've spoken with a lot of regular folks. They don't care about privacy or self-hosting or decentralization at all. They never will. To them technology is a tool with which they make their lives easier. We should take a page from them. :)
(Although to make it 100% clear, I do care about privacy and anonymity very much; but it shouldn't be idolized and put on a pedestal, otherwise people like me will be made irrelevant with time -- one could argue this has already happened).
---
TL;DR: Sites strictly advocating for some tech principles lost most of my vote a while ago. We the techies get too distracted by our own shinies and must make a come-back to pragmatism and serving the regular people. It's OK to code stuff as hobbies but promoting them as universal values gets a "nope" from me. And that comes from a guy who wants to retire at his own house with 3 internet connections, and work on Tor-on-steroids and automatic replication of encrypted data until he dies.
I believe Obsidian (https://obsidian.md) follows this principle. That app, and ones like it (Foam the open source VSCode version) have introduced me to the field of Personal Knowledge Management. I believe these two tools help one lead a wiser life. Regardless of outcome, they’ve made learning and thinking fun again, at least for me.
That was one of the principles that made me enjoy https://www.hashapass.com, a password manager with zero storage. Not even local storage, because then you'd have to deal with backups.
I'm glad to see so many applications follow such a principle, though whenever I use something like it I remain scared of not doing backups right.
Used to use http://www.nullpass.org which is the same thing but open source. Ran in to issues with websites having varying password requirements that sometimes the generated one did or did not meet, and then I wouldn't remember which alterations were needed for it the next time I needed the passwords for the sites.
I've been thinking of starting a community (forum + wiki, etc) based around similar principles, but I haven't settled on what to call it yet. The core ideas are self-hosting, privacy, control of data, open source clients, etc.
The best term I've come up with so far is "data ownership". I like this, but the principles are broader than just data storage. Having control over your computation can also important.
From the end user’s perspective, what would the advantages of an app without centralized storage, like these, have vs. an app with E2E encryption and traditional centralized storage? If the end user’s data is encrypted on the service provider’s side and cannot be read without the user providing a key, doesn’t that achieve the same level of privacy from the user’s perspective?
But if the company shuts down then they won’t be able to maintain the app anyways so as a user I wouldn’t want to use the app anymore and maybe have a copy of my data. The company could be required provide a download of the user’s data (encrypted) before shutting down.
The saved "hub" (file/database) is just a JSON formatted text file renamed to `.vha2` and all the images are stored as JPG in a folder near the file. Yay!
Where actually is the data being stored then? With another provider? On your device?
Or is the second diagram just about being allowed to access your data whenever/however you like. Eg if SocialNetwork just made an API that let you access 100% of any data they have relevant to you?
Zero data apps are great because in most cases you can just move your data to any other service provider. I’m leading a service where I’m trying to emphasize that vendor-agnostic solutions are a fair deal for a customer and provider.
Storage protocols like remoteStorage and Solid have a chicken/egg problem. They need really good apps, but no one is going to write apps, services (like backup), or other integrations until there are lots of users.
But how do you attract users without these things already in place?
There needs to be a killer service that offers something better than Google Drive, Dropbox, etc can provide. They're unlikely to be able to compete on storage price, so they'll need to differentiate in some other way.
I'm bullish on Solid in the long run, but it's a tricky problem.
It's more of an overview of different projects with this goal, among which Solid: https://solidproject.org is the third link under "More information", and several Solid apps are listed. (Among which some of mine, it seems.)
I believe Urbit (https://urbit.org/) is a credible alternative project with significant traction that people who are interested in this might also find valuable to try out.
1. Autonomous Data
2. remoteStorage
3. Solid Project
4. Unhosted
5. Fission
[1] https://noeldemartin.github.io/autonomous-data/introduction....
[2] https://remotestorage.io/
[3] https://solidproject.org/
[4] https://unhosted.org/
[5] https://fission.codes/