undefined | Better HN

0 pointsmarknadal7y ago0 comments

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 .

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

0 comments

3 comments · 1 top-level

e12e7y ago· 2 in thread

Thanks for replying. I guess: 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?

e12e7y ago

Another, related, question: at 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.

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

j / k navigate · click thread line to collapse