3 ms·

Right back to you! :) That is probably because I've done a poor job communicating it, since I'm still finding time to write about it. Thank you for bringing th

Right back to you! :) That is probably because I've done a poor job communicating it, since I'm still finding time to write about it. Thank you for bringing this up! Probably most relevant: I kinda sorta had a demo of a P2P LinkedIn working https://www.youtube.com/watch?v=ZiELAFqNSLQ https://www.youtube.com/watch?v=ZiELAFqNSLQ . So we do have an unstable API that automates key management and key sharing, but all production apps (notabug.io , etc.) today directly use our https://gun.eco/docs/SEA https://gun.eco/docs/SEA shim over WebCrypto. Unfortunately, that means you have to be aware of how to apply it - thankfully, we did make a cartoon cryptography crash course on this (in link), so it is viable to get started. Obviously, if you have any new insights, would love to hear it! Without SEA, gun is very much like what you say. With SEA, you can protect against just anyone randomly writing to GUN. Jump in and ask more Qs on https://gitter.im/amark/gun https://gitter.im/amark/gun about it, or you'll circle back around later - hopefully that is helpful directions? Thanks. Most important statement of mine: I bet you'll enjoy the cartoon cryptography series.

e12e 8y ago
Thanks for replying. I guess: https://gun.eco/explainers/data/summary.html https://gun.eco/explainers/data/summary.html sums up the situation - but there's a few things that aren't quite clear: by design, everyone can access all encrypted data? So there's some meta-data that's easy to find, such as checking if an account exist, and how much data is associated with it - and the ability to record the approximate rate that data is written to the account? For example, if the login is an email, the app is an exercise logger - I might be able to infer that someone is out jogging by looking at the data?
- e12e 8y ago
  Another, related, question: at https://github.com/amark/gun/blob/master/README.md https://github.com/amark/gun/blob/master/README.md we can read that: "Distributed - GUN is peer-to-peer by design, meaning you have no centralized database server to maintain or that could crash. This lets you sleep through the night without worrying about database DevOps - we call it "NoDB". From there, you can build decentralized, federated, or centralized apps." And then goes on to show how to boot an instance on heroku etc. But is a production setup documented anywhere? I'd assume one would want three server instances (to allow taking one down for upgrades) - to make sure clients can write data to a managed instance, in order to make sure data is backed up etc? Apologies if I've overlooked an obvious documentation link.
  - marknadal 8y ago
    Yes, can I follow up with you more on this later / in the chatroom[1]? I don't want to leave you hanging but won't be able to reply in detail for probably 1 week - but I do have an answer for you (I apologize the docs are slacking!). Thanks / sorry!

e12e 8y ago

Thanks for replying. I guess: https://gun.eco/explainers/data/summary.html https://gun.eco/explainers/data/summary.html sums up the situation - but there's a few things that aren't quite clear: by design, everyone can access all encrypted data? So there's some meta-data that's easy to find, such as checking if an account exist, and how much data is associated with it - and the ability to record the approximate rate that data is written to the account? For example, if the login is an email, the app is an exercise logger - I might be able to infer that someone is out jogging by looking at the data?

e12e 8y ago
Another, related, question: at https://github.com/amark/gun/blob/master/README.md https://github.com/amark/gun/blob/master/README.md we can read that: "Distributed - GUN is peer-to-peer by design, meaning you have no centralized database server to maintain or that could crash. This lets you sleep through the night without worrying about database DevOps - we call it "NoDB". From there, you can build decentralized, federated, or centralized apps." And then goes on to show how to boot an instance on heroku etc. But is a production setup documented anywhere? I'd assume one would want three server instances (to allow taking one down for upgrades) - to make sure clients can write data to a managed instance, in order to make sure data is backed up etc? Apologies if I've overlooked an obvious documentation link.
- marknadal 8y ago
  Yes, can I follow up with you more on this later / in the chatroom[1]? I don't want to leave you hanging but won't be able to reply in detail for probably 1 week - but I do have an answer for you (I apologize the docs are slacking!). Thanks / sorry!