Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement browser compatibility #179

Open
tribou opened this issue Jul 4, 2017 · 16 comments
Open

Implement browser compatibility #179

tribou opened this issue Jul 4, 2017 · 16 comments

Comments

@tribou
Copy link

tribou commented Jul 4, 2017

Hello!

I'm coming from the direction of testing y.js for a web-based shared document editor. However, I started looking into your architecture for secure-scuttlebutt, and I really like what I've found so far.

I was curious, is there a browser implementation available or planned for this version of ssb? I ran across dominictarr/localstorage-scuttlebutt along with dominictarr/r-edit, but I'd hate to forego the latest end-to-end security architecture you've been working on lately. Is it possible to run this version of the database in the browser?

@dominictarr
Copy link
Contributor

first, there is "secure-scuttlebutt" and "scuttlebutt" they are based on the same basic idea of a protocol, but otherwise, completely different. those other ones work with scuttlebutt, which isn't secure per se. I am intending to get this working in the browser at some point though, and some sort of mutable document representation on top of it, but not really planning on updating "scuttlebutt"

you might also be interested in http://github.com/dominictarr/epidemic-broadcast-trees it's also about the part essential protocol part to scuttlebutt, but makes it more efficient and scalable!

@tribou
Copy link
Author

tribou commented Jul 4, 2017

Thank you for the clarification! I'll check out epidemic-broadcast-trees 👍

Regarding your intentions to get secure-scuttlebutt working in the browser, perhaps we could use this issue to track the progress? I'd be glad to help out where I can. Could you provide a high-level list of steps still needed for that to happen?

The idea that I'm chasing is to create a better opportunity for code-sharing between React, iOS/Android React Native, Electron, and an event-sourcing/AWS Lambda backend. I'm thinking the backend may need some custom logic to provide an initial authentication handshake and persist a snapshot of the state. Anyway, right now I'm just looking for next steps to get this package closer to the browser. Thanks for your help!

@tribou tribou changed the title Is there a browser implementation? Implement browser compatibility Jul 4, 2017
@dominictarr
Copy link
Contributor

Well, the main hurdle is getting https://github.com/flumedb in the browser. I am working on this at the moment, actually. the main problem is getting the indexeddb wrapper fast enough to be reasonable. I need to be able to load 100k records (100mb or so) into indexeddb in under 5 minutes.

@christianbundy
Copy link
Contributor

This issue is my main priority -- my daily driver is a Chromebook, and being able to use it in a mobile browser (or app) would be a total game-changer. If there's anything I can do to help this along, I'd be more than happy to throw a few hours at it. Thanks!

@dominictarr
Copy link
Contributor

oh awesome! so the biggest thing single obstical is to get the flume (database) stuff working well in the browser. I want to be able to load say, 150mb of data in at least 10 minutes. that really isn't too much data, but indexeddb (our only storage option, basically) is really quite slow.

From what I've looked into it currently, the best thing is build this api: https://github.com/flumedb/aligned-block-file on top of indexeddb. I also tried going into indexeddb directly, https://github.com/flumedb/flumelog-idb but it's slow with many small writes. It's fairly fast with large writes, which is why I think the best option might be to write a block store on top of indexeddb.

@mlegore
Copy link
Contributor

mlegore commented Aug 25, 2017

Is there a fork somewhere of this WIP?

@Rob-pw
Copy link

Rob-pw commented Oct 24, 2017

@mlegore, I believe at: https://github.com/ssbc/secure-scuttlebutt/tree/bump-flumedb, I've not yet tested it.

@Atavic
Copy link

Atavic commented Jan 28, 2018

Decentralization Protocols on Firefox 59: pyllyukko/user.js#366

@stale
Copy link

stale bot commented Oct 23, 2018

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 stale bot added the stale label Oct 23, 2018
@tribou
Copy link
Author

tribou commented Oct 23, 2018

I still would love to see a browser implementation, but it sounds like we may need a different way of architecting it to make it performant?

@christianbundy
Copy link
Contributor

Me too! Unfortunately I don't think this is something that we can resolve without replacing flumedb or making significant changes upstream, so I wonder whether this would be better tracked in the flumedb repo. What do you think?

@stale
Copy link

stale bot commented Feb 11, 2019

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

@regular
Copy link

regular commented Aug 29, 2020

ssb-browser-core got this covered, I think?

@tribou
Copy link
Author

tribou commented Aug 29, 2020

Nice, thanks for sharing. Would love to see it added to the ssbc org. Regardless, looks like a huge step forward in available browser APIs!

@regular
Copy link

regular commented Aug 29, 2020

It is! Very exciting! cc @arj03

@christianbundy christianbundy removed their assignment Jan 31, 2021
@stale
Copy link

stale bot commented Jun 2, 2021

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

@stale stale bot added the stale label Jun 2, 2021
@staltz staltz removed the stale label Jun 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants