Show HN: Graphite – A decentralized and encrypted Google Docs alternative
graphitedocs.com
graphitedocs.com
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'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."
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.
Risk of centralization comes from mining pools that control 51% of the hashing power. [1]
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.
Do you have any thoughts on a framework for classifying these 'decentralized' apps?
Rule number one is not to rely on other people's computers to write them in first place.
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.
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.
Closed source + no audit is not exactly what you'd want to see from a piece of security software.
[0]: http://rclone.org
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.
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"
Most people probably haven't heard of the monitoring suite.
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.
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.
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.
https://en.wikipedia.org/wiki/Graphite_(software)
http://ashlar.com/2d-3d-drafting/2d-3d-cad-graphite.html
https://en.wikipedia.org/wiki/Graphite_(SIL)
http://alice.loria.fr/index.php?option=com_content&view=arti...
http://www.samsontech.com/support/samson/products/graphite49...
...
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 a bit of a discussion about how this will work on mobile here: https://forum.blockstack.org/t/blockstack-mobile-plans/3621/...
We want to really reduce the friction of on-boarding new users to amazing apps like Graphite.
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!
Then I can sign up, and so on.
"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-core fast-sync
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.
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
https://support.office.com/en-us/article/lock-or-unlock-spec...
I’ve checked the following resources:
* The Blockstack whitepaper: https://blockstack.org/whitepaper.pdf
* Each of the System Design documents listed here: https://github.com/blockstack/blockstack-core/tree/master/do...
* Blockstack General FAQ: https://blockstack.org/faq
* Blockstack Technical FAQ: https://github.com/blockstack/blockstack-core/blob/master/do...
* Blockstack Repository Readme: https://github.com/blockstack/blockstack-core
* The Graphite FAQ: https://www.graphitedocs.com/faq
* The Graphite Features: https://www.graphitedocs.com/features
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]:
* Restic, under “Keys, Encryption and MAC”: https://restic.readthedocs.io/en/latest/100_references.html
* Wireguard: https://www.wireguard.com/protocol
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 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!
[1] https://github.com/blockstack/blockstack.js/blob/master/src/...
[2] https://github.com/blockstack/blockstack.js/blob/feature/aut...
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 SW stays installed for when you open the web app the next time, in essence making it a trust-on-first-use scheme.
I'm working on a library: https://github.com/airbornio/signed-web-apps
It would be cool if other web apps (including Graphite?) could implement it too.
If you really care you can check the integrity hash on your scripts before using every time.
That gives you more security than the update in your OS or Browser so they are a weaker link.
"OK, THEN I'LL JUST SERVE A CRYPTOGRAPHIC DIGEST OF MY CODE FROM THE SAME SERVER SO THE CODE CAN VERIFY ITSELF."
"This won't work."
Your comment that "That gives you more security than the update in your OS or Browser" is patently false, I don't know why you'd suggest that.
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.
You forgot to tack on "using compilers, etc., that they also built from source".
I created a browser extension to solve just that: https://github.com/tasn/webext-signed-pages/
It lets devs PGP sign their web apps and verifies those signatures. We use it for the EteSync (https://www.EteSync.com) web client.
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.
- 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
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.
And for what it's worth, Graphite is also operational :)
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.
I probably just don't understand.
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.
That's just like saying that apt-get is decentralised because its open source and you get point it to different servers.
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).
stellar is not a ripple fork.[0] this is a common misconception.
If you want to push a change to Linux doesn't someone need to approve it before it's part of the official release?
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.
Do you know the link to the repositories? They are not in the FAQ.
One major point though. Top of your dev timeline should be mobile!
Also where is the github/code located?
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."
>How much does it cost? >Graphite for personal use is completely free.
So, unlimited storage, shareable and decentralized, for free? Where's the bait?
Both, Graphite and Blockstack, are fully open source. So there's nobody who will get in between you and your documents.
If it's stored on Dropbox, why not use any local editor?
For a full replacement I would require a presentation app though.
Is there a planned option to selfhost the frontend for personal (and/or limited) usage?
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.
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.
I'd encourage everyone to take a look at blockstack.org and feel free to review Graphite's repo (it's 100% open source): https://github.com/jehunter5811/graphite-blockstack
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 ...
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.”
I just tested this, and it is NOT a google docs alternative - it has no realtime sync (or at least, it wasn't working).
I work extensively on decentralized/P2P distributed systems and realtime P2P sync is non-trivial, you need to use a specialized CRDT for it:
- Here is an interactive animated explainer on how to do a P2P realtime syncing CRDT: http://gun.js.org/explainers/school/class.html
- Here is an excellent more detailed explanation of how such a CRDT works, by Martin Kleppmann: https://www.youtube.com/watch?v=yCcWpzY8dIA&feature=youtu.be...
Because real-time collaboration is not trivial, as you mentioned, we're making sure we do it right.
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?
Looks like a great project!
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!