Prediction: every dapp that ships over the next year as these technologies mature will have its top comment on HN be "actually this is not 100% decentralized"
it would be very helpful to get out ahead of this and have a framework for classifying how decentralized an app is. otherwise we may find ourselves in a situation where nobody migrates off of fully centralized apps to less centralized apps because they aren't "fully decentralized", which would be a shame.
I feel any step towards decentralization is a good one and I there will always be a group of creators who will push that boundary and believe that it is their duty to do so. There will also be those that will adopt it especially as the status quo becomes increasingly less attractive.
I'm personally more critical of all these crypto technologies that can be decentralized but have unnecessarily opted to maintain a centralized power structure.
The vast majority of Token/Blockchain whitepapers I've read distribute a majority share of the power to the developers and/or investors and/or early adopters. In that sense it's less of goal of decentralization and more of enabling a new class division where a new group of people become the powerful by making a bet on which new system will be dominant. That's of course by design as it provides a major incentive for gathering a coalition of support and tractable adoption.
Ultimately I think all these attempts at centralizing power just expose an internal instability in these systems that is ripe for disruption by a benevolent actor and currently these are feel like opportunistic cash grabs exploiting fools with the luckily fortunate benefit of having these technologies explored.
I do believe all the right pieces are beginning to emerge each new cryptowhatever exploring and testing a new algorithm or consensus scheme or concept. At some point someone will put it all together to create a truly fair decentralized trust-less system that will have an internet-scale effect on our society. It will have the same effect on things like Bitcoin that Wikipedia had on printed encyclopedias, but with an truly incredible scope of change extending far beyond trade and communication.
I also get the sense that the current systems will need a collapse to signal the defects. The allure of how lucrative it is to build it predominantly to your own benefit, especially given how willingly people are to accept it, is intense and probably even market efficient.
It reminds me of that Frank Herbert quote: "All rebels are closet aristocrats. That’s why I can convert them so easily."
One way to do it is to think about which parts are centralized vs. distributed vs. replicated: discovery, authentication, processing, storage, files, etc.
Take bitcoin, for example: the ledger is centralized (there is a single monolithic one) but its storage is replicated (there isn't a single central storage location) and the processing is decentralized.
It doesn't follow that a "single monolithic ledger" means Bitcoin is decentralized. Since all (full) nodes carry a copy of the entire ledger and every participant in the network can propose transaction blocks to the blockchain, there isn't one party that controls writing to the ledger.
Risk of centralization comes from mining pools that control 51% of the hashing power. [1]
> It doesn't follow that a "single monolithic ledger" means Bitcoin is decentralized
Oh, I never mentioned that. But the implication of the single, monolithic ledger is that it isn't partition-tolerant, if you don't have access to the ledger, you can't transact.
IIRC, the lightning network kinda addresses that by allowing off-central-ledger transactions.
Not sure why you were downvoted, because I think you have a very good point. I often see us, as web developers, being blind to obvious, simple, local solutions. Perhaps this is because in many areas going from native to web is a win. Or, because too many web developers are exposed to business models around developing web applications mostly as a vehicle to fetch user data. (Fortunately, this is not true for intranet web applications which is a niche where I'm quite happy to work in.)
There's nothing wrong with local applications. What Graphite is trying to solve for is the convenience of access across multiple devices without losing the privacy of what you'd expect from a local app. Happy to talk more about this in detail!
Good question. The primary difference is that your file data is encrypted client-side before it ever reaches the storage provider of your choice. And that data can only be decrypted client-side in the app.
You can, of course, PGP (as one example) encrypt your files yourself and store them on a local Dropbox folder that syncs. But, Graphite is encrypted by default without any additional work on the user's end.
The other main difference is that you can share your files with anyone that has a Blockstack ID regardless of what storage method they use. You might use Dropbox while another user uses Azure, and neither user would know the difference, and the app will work seamlessly.
You can use Boxcryptor [0] on top of Dropbox to encrypt everything client side. That's much simpler than PGP.
Yes I agree on the collaboration. I can see how this is more of a security/privacy minded replacement for Google Docs rather than a Word/Excel replacement.
Even simpler solution is to use encrypted backup/sync like SpiderOak or Tresorit. The point of Blockstack as I see it is that it decouples software from storage providers, which will hopefully result in large cheap encrypted storage combined with secure opensource software.
It's not just that. The web is fundamentally incompatible with security against the server. ONLY local solutions can be secure against the author of the code being untrustworthy (ie. the security of the web fundamentally depends on MS, Google, Mozilla, IETF, etc. being trustworthy. Without that condition satisfied, even perfect code can be compromised). Let's say some webapp is actually really secure (when you first run it and generate the data, they're not cheating, and really upholding security), the docs are on your hard drive, you control the data storage, and so on and so forth.
You might think, I made my docs using a secure program. They should be safe, right ? Okay ... Let's say the organisation behind it "goes bad", and now you want to access your docs. What happens ?
You browse to their server. Your browser downloads the code to read the docs then and there from their servers.
Nothing prevents the incredibly easy security problem:
You browse to their server. Your browser downloads the code to read the docs and the code to fully break your security. (maybe the NSA /justice system compells them [1])
As long as both of these conditions is satisfied, there can be no security from the author of the code:
1) code gets changed without guarantees for it's security properties/thorough inspection
2) bidirectional connection for the code
As long as both of these conditions are satisfied, you CANNOT be secure (meaning you don't have to trust anyone). Impossible. Mathematically impossible. Since the web fundamentally depends on both these properties, there can never be true security on the web. Call it candio's law.
With local installs (e.g. Libre, Open or MS Office) you can secure everything and still have updates and fresh software. How ? Easy: have one-way data transmission from the internet to your machine. Download the programs onto a read-only drive (for the truly paranoid: write to DVDs or something that is fundamentally incapable of rewrites). Then use those read-only media to upgrade. That's enough to get OpenOffice running. And no matter how compromised OpenOffice is, the Apache project cannot access your data, nor can they do anything else, if you cover your bases. For instance, they cannot delete your data. They cannot prevent you from accessing your data. They have no power over you.
And of course that will never work for Office 365/GoogleDocs or any kind of web replacement. Under basic security measures those products simply ... cannot work.
[1] People think that it's the NSA going after their data. I'm sure that happens, but what is (by far) the most common reason a judge orders your mail copied to someone else ? Divorce (and related, e.g. alimony disputes). Second most common reason ? Commercial relationship gone sour. THAT's what you should be afraid of : all your mail sent to your competitors because you got into a legal fight with one of your suppliers. In practice I'm pretty sure more emails become exposed due to allegations of animal abuse than the NSA ever gets.
And it's pretty popular. There are so many unique or made up names to choose from that help users later when looking for some solution tremendously. Why choose something that is already associated with some popular software? Especially given that it's also going to have some charts.
I made a graph plotter called the same. Even when I came up with the name I knew it would clash. I was unaware of the clashing projects but by using a non-mutilated word I was fairly certain they would exist.
There are more projects than words, Possibly more projects than easily pronounceable utterances. Is there any good solution?
The dystopian vision - "I'm sorry the project name Graphite is already taken, Graphite001675 is available"
It also clashes with the mineral graphite, which is often powdered, then mixed with a clay binder to form the core of a mark-making instrument called a "pencil". This might be intentional.
Most people probably haven't heard of the monitoring suite.
My first thought was that since it's becoming popular to swap Graphite out with something like InfluxDB, someone found a new use for the Graphite metrics database by storing encrypted chunks of files in it instead.
The features page [0] has as much content about 'contacts' as it does docs or spreadsheets.
Personally for me the most important thing is that it can do all that I use Word/Excel for (I know this doesn't have to be the full feature set) - because without that I couldn't use it.
So I would put the Docs / Spreadsheets sections at the top with screenshots of a reasonably complex document (contents/images/tables/sections) then a reasonably complicated spreadsheet.
Only then after that would I start talking about contacts.
There's a claim that it contains 'All the features you've come to expect from Google and Microsoft'. This could do with a comparison table saying exactly which features / functions are available across Word/G Docs/Graphite and across Excel/G Sheets/Graphite.
Congrats, this looks really great! Do you plan turning this into a product/service or is it a side project? I think there's a real market for secure alternatives to popular cloud services so I hope this will be successful. Personally, I moved most of my data and services (G-Mail, Dropbox, AWS) away from the US to European alternatives, which fortunately stepped up their game in the last years (IMHO) and are often quite usable. I haven't found a good alternative to G-Docs for collaborative editing though, so pretty excited about something like this. I think a traditional encrypted backend data store would be more adequate for most users though.
Thanks! Yes, there are enterprise features in development for the business side of things. The consumer app that you see (plus enhancements coming) will continue to be free, though.
I can imagine a world where Blockstack apps and other decentralized apps can be combined to replace all of the cloud services we've been indoctrinated into believing were necessary.
Lately, I see the trend of calling a lot of different things decentralized. In fact they all are, but at the same time they are very different.
The classical example of a decentralized application was the email server. Everyone could host one and they all would communicate with each other (in theory). And with the thing called Federation for Nextcloud, XMPP or Matrix servers it is pretty much the same. When you host a server, you have complete control over it.
But recently, we see all those blockchain enabled networks which store the data on some of its nodes. You have no idea where your data is stored (cloud like), just protected by by some encryption, which is considered safe as of today.
I am a huge fan of decentralized services as we have known them for a while, yet I look very skeptical at the new services. I mean they have their own set of unique features (e.g. excellent up-time, scaling on a network level, etc.), but at the same time they lack properties of the old decentralized applications (e.g. 'your data on your hardware').
Anybody knows if there are more precise terms than just calling them all 'decentralized'?
Honestly, whenever someone chooses a name, a comment like this comes up. It's inane. Every possible common english word is already used for some other software product in existence, even if it has a small user base.
Holding up the ideal that no name clashes should ever occur in software is even far more restrictive than actual trademark law.
Graphite is the material from which pencil lead is made, a fitting name for a writing app. The expectation was never that Graphite (this one) was going to be the only company, app, or service with that name. Thanks for the links!
This is helpful feedback. You have to download the Blockstack Browser in order to communicate with the blockchain for registering your name and zone file. However, you should be able to get up and running in just a couple minutes. Any suggestions for specific improvements?
We're really focused on improving the on-boarding process for users who are new to the Blockstack ecosystem so it only takes on a few seconds for users to get started with a Blockstack app instead of immediately asking users to download and install the Blockstack Browser.
There's two separate things: demonstrating, and onboarding.
Installing Haskell for development takes a few minutes. But you don't need to do that to see how Haskell works, you can just use the interactive prompt on the website: https://www.haskell.org/
My point in your case, is to suggest the idea of an in browser blockstack/Documents demo. It wouldn't get you the decentralised guarantees that you get with the proper blockstack browser, but might give people a taste enough to be interested. Could be a lot of engineering effort though!
This seems to rely specifically on the Bitcoin blockchain. From the Blockstack-Core node install instructions:
"Because each Blockstack Core node maintains a full copy of the network state locally, it will need to synchronize its state with the Bitcoin blockchain when it starts for the first time. This can take days."
That's bad news in my book, Bitcoin is a very unstable world. I'd rather rely on a dedicated blockchain.
Blockstack engineer here. Just want to clarify for other readers that Blockstack Core has a "fast-sync" mode that lets you spin up a full node in a minute or two. The downside is that it uses a recent signed snapshot from Blockstack PBC's servers (the public key is built into the software). If you have it installed, you can this to get started:
This is only if you choose to run a core node locally. Not all user will do so, and for them, they will be up and running in a couple minutes.
The bitcoin blockchain is just the current blockchain being used. Blockstack was built to be migratable to any blockchain. In fact, they've already migrated once successfully.
Looks good, but as a google docs alternative? While the editor is fairly usable, the spreadsheet is very feature anaemic -- just enter data, export as CSV, insert/delete rows, alignment, fill handle, simple formulas and print. Although I did notice that it allows you to right click and make individual cells read only. I wish Excel had that...
Absolutely agree with you on spreadsheet functionality. But the additional features you're looking for are coming. I should have a public roadmap out soon that I'd love to get feedback on.
haha, i've pretty much migrated to google docs, so i didn't realize how terrible that workflow was in excel. I didn't need such a function back when i still used it.
for anyone else wondering:
you can only have a whitelist of editable fields in an excel worksheet, and adding items to that whitelist is a well hidden feature
This is a red flag. “Encryption” is far too unspecified. I’m looking for specific primitives, constructions, algorithms and design decisions. I want to know how key exchange happens, if a library like libsodium is used, whether you’re using AES-GCM or ChaCha-Poly1305, etc. I’m looking for an architecture diagram to understand which of these questions is coherent. Is key derivation used? Under which algorithm? I’m assuming your IDs are SHA-256 hashes, but is that correct? I don’t know.
Basically, aside from saying there are “ECDSA private keys” in passing, how precisely does encryption, key exchange and digital signing work? Maybe I missed a pretty obvious explanation in here - I was reading quickly (though pointedly). However, if that’s the case then mea culpa, and it should be easy to rectify by pointing out where exactly I missed this documentation.
For reference, here are examples of documentation I’m looking for[1]:
A basic overview of each primitive with a brief explanation of why it was chosen would go a long way here. I understand if Graphite is too young for this (though this should be a priority), but Blockstack should absolutely have something like this documented poignantly. If Blockstack does have this documented, Graphite should really link to it (poignantly).
________________
1. I have no affiliation with either of these, though I personally use them, and they’re not competitors anyway.
I'm on the engineering team at Blockstack, and wrote the client-side encryption functions used by applications.
I totally agree with the idea that if software uses encryption, it should be documented, open-source, and ideally use a standard encryption protocol. Being able to say "this is exactly how encryption works" in a system is important, and I'm glad you're asking these questions.
Encryption in Blockstack apps is performed client-side via library calls in blockstack.js (our javascript library). The encryption routines are implemented here [1], and implement ECIES, using the user's application-specific private key. That private key is passed to an application during the application authentication process [2]. All a blockstack application has to do is pass { "encrypt": true } in the storage routines, and this is invoked.
We definitely would like to provide better documentation and messaging around how applications engage and use our client libraries -- and documenting our encryption routines is part of that. However, in the meantime, you can feel free to check out or codebase (it's all open source), and we'd always welcome any kind of feedback!
Nobody who's serious about security is going to use an app that does crypto in javascript. Why not make browser plugins to avoid this complication?
Not to mention, if browser makers take their existing browser storage functionality and make more flexible interfaces for them, your app will be kind of useless, as the browser could sync user data with arbitrary cloud providers.
The normal complaint about crypto in JS is that, as a user, I cannot tell what JS is going to be delivered to me this time. Perhaps a security letter forced an update to broken crypto.
> THEN I'LL JUST SERVE A CRYPTOGRAPHIC DIGEST OF MY CODE
1) Javascript is open source and you can audit the code you are running.
2) You can save the HTML of a page and run your local copy so that you know the JS can't change or check the hash every time
Can you audit the code of your OS or Browser? In theory, if you are on Linux, but in practice it is too complex and voluminous for one person to do.
A browser based app is usually in the thousands of lines of open source code running in a sandbox that is very easy to debug.
The browser environment is the most secure and most easily user auditable environment there is.
Unless you expect all of your users to build your app from source on linux that they built from source you can't really get better security.
"Javascript Cryptography Considered Harmful" is old FUD. It was barely coherent when first published and the only legitimate arguments it had have been fixed.
Please stop propagating this article. Its positions are out of date.
FTA: WHAT'S HARD ABOUT DEPLOYING JAVASCRIPT OVER SSL/TLS?
You can't simply send a single Javascript file over SSL/TLS. You have to send all the page contentover SSL/TLS. Otherwise, attackers will hijack the crypto code using the least-secure connection that builds the page.
----
Seriously? Serving entire websites over https is the norm these days. It appears as though the article has been added to but not updated. Current advocates should re-read the article.
Yes, I didn't really want to go through each point in the article. But here's a few things to consider as you read it:
- The article reads like those arguments we have in our heads where we always win.
- The article is from 2011
- The article says "come back in 10 years when people aren't running browsers from 2008"
(we're not to 2021 yet but the majority of browsers are evergreen now)
- We have SubtleCrypto now
- We have SubResourceIntegrity
- We have CORS and CSP
The article has some valid points, but I posit that it is more harmful than helpful. We need an Mozilla-style "arewesecureyet" website instead.
The article hammers home that you should not trust client-side javascript crypto. And you shouldn't. Because you can't. Because 30 points in that article. If we spent all day on this forum, we could go back and forth over every single one, re-establishing the above held truth.
It's like a Cloud OS. If my whole OS is running in the cloud, you can claim it's secure, "because crypto". But it's still actually running on a random pizza box in one of Google's datacenters. There's like 10 layers of trust and assurance needed between them and me.
If my OS is running on my laptop, I only need to trust ME, and maybe Intel's dodgy engineers, and whoever wrote the rest of what's running on my laptop. The control over the security of the system stays in my hands.
That is the basic trust problem, and on top of that are all the other technical problems that make client-side javascript crypto untrustworthy. Even if you solved all the other technical problems, I still don't trust what you are delivering to me more than I trust code that lives on my machine, designed by cryptographers to the highest standards of consumer security.
Important note, a project that you need to look at if you are looking for a similar thing: Airbornos.
It has about the same general premise, but is even more secure in some aspects, and is already operational. (No affiliation.)
I believe this is only decentralized in intent and not actuality.
This runs on top of Blockstack and after reading their Token whitepaper, particularly the section regarding the governance of the protocol... [1]
Initially the stakeholder votes will be used as
signaling and will not automatically activate protocol features. Fully-automated voting on protocol upgrades is an area of active research.
So currently how I'm understanding is that at this point the protocol is controlled and hard forked at the whim of an oligarchy (a foundation I believe) with how it'll work down the road a point of "research".
Furthermore...
The initial trusted-set [of users] requires a single gatekeeper to perform identity checks.
Though I understand your sentiment, please note that the protocol governance problem holds for most major currencies (i.e. Bitcoin, Ethereum, etc). So it is not a unique flaw to Blockstack.
Please also note that though if you think about it from a centralized perspective (i.e. you using your regular browser downloading Blockstack from their own website) then yes, it is centralized. But if you think about it from a community perspective, since all code and protocol is open source, it is trivial to establish new protocol and code regardless of authority. So the essence of it is decentralized.
And this is not just some theoretical thing, all of the major coin protocols have gone through community driven ('decentralized') forks that went directly against whoever was leading the projects at that time. For example Bitcoin<->Litecoin (and notable BCC recently), Ethereum<->Ethereum 'Classic' and Ripple<->Stellar.
I am making a point about the governance of the protocol, not the protocol itself. The apt protocol is centralized, but distributed to attain performance at scale. The governance of the apt protocol could be seen as centralized, because Debian tells you which packages are ok, but it is also easy for individuals to switch to other governors, such as Ubuntu. This might be stretching the definition of 'decentralized', but my point is just that it's not a bad thing or even undesirable.
This has been a central problem for decentralized or any 'P2P' protocol since day one.
When the more popular music sharing sites like Napster and Morpheus were taken down due to their reliance upon 'hub servers', more distributed networks like Gnutella attempted to get rid of their need for points of failure.
But even they needed a concept of a bootstrap index to obtain a list of hubs from which to get on the network. And sure enough, it turned into a game of whack-a-mole between the industry and these servers. Torrenting has the same problem.
If I remember right, the only protocols that work in the long run are those that can broadcast and discover each other, but they're limited to local LANs. Once you need to go outside of your own network, you need some way to discover where nodes are located, and without an initial point of reference(s) (which becomes the point of failure), you're screwed.
Same problem with trusting users - either you use a centralized authority or pre-trusted root certs, or you have to know in advance the other users (e.g. physically exchanging PGP certs).
Isn't whack-a-mole good enough though? How many examples do we have through history of a large centralized organization being bled to death (or at least harassed to the point of giving up) by trying to wipe out a shifting coalition of resistance groups with no central authority? Rome vs Jewish rebels/Celtic tribes, Imperial China vs Mongolian warlords, first France, then the USA vs Vietnamese rebels (even China took a shot but I don't know if that counts since it was post-unification), the USSR vs Afghani warlords, the USA vs Afghani warlords, any future empire that tries to occupy Afghanistan... I would bet dollars to doughnuts that every centralized authority in the history of human civilization has lost a game of whack-a-mole at least once.
If somebody attacks and takes down the central server that your apt-get is hosted on, your won't be able to use it (without changing your servers). If somebody attacks the central server of the token devs, the existing token network continues to operate, even if you can't get an "official" update from the original location. So it isn't really the same thing.
The github link really needs to be on the main site. I do like that the whole thing is GPLv3. Not enough GPLv3 stuff out there these days, or even GPL in general.
Where is my data actually being stored?
This depends on your choices. By default, your data is stored in a dedicated Microsoft Azure Blob.
Isn't that centralized?
Azure is a centralized service, but by encrypting your data, and because your private key is never exposed, Azure cannot access your data. With data replication, there is no single-point of failure and no entity has access to the content of your files.
I really like this a lot. I like the fact it gives choices, it's open source and the first implementation is really solid for an MVP. Well done. It's rather like a cross between OwnCloud and that online app container service I've forgotten the name of. :)
One major point though. Top of your dev timeline should be mobile!
Excellent. Your challenge then is going to be how to keep it in people's minds long enough to gain a decent amount of committed traction. So many web apps like this come and go, but I have a feeling if you keep this simple and do some clever marketing (e.g. alliances) then this could be a real contender.
Seconded, e.g. going to the signup page on my iPhone 5 just leads to a blank page. I suspect the same might be true for my iPad Air despite being on a current iOS release.
A slightly better onboarding experience would be worth a lot, even if the answer is "thine device is unsupported and no plan to support it exists."
It uses Blockstack for the decentralized foundation it's built on. (Among other things) Blockstack stores your data on storage providers you connected to it (such as Google Drive, Dropbox, etc).
Both, Graphite and Blockstack, are fully open source. So there's nobody who will get in between you and your documents.
Storing an unencrypted file with a single storage provider is neither private nor secure. Blockstack allows users to select multiple storage providers, allowing for data replication and mitigation of any single source of failure. Additionally, encrypting a file client-side before it is stored means that Google or Dropbox or whoever can snoop all they want and not be able to see your data.
Presentation app is on the roadmap. Honestly, I've been waiting to see how much demand there was before we launch into that.
And yes, you can host since this is a serverless app. If you go to the repository, you can clone and run locally or deploy to the domain of your choosing if you want.
The key thing to note, though, is that the app origin is used for storage. So, if you create documents locally, they will be accessible anytime you run the app at localhost:8080 (or whatever port), but they won't be accessible at app.graphitedocs.com. Similarly, if you self-host, those documents will be available at that app origin domain, but not others.
If you want to use Graphite and share files, the best bet is to run it at app.graphitedocs.com, but you absolutely do not have to.
Heres how they explain it on the Blockstack website.
Blockstack uses the lower layers of the traditional internet and focuses on decentralizing the application layer. Blockstack provides key tools and infrastructure to developers enabling decentralized storage and decentralized authentication & identity. Developers build single-page applications in JavaScript then plug into user-run APIs, which eliminates centralized points of control. Users run decentralized apps through the Blockstack browser and give explicit read/write permissions to their data. Information is encrypted and stored on users’ personal devices. There are no middlemen, no passwords, and no massive data silos to breach.
Spreadsheet and doc functionalities are very limited : you can't drag a formula, it just copies the value. You can't draw on a doc. It's more like a toy than a google doc replacement.
100% agreed on spreadsheets. Docs is designed for writing. There will be more features but drawing is not an early priority. Graphite just launched. You'll see improvements quickly. Thanks for giving it a shot!
That's quite the compliment, the most impressive things are often mistaken as toys at first glance.
Home computers were a toy, the internet was a toy, airplanes were toys, the automobile was a toy... I'm not suggesting that Graphite is going to have that kind of impact, but ...
Yes, but many more unimpressive things are correctly assessed as toys.
Your argument is like someone saying, “he sucks at basketball, he was cut from his high school team” and responding “that’s quite the compliment, Michael Jordan was cut from his high school team.”
Would love to help you out on that algorithm, I (and a bunch of other friendly P2P people) hang out at https://gitter.im/amark/gun !
I know it isn't as catchy as Google Docs, but perhaps having the title be "Evernote alternative" or something like that? (IDK if evernote has realtime typing, I doubt they do... or somebody similar that doesn't), so that way people don't get dissapointed?
Thanks, I super appreciate that. We just released some new ones the other day (not sure if those are the ones you peeked at or not)! Definitely join the chat room, bunch of friendly people there and not JS-only (somebody just started a Python port that is working), would love to chat. :)
Thanks a lot! I might take you up on that. I was planning to learn a bit of Python anyway.
I love what you're doing. I hate the way corporations are monetizing our private data. People should be able to have both privacy and convenience.
I would be happy to pay for an Evernote/Google Docs clone with an Android app where everything is client-side encrypted and possibly self-hosted so our data remains ours. What I want should be pretty simple really, but there's always the trust issue so I might have to write it myself!
Storage in a data blob in Azure is just the default storage option. Users can and should connect their own storage providers (multiple for best prevention against centralized failure).
it would be very helpful to get out ahead of this and have a framework for classifying how decentralized an app is. otherwise we may find ourselves in a situation where nobody migrates off of fully centralized apps to less centralized apps because they aren't "fully decentralized", which would be a shame.