Show HN: Graphite – A decentralized and encrypted Google Docs alternative - <AUTHOR> https://graphitedocs.com <comment><USER3> 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.

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

<comment><USER5> 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](https://bitcoin.org/en/glossary/51-percent-attack)

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

</comment></comment></comment></comment><comment><USER6> > Own your documents

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

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

<comment><AUTHOR> 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!

<comment><USER8> how does this differ from local documents combined with dropbox?

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

<comment><USER8> 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/](https://www.boxcryptor.com/en/)

<comment><USER9> > Boxcryptor

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

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> Graphite is an unfortunate name clash with graphite monitoring and metrics tools.

<comment><USER11> For now, if this takes off, monitoring is very niche compared to Docs.

<comment><USER12> If it takes off then will complicate life for ops. Very mean.

<comment><USER11> 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?

</comment></comment></comment></comment><comment><USER8> 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) - <USER2> 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](https://www.graphitedocs.com/features)

<comment><AUTHOR> This is really great! I appreciate the ideas and feedback.

</comment></comment><comment><USER13> 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.

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

</comment></comment><comment><USER14> 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'?

</comment><comment><USER15> This will easily be confused with Graphite the monitoring tool

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

<comment><USER16> Off the top of my head: Blockuments.

<comment><USER17> do[c]Chain ?

<comment><USER18> Graphate :)

</comment></comment></comment></comment></comment><comment><USER19> 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.

<comment><AUTHOR> 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?

<comment><USER20> 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/...](https://forum.blockstack.org/t/blockstack-mobile- plans/3621/6?u=larry)

We want to really reduce the friction of on-boarding new users to amazing apps like Graphite.

<comment><USER21> 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/](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!

</comment></comment></comment></comment><comment><USER22> 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.

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

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

</comment></comment></comment><comment><USER23> 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...

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

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

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

</comment></comment></comment></comment><comment><USER24> 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](https://blockstack.org/whitepaper.pdf)

* Each of the System Design documents listed here: [https://github.com/blockstack/blockstack-core/tree/master/do...](https://github.com/blockstack/blockstack-core/tree/master/docs)

* Blockstack General FAQ: [https://blockstack.org/faq](https://blockstack.org/faq)

* Blockstack Technical FAQ: [https://github.com/blockstack/blockstack-core/blob/master/do...](https://github.com/blockstack/blockstack-core/blob/master/docs/faq_technical.md)

* Blockstack Repository Readme: [https://github.com/blockstack/blockstack-core](https://github.com/blockstack/blockstack-core)

* The Graphite FAQ: [https://www.graphitedocs.com/faq](https://www.graphitedocs.com/faq)

* The Graphite Features: [https://www.graphitedocs.com/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](https://restic.readthedocs.io/en/latest/100_references.html)

* Wireguard: [https://www.wireguard.com/protocol](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.

<comment><USER25> 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/...](https://github.com/blockstack/blockstack.js/blob/master/src/encryption.js#L63)

[2] [https://github.com/blockstack/blockstack.js/blob/feature/aut...](https://github.com/blockstack/blockstack.js/blob/feature/auth- doc-improvements/src/auth/README.md#app-private-key)

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

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

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

<comment><USER28> This is solved: [https://developer.mozilla.org/en- US/docs/Web/Security/Subres...](https://developer.mozilla.org/en- US/docs/Web/Security/Subresource_Integrity)

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.

<comment><USER26> From [https://www.nccgroup.trust/us/about-us/newsroom-and- events/b...](https://www.nccgroup.trust/us/about-us/newsroom-and- events/blog/2011/august/javascript-cryptography-considered-harmful/)

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

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

<comment><USER29> _> 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"_.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER30> 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.)

<comment><AUTHOR> 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 :)

</comment></comment><comment><USER31> 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](https://blockstack.com/tokenpaper.pdf)

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

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

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

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

</comment></comment></comment></comment></comment><comment><USER36> 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.

</comment><comment><USER37> 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.

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

<comment><USER39> Yes, it's in the FAQ.

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

<comment><AUTHOR> 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](https://github.com/jehunter5811/graphite-blockstack)

</comment></comment></comment></comment><comment><USER18> 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!

<comment><AUTHOR> Absolutely! End of March is the target.

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

</comment></comment></comment><comment><USER40> Are there any plans for an Android App, or will it all be browser-based?

Also where is the github/code located?

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

</comment></comment><comment><USER39> >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?

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

<comment><USER43> If it's stored on Google Drive, why not use Google Docs?

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

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

</comment></comment></comment></comment><comment><USER44> I still don't understand why everyone is going on about the block chain

</comment><comment><USER45> Is the 16mb unsplash photo on the landing page really necessary?

</comment><comment><USER46> 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?

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

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

</comment><comment><USER48> When is the ICO?

<comment><USER49> Blockstack already had one. [https://icodrops.com/blockstack/](https://icodrops.com/blockstack/)

</comment></comment><comment><USER50> This is probably a very naive question: What are the main differences between this and git?

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

<comment><AUTHOR> 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](https://github.com/jehunter5811/graphite-blockstack)

</comment></comment></comment><comment><USER17> 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.

<comment><AUTHOR> 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!

<comment><USER17> Gambate !

</comment></comment></comment><comment><USER52> What is Blockstack, in clear English?

</comment><comment><USER53> 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](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...](https://www.youtube.com/watch?v=yCcWpzY8dIA&feature=youtu.be&t=29m36s)

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

<comment><USER53> 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](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?

<comment><AUTHOR> I sincerely appreciate that. Joining the Gitter room now :)

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

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

</comment></comment><comment><USER55> Another unnecessary application of blockchain tech.</comment>


Android consumers 'are put off by paying'  - <AUTHOR> http://www.develop-online.net/news/38133/Android-consumers-dont-believe-in-paying-for-content <comment><USER2> I think the reason why android doesn't have a large paid app base is due to the lack of a well designed purchasing ecosystem. People have been using(read: spending money with) iTunes for nearly a decade. They know it and they trust it. The fact developers can be sure people will have a smooth process buying their apps encourages the best developers to use iOS as their preliminary platform. Until android has a trusted payment system that allows easy payments, developers will not spend the time to create apps for it.

</comment><comment><USER3> I'm "put off by paying" because when I buy a game it always looks like shit because it's all stretched out to fit a tablet. On top of that app discovery is painful.</comment>


The Keto Diet's Most Controversial Champion - <AUTHOR> https://www.theatlantic.com/health/archive/2019/11/patrick-arnold-ketones-baseball-balco/601399/ <comment><USER2> Keto did wonders for my depression. I was stuck with paranoia as well until i also cut out vegetables and all sugar. Today i'm feeling productive and worthy.</comment>


Building a Web App From the Ground Up - <AUTHOR>

You are a blank slate and want to learn how to build a web app from the ground up.<p>1. What language(s) are you learning? 2. What Tools are you using? 3. What Infrastructure/Programs are you building it on? (ie What database, hosting, web/app server, etc) <comment><USER4> Language - <USER2>

Framework - <USER3>

Database - MySQL (since I've learnt about it from my university)

Hosting - AWS or Webfaction

No particular choice of infrastructure. Since I'm learning to build a web app from scratch, I'll tend to focus more on getting various pieces together.

</comment><comment><USER5> I'm a fan of PHP, it was the first scripting language I've learned and I still feel pretty comfortable using it.

When developing web applications I still stick to a LAMP stack:

Language: PHP on server-side, JS on client-side

Server: Apache

Database: MySQL

Frameworks: Basically any MVC framework

Hosting: Completely up to you

If you want to built a good web application you have to deal with:

Object-orientation, Dependency Injection, MVC, Design patterns, etc.

If you follow the most common coding principles, DRY, Separation of concerns, etc. you'll produce clean, maintainable code.

</comment><comment><USER6> Javascript. You have to know it for a web app, so start there. Build the front-end in it. Once you get decent at the front end, you'll know a lot more about programming so you then make a much more informed decision regarding a backend language and framework that works for you. Could be ruby, python, php, clojure, scala, etc. or even more javascript. Delay the decision of which back end to learn to the last responsible moment.

<comment><USER7> That's a great advice. I would say, in this day and age, if you are starting to learn then learn it correct. Learn a JS framework like Angular and build your client as purely browser based and learn another framework such Ruby-on- Rails or Laravel or CodeIgniter to just serve JSON data for your JS client. I think that's the route to go as your data feeds can be leveraged on many different mobile clients as well.

</comment></comment><comment><USER8> I'd definitely go with AWS for deployment only because if you never signed up before you get a micro instance for free for a year in most cases.

This gives you an ability to deploy multiple toy projects without having to fork out $5-10/month which isn't a ton but it's still an expense.

</comment><comment><USER9> java/jsp, JSF framework, Mysql, apache server.</comment>


Apple's Rotten Response - <AUTHOR> http://www.newsweek.com/2010/07/16/apple-s-rotten-reponse.html

<comment><USER2> This is what passes for journalism? "Apple is so arrogant…"</comment>


Free access to British scientific research to be available within two years - <AUTHOR> http://www.guardian.co.uk/science/2012/jul/15/free-access-british-scientific-research

<comment><USER2> If there is anything that will kill free access, it will be this: "British universities now pay around £200m a year in subscription fees to journal publishers, but under the new scheme, authors will pay "article processing charges" (APCs) to have their papers peer reviewed, edited and made freely available online. The typical APC is around £2,000 per article."

APCs just murder the desire to publish at all.

<comment><USER3> I believe the idea is that future grants would stipulate that some percentage of the grant be used to cover publishing costs, whereas current grants include some money for subscribing to journals. That way the publishers are still guaranteed to get money, but anyone can see the results of the research. Certainly less ideal than circumventing publishers entirely, but hopefully a step forward.

<comment><USER4> I'm curious how this will work - who knows exactly how many papers they will publish at the start of a grant? And what about fields with low grant amounts (mathematics, humanities, etc?)

<comment><USER5> If I was a funding body I'd knock a few thousand off the initial grant and say "have the journal send me the bill when you publish a paper".

That way, you only have the expenditure if the research leads to published papers. If the research doesn't lead to papers, well, at least you're a few thousand better off. And of course the funding bodies would know exactly who published what when where, and they'd get the right details in the paper's acknowledgments every time.

As an alternative, if there was funding to publish only a limited number of papers that could reform the incentives that lead to "salami publication". Or perhaps it would lead to a worst-of-both-worlds where salami publication cost funding bodies a bunch of money. We shall see!</comment></comment></comment></comment>


String Cheese Incident 'hacks' around Ticketmaster sales - <AUTHOR> http://www.nytimes.com/2012/05/16/arts/music/string-cheese-incident-takes-on-ticketmaster.html

<comment><USER2> _But buying a ticket on the band's Web site has its own added cost: $12 to mail tickets by United Parcel Service, with no other delivery option offered. [snip] There was simply no way around that fee, Mr. Luba said._

That seems like a very high price for shipping a piece of paper. I'm certain USPS will do it for significantly less, with insurance and delivery confirmation. I wonder why that isn't a viable option in this case.

<comment><USER3> I just bought tickets to a show from ticketmaster as it was the only option available. They charge $2.50 to print your ticket at home or if you don't mind waiting 2-4 weeks you can get them mailed to you for free. Every other option was in the 1000-2000% markup on the shipping costs.

</comment></comment><comment><USER4> You're paying for the gold-plated toilets, gold plated sandwiches being delivered and gold plated whores that they use.

Having interviewed at a couple of ticketing outfits and working at one for a single day (before I decided over an meatball marinara subway at lunch that it was a scam touting outfit and I'd probably end up on Channel 4 Dispatches [small hint]), I can say that they are the most corrupt, disgusting businesses on the planet and should fuck right off this planet pretty quickly.

</comment><comment><USER5> I don't understand, what exactly is preventing them selling their own tickets? Is it that the venues are opting to go with TicketMaster when booking them? Can they not just refuse to go with TicketMaster and then sell their own tickets? I don't understand...

<comment><USER6> Yes, the theatre mentioned in the article opts to go with Ticketmaster for all their ticket sales, so the band couldn't sell their own tickets.

</comment></comment><comment><USER7> WTF, New York Times? Look at this bullshit editorializing:

"the band wants to ignore valid contracts and deprive theaters and promoters of standard revenue sources."

First off, they bought the tickets FROM THE THEATER BOX OFFICE. So no, they're not depriving the theater.

What they're doing is looking out for the FANS, which have been victimized by a far more complete and consumer-harming monopoly than Microsoft ever was. Ticketmaster should've been shut down decades ago. I've written to senators about it. These scumbags violate antitrust law in a way that should be a case study in schools around the world. Yet our "representatives" do nothing.

Ticketmaster even scalps its own tickets, which is inexplicably allowed while the same act by private citizens is illegal.

Bend over and take it, America.

<comment><USER8> BOATI was the name of my ticketmaster clone for a college CS class. I was livid about convenience charges for 'virtual' tickets.

Bend Over And TIcket

<comment><USER7> Love it.</comment></comment></comment>


Show HN: Sneak Video - Docker on Azure Private Beta - <AUTHOR> https://www.youtube.com/watch?v=Lxvg7OMcPac <comment><AUTHOR> As a Docker Captain I got early access to the Azure beta - I show you all the inside details on setting up the preview from getting the invite-email to deploying services live on your swarm.

Still waiting for your email? Try Swarm mode now in my Getting Started tutorials with Docker for Mac or Windows: [http://blog.alexellis.io/tag/swarmmode/](http://blog.alexellis.io/tag/swarmmode/)</comment>


Winning The World Series With Math - <AUTHOR> http://www.sciencenews.org/index/generic/activity/view/id/64589/title/Math_Trek__Winning_the_World_Series_with_math <comment><USER2> 1\. Stupid question, but are runners allowed to run out there in foul territory?

2\. The most usual cases where speed matters are two and three base advances-- double, triple, second to home on a single. I'd think the advantage would diminish in proportion.

<comment><USER3> Question one is a little complicated (but not very).

Rather than paraphrase, here's the relevant paragraph from the official rules:

"Any runner is out when he runs more than three feet away from his baseline to avoid being tagged unless his action is to avoid interference with a fielder fielding a batted ball. A runner's baseline is established when the tag attempt occurs and is a straight line from the runner to the base he is attempting to reach safely."

That's from 7.08 (a) (1).

I can't see any way this rule could prevent them from following the theory in this article - _possibly_ it might be problematic if the tag attempt occurs while he is still right near his original base (or home plate), but in that case he would surely be tagged out anyway.</comment></comment>


The story behind a photo of a snow monkey using an iPhone (2019) - <AUTHOR> https://iso.500px.com/snow-monkey-iphone-photo/ <comment><USER2> Off-camera flash is a great technique, even if I don't find as many opportunities as I'd like to use it in my own photography. There are a lot of inexpensive RF flash setups available online these days, and while they might not offer the same bulletproof reliability and versatility as a Nikon speedlight kit, with a little thought and practice you can get really amazing results out of a $50-100 investment.

<comment><USER3> A neat trick is to use your friend's/spouse's phone as an off camera light. doesn't have the same impact of a speedlight for things like freezing motion, but is very effective at getting a 3d light source on a face or whatever.

<comment><USER4> I once used a phone flashlight to paint light in a long-exposure photo of an object, to get the specular highlights right (because I didn't have access to decent lighting otherwise). Basically I wiggled the phone around in the areas where I wanted lights to be, while another camera took a 15sec exposure.

</comment></comment></comment><comment><USER5> No out-takes? Behind the scenes of the tourist trying to retrieve her pilfered phone??

<comment><USER6> Well, at least he (presumably) bought the rights to the pictures of the monkey stealing the camera.

<comment><USER2> There'd be no question of rights for any of the shots I saw in the article. My personal property being in your photo, taken in and of a public place, doesn't give me any ownership; if you take a picture of _me_ then it can be more complicated, but an object (or a monkey!) has no likeness rights of which I'm aware.

<comment><USER7> Related [https://en.m.wikipedia.org/wiki/Monkey_selfie_copyright_disp...](https://en.m.wikipedia.org/wiki/Monkey_selfie_copyright_dispute)

<comment><USER2> These aren't selfies, so the relevance is limited, even assuming (imo charitably) that the arguments against copyright in that case are other than specious.

</comment></comment></comment></comment></comment><comment><USER8> I find it sad that these monkeys are getting so many flash photos taken of them. I hate flash and I know that it's coming and why it exists. For a monkey I can imagine it's even more aggravating.

<comment><USER9> I can't speak too much about how the monkeys feel about flashes, but when I visited this same spring the monkeys barely even noticed the humans at all.

The springs they soak in were built by a nearby hotel to keep the monkeys out of the hotel pools. They feed them every day to keep them up and away from the hotel.

(Of course, when we walked by the hotel, there was a single monkey soaking in their pool.)

</comment></comment><comment><USER10> These monkeys are in the first scene of one of my favourite movies.

Baraka (1992) -- [https://www.imdb.com/title/tt0103767](https://www.imdb.com/title/tt0103767)

Check it out [https://www.youtube.com/watch?v=hbdFW6N782w](https://www.youtube.com/watch?v=hbdFW6N782w)

</comment><comment><USER11> Along side all of the more serious bits of the story and comments....

I love the fact that the monkey is subtly giving the photographer the finger....</comment>