ssb network in the browser

[ahdinosaur]

downloading and installing a desktop app is less ideal than browsing to a web page, which could limit the adoption of the ssb social network. @bnolan, @Widdershin, and @kellective are a few friends who are interested in p2p social networks purely in the browser, i'm keen for ssb to be an avenue to achieve this vision.

@pfraze, @dominictarr, @substack: what do we need for ssb to be usable in the browser? i know this discussion has come up a few times in various places, but i figured it'd be nice to have a dedicated issue (i couldn't find an existing one) to discuss and track progress towards this feature. i realize there's a diversity of tactics we could employ to achieve this, so keen to hear them all.

[dominictarr]

this neededn't actually be too difficult. there are two basic approaches:

lite-client (persist keys only): the client generates a key-pair, and pulls the client and all data from the pub-server each time. This would suffer more latency, and put more demands on the servers. This would probably just require a few tweaks to phoenix.

heavy-client (persist keys and data): we use level-js instead of leveldown. This would (eventually) run into limitations of the browser storage. This would be more work, but should be possible too... we just need to devote some energy to making things work in the browser.

[dominictarr]

This has always been the plan... but it just hasn't been prioritized yet

[pfrazee]

Im a little concerned about indexdb and domstorage because the browsers treat them like temporary storage, for instance chrome will clear both of them if you "clear browsing data" with "hosted app data" checked, and it may not be obvious to folks they'd lose their keypairs when they do that.

[Widdershin]

I think @bnolan has been thinking of a solution to that. He was telling me his idea of having a server store the keypairs, encrypted with a passphrase, so that you could recover your identity over email.

Now that I'm thinking about it, since you wouldn't really want to centralize storage of keypairs if you could avoid it, you could maybe even have trusted friends in your network store your encrypted keypair for later recovery.

[dominictarr]

@pfraze I think we just need to accept that browsers arn't perfect and roll with it. we can let users export their keypair - we should encrypt the keys even on the client...

You'd think that if they are encrypted onto the server that should be okay, except people don't choose passwords well, so if someone gets their encrypted keys and really wants to they can probably decrypt the people who chose the worst passwords.

What about just letting users export their keys, but store them on their device? Then they can recover them after a decache, but without having to trust a server with them.

[pfrazee]

@dominictarr I tried that with an app, it was ok. A keystorage browser extension might work too

something to consider, end-to-end encryption on a hosted app can't be guaranteed. At any time the host could deliver code to send the keypair back to the host. This isnt a problem, it's just not end-to-end mode. if the code is hosted, then maybe the keypair should be hosted too, and we can avoid these issues

[dominictarr]

@pfraze hyperboot addresses the concern of end-to-end on hosted app.

[pfrazee]

@dominictarr we should look more into that, Im also keen to build out the ssb package manager and then host SPAs on scuttlebot, since we can build in so many great security features that way (package signing, content-security policy, the version pinning hyperboot gives) plus other neat things like patches by non-authors and app tech- & issues-support via feeds.

[ahdinosaur]

cc @mitar, based on your comments: https://github.com/ssbc/phoenix/issues/394#issuecomment-113042724 and #172 (comment).

[mitar]

Thanks! Yea, I am interested in something like that for quite some time now. Especially for use inside mesh networks. So server side should only be to server the static content and maybe give you the list of of other clients in the network or something.

[dominictarr]

we have decided to go with an electron app, allowing us to use crypto implemented in C. since we do so much asymmetrical crypto this makes ssb significantly faster

[carloslfu]

I want this disscusion to be reopened, since WebAssembly is comming:

On February 28, the four major browsers announced their consensus that the MVP of WebAssembly is complete - Link Clark, here

Asymmetrical cryptography will be faster in the Web by using this technology. So the arguments @ahdinosaur shows are still valid, user experience and SSB adoption should be better if SSB runs in the browser.

[dominictarr]

yes, of course it was just closed for now
see these threads
%yYXsOihj80vH7fqL4HQiwdAHs594U8bPhCph5OCpCWs=.sha256
and also
%di/8i95Kx8pMLR8S2PrIQYiYaIHKo/n/DgmJB5vlM5s=.sha256

[dominictarr]

Oh, btw, this is something I'll become interested in working on soon.
This will work well once we get out of order messages
%kDrsaJXkDiRwit9mCCmqoWBqI3WWxBxp+82fjZELluU=.sha256

[arj03]

Seems that webassembly is already supported in chrome and firefox. I'm guessing its mostly getting the sodium stuff to cross compile and some things around storage that needs to be abstracted out?

[dominictarr]

@arj03 the sodium stuff is already good (otherwise the liteclient wouldn't work) it's mostly the storage situation.

mainly, improving https://github.com/flumedb/flumelog-idb and https://github.com/flumedb/flumeview-idb

[gmarcos87]

libsodium.js in the browser (JavaScript and WebAssembly) https://github.com/jedisct1/libsodium.js

[waozixyz]

what about using ipfs/orbit-db for data storage?
http://ipfs.io/
https://github.com/orbitdb/orbit-db

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[martin-v]

Any updates for this issue? I would really like to see something like ssb with decentralized browser only storage.

[arj03]

@martin-v you can use https://github.com/arj03/ssb-browser-demo, please note that main branch is WIP.

[KyleMaas]

@martin-v ssb-browser-demo is still a WIP, but it's being actively worked on and is becoming decently usable.

[martin-v]

Thx for the update and your work. I'm still very interested in using it in some of my projects, but I need to find the time for these projects first. I think the idea of a truly decentralized browser app is conceptually perfect for small privacy-protecting applications. Like shared ToDo-lists, shopping-lists, small event planing, personal multi-device wikis.

[khimaros]

@martin-v if you are interested in mutable data, https://github.com/earthstar-project/earthstar may be a good fit. it works well in the browser today and was designed for use cases such as wiki.

IIUC, earthstar has a similar architecture to ssb-browser-demo re: using a public proxy to trunk with the broader P2P network. looking further down the road, something like https://github.com/sockethub/sockethub could provide a common foundation for both.

[arj03]

To clarify ssb-browser does not use a proxy. It's a full ssb client that can communicate with other peers like for example over a room connection. But yes, earthstar is very cool if you are looking for something to tinker with.

[christianbundy]

Maybe someone else could clarify further, but I don't think that Earthstar uses a "proxy". It uses servers, like how SSB uses pubs/room servers/etc, but that's basically required unless you can establish a direct connection to your peer.

[khimaros]

it sounds like i was at least partly mistaken on both accounts!

what i was hoping to communicate is that websockets/webrtc don't work very well for pure peer-to-peer connections (even discounting NAT issues), so both ssb-browser and earthstar have worked around this in a similar way, using specialized servers.

@arj03 -- my understanding of the ssb-browser implementation (possibly dated) is that it needed a specialized pub in order to trunk with the rest of the network. it looks like, more recently, that is https://github.com/arj03/ssb-partial-replication -- is this optional and just for improved performance?

@christianbundy -- i see now that earthstar hasn't implemented DHT for pure peer-to-peer discovery and connections yet, so this "specialized server" approach was part of design from the start. thank you for pointing out my mistake.

[arj03]

@khimaros it just needs a ssb server with web sockets enabled. Partial replication is for now just an optimization (proof of concept), but it might end up being a bigger thing once we hammer out the details :-) Also DHT support might come soon.

[KyleMaas]

Hoping maybe we could make this a little more widely supported via #750, as well. The feature is there, it just has to be manually enabled right now.

DHT support in the browser (via the hyperswarm-web variant for the backend) is able to use WebRTC instead of just WebSockets, so theoretically no server would be necessary once the DHT process is done. Assuming that feature gets pulled into multiserver-dht.

[cinnamon-bun]

Since Earthstar was mentioned, I'll clarify: The work so far has been on the data format and not the communication protocol(s). Any way that peers can connect (someday) they can trade data.

So far we've only implemented SSB-style pub servers that hold data at rest. The browser-clients talk to pubs with a boring JSON/REST/HTTPS API. The next things we'd like to add are:

• "room servers" that proxy live connections between pairs of browsers
• hyperswarm for DHT connections between non-browser clients (...not sure how to get browsers into the DHT except via a proxy server)