Hacker News new | comments | show | ask | jobs | submit login
Show HN: Graphite – A decentralized and encrypted Google Docs alternative (graphitedocs.com)
330 points by jhunter1016 5 months ago | hide | past | web | favorite | 138 comments



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]

[1] https://bitcoin.org/en/glossary/51-percent-attack


> 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.


I completely agree.

Do you have any thoughts on a framework for classifying these 'decentralized' apps?


> Own your documents

Rule number one is not to rely on other people's computers to write them in first place.


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!


how does this differ from local documents combined with dropbox?


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.

[0]: https://www.boxcryptor.com/en/


> Boxcryptor

Closed source + no audit is not exactly what you'd want to see from a piece of security software.


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.


You can also use free rclone[0], where you can mount all kinds of storage targets and encrypt your files.

[0]: http://rclone.org


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.


Brilliant. Physical ownership is still a thing.


I can't agree more. AmazonBasics notebooks are great and cost under $10.


Graphite is an unfortunate name clash with graphite monitoring and metrics tools.


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"


Also clashes with a "smart font" system: http://scripts.sil.org/cms/scripts/page.php?site_id=projects...


It's such an obvious name clash, too.


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.


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.


For now, if this takes off, monitoring is very niche compared to Docs.


If it takes off then will complicate life for ops. Very mean.


There are only so many common words to go around. As long as something is not in the same biz, how mean can it be?


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.

[0]: https://www.graphitedocs.com/features


This is really great! I appreciate the ideas and feedback.


Cool concept, but note:

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...


You're absolutely correct. In this iteration, collaboration is achieved asynchronously. Share a file, receiver can edit, receiver can share back, etc.

Because real-time collaboration is not trivial, as you mentioned, we're making sure we do it right.


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?


I sincerely appreciate that. Joining the Gitter room now :)


Just checked out gun, I have to say the tutorials are very well done. I'm not a javascript guy but I've been enjoying them.

Looks like a great project!


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!


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'?


This will easily be confused with Graphite the monitoring tool


I don't think it'll easily be confused.

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.


Good feedback! I actually wasn't aware of Graphite Monitoring until this comment.



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!


"GraphiteDocs" would probably work better in the long run.


Graphite Docs is the legal name of the company :)


Off the top of my head: Blockuments.


do[c]Chain ?


Graphate :)


BlockDocs BlocDoc


DeDocs


Too many pages and things to fill before even trying the product. The way to even start a quick hello world is really not obvious.


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?


Larry from Blockstack here.

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.


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!


If I give a try to a similar product, I want it to be as easy as: https://framapad.org/

Then I can sign up, and so on.


Thanks. Unless I'm missing something, Framapad and Etherpad are centralized services. Graphite is decentralized.


Yes. The ease of experience is what i look for, not the same features. We all get a decentralised service is harder to setup.


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.


That's great to hear! I just noticed that functions like SUM and MEDIAN also work, which is a good thing.


Yes! All of the Javascript Math functions should work. Let me know if you hit one that's not working, though.


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

https://support.office.com/en-us/article/lock-or-unlock-spec...


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:

$ blockstack-core fast-sync


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.


Yeah, I guess it's more a criticism of Blockstack than Graphite specifically.


How is this free? From the FAQ I can see they store the data blobs in Azure. It will get really expensive really soon.


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).


I see no mention anywhere, on Graphite or Blockstack, about how the encryption actually works.

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'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!

[1] https://github.com/blockstack/blockstack.js/blob/master/src/...

[2] https://github.com/blockstack/blockstack.js/blob/feature/aut...


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.


Is there a fundamental issue with crypto in JS (side-channel attacks?) or is it just that available crypto libraries in JS are immature?


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.


In Airborn.io, I've solved this by installing some code in a Service Worker, which verifies all updates: http://blog.airbornos.com/post/2017/08/03/Transparent-Web-Ap...

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.


This is solved: https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

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.


From https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...

"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.


> 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.


> Unless you expect all of your users to build your app from source on linux that they built from source

You forgot to tack on "using compilers, etc., that they also built from source".


Shameless plug:

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.



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.


There's like 30 different points in this 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.)


Airborn is solid! Graphite is decentralized, where Airborn is not. But that's not to say Airborn isn't a great project.

And for what it's worth, Graphite is also operational :)


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.

I probably just don't understand.

[1]https://blockstack.com/tokenpaper.pdf


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.


That's a weird definition of 'decentralised' then.

That's just like saying that apt-get is decentralised because its open source and you get point it to different servers.


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.


> Ripple<->Stellar

stellar is not a ripple fork.[0] this is a common misconception.

0. https://twitter.com/JedMcCaleb/status/933358161783693312


It started as one though, IIRC, and later they wrote a new consensus protocol


Thanks for the clarification!


While you're technically true, it's practically impossible to manipulate Bitcoin in this way.


All protocols are governed by a oligarchy, aren't they? HTML, javascript, HTTP, IP etc.

If you want to push a change to Linux doesn't someone need to approve it before it's part of the official release?


Totally.


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.


100% decentralized?

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.


Sign in button does nothing on iOS 11. Also, is the project open source? Otherwise there is less appeal even though it is decentralized.


Graphite is not yet available on mobile. Desktop and laptop only until probably the end of March.


Yes, it's in the FAQ.


Ah yes so it is. I looked everywhere else but didn’t expect the FAQ to contain anything relating to that.

Do you know the link to the repositories? They are not in the FAQ.


Sorry I didn't put it on the marketing site. Need to get that updated. Here's the link: https://github.com/jehunter5811/graphite-blockstack


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!


Absolutely! End of March is the target.


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.


Sandstorm?


YES! Thanks. :)


Are there any plans for an Android App, or will it all be browser-based?

Also where is the github/code located?


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."


>Are there storage limits? >There are no storage limits for documents, spreadsheets, or messages.

>How much does it cost? >Graphite for personal use is completely free.

So, unlimited storage, shareable and decentralized, for free? Where's the bait?


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.


If it's stored on Google Drive, why not use Google Docs?

If it's stored on Dropbox, why not use any local editor?


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.


Because Crypto


Can I just say I found this thread very informative for tackling encryption on a web text editor/document storage:)


I still don't understand why everyone is going on about the block chain


Is the 16mb unsplash photo on the landing page really necessary?


This looks quite interesting.

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?


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.


When is the ICO?


Blockstack already had one. https://icodrops.com/blockstack/


Ha! I'll leave the ICOs up to the folks powering the ecosystem for decentralized apps.


This is probably a very naive question: What are the main differences between this and git?


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.


Not much of a better explanation than that! Thanks for posting that.

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


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!


Gambate !


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.”


What is Blockstack, in clear English?


Another unnecessary application of blockchain tech.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: