3 ms·

Congrats Dominic and co! I saw that even Julian Assange was recommending scuttlebutt on Twitter!! A couple people have asked about browser based access and som

Congrats Dominic and co! I saw that even Julian Assange was recommending scuttlebutt on Twitter!! A couple people have asked about browser based access and some people have replied that that wouldn't work? Could somebody explain why? Me and Dominic have debated design a couple times, and on my own system we have P2P cryptographic identities working just fine in the browser (see https://hackernoon.com/so-you-want-to-build-a-p2p-twitter-with-e2e-encryption-f90505b2ff8 https://hackernoon.com/so-you-want-to-build-a-p2p-twitter-wi... for an example), so this should be possible with scuttlebutt also. Could anyone explain further?

no_identd 9y ago
Sorry to semi-hijack your comment there, but, could you perhaps outline the functional differences (besides the extremely obvious ones like "it's not the same protocol") between Patchwork, Briar (Check the 34C3 talk on Briar if you find yourself unfamiliar with it: https://www.youtube.com/watch?v=iRJ8vIh3dVU https://www.youtube.com/watch?v=iRJ8vIh3dVU - albeit I kind of doubt that'd end up the case), and secushare (see http://secushare.org/comparison http://secushare.org/comparison)? They seem to try to cover many of the same points, but they also seem to have quite a few differences. I primarily ask because secushare hasn't yet updated their comparison page to include Patchwork (although it already covers SSB), and because that same page has yet to account for the release version of Briar. Edit: Nevermind the difference to secushare, I've noticed secureshare has an entry on Patchwork in their FAQ, just not on their comparison page: http://secushare.org/answers http://secushare.org/answers
- marknadal 9y ago
  Apologies, I haven't heard of either of these things before. So you'd know more than me!
staltz 9y ago
Hi Mark. What's the underlying database used there? SSB in the browser is a subproject we're pushing forwards sometimes, but it's progressing slowly. One of the main obstacles is IndexedDB which seems to be much worse (in many aspects) than LevelDB, upon which SSB used to base itself. Nowadays SSB is based on FlumeDB, which is often backed by just the filesystem. Then there are other obstacles like building P2P connections through WebRTC.
- marknadal 9y ago
  Good to hear from you Andre! Yes yes yes WebRTC has been a ridiculous pain in the butt for me, which is why I still have websocket fallback as default - browsers really need to get their game together and improve WebRTC (I hear there is a new version coming up that should fix a lot of problems) What database underneath for the demo? GUN of course, we added a framework called SEA (Security, Encryption, Authorization) which seamlessly integrates Web Crypto API in the background so app developers don't have to fuss with it directly or learn the Web Crypto API (which is poorly documented and very confusing, but a life saver that it is available at all!). Huh, haven't heard of FlumeDB I will definitely check it out. Great progress BTW, super exciting to see the community grow!!! Yeah, IndexedDB has its quirks, I stuck with localStorage personally cause it works like a charm and is much faster than any perf I could get out of LevelDB (I must have been doing something wrong with Level, because it never worked as well as we were expecting). I'm very excited to see a browser subproject of SSB, that will be great. If it helps at all, we're currently refactoring and modularizing SEA which may help with SSB in the browser even if gun isn't needed or used. Let me know!
masukomi 9y ago
Browser based access is absolutely possible. Not only that it exists. It has 2 forms: If you want a read-only version of the network there are a couple servers that do that. It's useful for showing people who aren't on ssb interesting conversations. If you want to actually interact with the network that's possible too but there are... limitations / issues. There are 2 aspects to this. 1) it's a distributed network. So, either you need to stick a client in the cloud with a web interface (Patchfoo [1] is just such a client, but the interface is.... meh) OR you need to run the entire client in your browser, and the problem with that is where do you store the data? You're going to quickly exceed the max of local store (i forget what that is but if you start following lots of people and they post photos you're going to exceed it). 2) You can't afford to loose your private key. SSB uses Public Key Encryption and as such if you loose your key you can no longer prove that you're you so you become disconnected from all your prior posts and people following the old you no longer get updates from "you" because "you" can't post as the old you anymore. If you use multiple browsers then how would you sync the keys between them? Also, SSB uses a blockchain for each user. If you have the same keys on multiple computers and one computer posts before it's synced up with the last post from the other computer then you've just forked your chain and it screws up everyone who's following you because you don't know which version of the chain each follower has ended up on. [1]: https://github.com/ssbc/patchfoo https://github.com/ssbc/patchfoo
- marknadal 9y ago
  (1) is good! Great work! (2) is a concern but ultimately depends upon the key management question - we already solved this and made an animated explainer videos of it: http://gun.js.org/explainers/data/security.html http://gun.js.org/explainers/data/security.html (and you can see a demo of it working in action in the parent posts, or just check the source code). (3) the blockchain, yes that is problematic, and is exactly what me and Dominic were debating in 2014. If you use the CRDT approach (which is what we do) you don't have that problem. So again, these are all things that have doable solutions, nothing can stop SSB!!! Not even pesky browsers.

no_identd 9y ago

Sorry to semi-hijack your comment there, but, could you perhaps outline the functional differences (besides the extremely obvious ones like "it's not the same protocol") between Patchwork, Briar (Check the 34C3 talk on Briar if you find yourself unfamiliar with it: https://www.youtube.com/watch?v=iRJ8vIh3dVU https://www.youtube.com/watch?v=iRJ8vIh3dVU - albeit I kind of doubt that'd end up the case), and secushare (see http://secushare.org/comparison http://secushare.org/comparison)? They seem to try to cover many of the same points, but they also seem to have quite a few differences. I primarily ask because secushare hasn't yet updated their comparison page to include Patchwork (although it already covers SSB), and because that same page has yet to account for the release version of Briar. Edit: Nevermind the difference to secushare, I've noticed secureshare has an entry on Patchwork in their FAQ, just not on their comparison page: http://secushare.org/answers http://secushare.org/answers

marknadal 9y ago
Apologies, I haven't heard of either of these things before. So you'd know more than me!

staltz 9y ago

Hi Mark. What's the underlying database used there? SSB in the browser is a subproject we're pushing forwards sometimes, but it's progressing slowly. One of the main obstacles is IndexedDB which seems to be much worse (in many aspects) than LevelDB, upon which SSB used to base itself. Nowadays SSB is based on FlumeDB, which is often backed by just the filesystem. Then there are other obstacles like building P2P connections through WebRTC.

marknadal 9y ago
Good to hear from you Andre! Yes yes yes WebRTC has been a ridiculous pain in the butt for me, which is why I still have websocket fallback as default - browsers really need to get their game together and improve WebRTC (I hear there is a new version coming up that should fix a lot of problems) What database underneath for the demo? GUN of course, we added a framework called SEA (Security, Encryption, Authorization) which seamlessly integrates Web Crypto API in the background so app developers don't have to fuss with it directly or learn the Web Crypto API (which is poorly documented and very confusing, but a life saver that it is available at all!). Huh, haven't heard of FlumeDB I will definitely check it out. Great progress BTW, super exciting to see the community grow!!! Yeah, IndexedDB has its quirks, I stuck with localStorage personally cause it works like a charm and is much faster than any perf I could get out of LevelDB (I must have been doing something wrong with Level, because it never worked as well as we were expecting). I'm very excited to see a browser subproject of SSB, that will be great. If it helps at all, we're currently refactoring and modularizing SEA which may help with SSB in the browser even if gun isn't needed or used. Let me know!

masukomi 9y ago

Browser based access is absolutely possible. Not only that it exists. It has 2 forms: If you want a read-only version of the network there are a couple servers that do that. It's useful for showing people who aren't on ssb interesting conversations. If you want to actually interact with the network that's possible too but there are... limitations / issues. There are 2 aspects to this. 1) it's a distributed network. So, either you need to stick a client in the cloud with a web interface (Patchfoo [1] is just such a client, but the interface is.... meh) OR you need to run the entire client in your browser, and the problem with that is where do you store the data? You're going to quickly exceed the max of local store (i forget what that is but if you start following lots of people and they post photos you're going to exceed it). 2) You can't afford to loose your private key. SSB uses Public Key Encryption and as such if you loose your key you can no longer prove that you're you so you become disconnected from all your prior posts and people following the old you no longer get updates from "you" because "you" can't post as the old you anymore. If you use multiple browsers then how would you sync the keys between them? Also, SSB uses a blockchain for each user. If you have the same keys on multiple computers and one computer posts before it's synced up with the last post from the other computer then you've just forked your chain and it screws up everyone who's following you because you don't know which version of the chain each follower has ended up on. [1]: https://github.com/ssbc/patchfoo https://github.com/ssbc/patchfoo

marknadal 9y ago
(1) is good! Great work! (2) is a concern but ultimately depends upon the key management question - we already solved this and made an animated explainer videos of it: http://gun.js.org/explainers/data/security.html http://gun.js.org/explainers/data/security.html (and you can see a demo of it working in action in the parent posts, or just check the source code). (3) the blockchain, yes that is problematic, and is exactly what me and Dominic were debating in 2014. If you use the CRDT approach (which is what we do) you don't have that problem. So again, these are all things that have doable solutions, nothing can stop SSB!!! Not even pesky browsers.