It's not loading in orbit.chat

[daviddias]

Hi @haadcode!

I noticed that orbit.chat is currently unusable. Mind updating it? Also happy to push a PR if you would take it in.

Thanks!

[haadcode]

Hi @diasdavid and good to hear from you! :)

Can you elaborate what's happening and what the error is? I'm able to go to orbit.chat, load the app and get chatting between two browsers locally and had a chat with someone random on using orbit on mobile.

Would be happy to work you through an update PR if you want but beware that the code hasn't been touched in a while so there might be more to update than it may seem.

That said, I've noticed Orbit has started randomly crashing (both Chrome and FF) and on Firefox it just kills the browser completely (hangs). This is seemingly random and I haven't been able to debug it yet. Orbit hasn't been updated since Apr, so only the browsers have had updates in the meanwhile.

[daviddias]

It is good to see you back on Github, @haadcode :):)

Expanding in the description of my bug report, essentially, I never get it to pass this screen:

And today, I did get errors in the console:

Which browser version are you running?

[haadcode]

I've seen many, many different error messages along the way but never that one :) I have no idea what that is. I'm quite sure orbit doesn't have generateKeyPair function in its code, so perhaps it's coming from a dependency. Not sure if the "IDBTransaction" callback is related necessarily but it could have something to do with the IPFS repo, right? Have you tried with different usernames or in an incognito window? Maybe there's an old or otherwise incompatible repo that Orbit is trying to open?

I'm on Chrome 60 and Firefox 55.

[daviddias]

Started checking what was necessary to update this and realised it requires to dig up and update more dependencies such as ipfs-daemon.

Readme of ipfs-daemon notices its users that it is going to get deprecated

Is the next step removing it as a dependency from this repo?

[haadcode]

Thank you @diasdavid for the PR! Indeed, we're still using ipfs-daemon in all of the orbit stack. I would love to get rid of it and kill it and use the official ipfs module.

As to why that is still the case is:
Originally, I wanted to use IPFS through the same API for both the Node.js version and the go-ipfs version (via js-ipfs-api) but they both required different way to get IPFS up and running. We designed the new ipfs.on('ready', ...) API to have a nice and easy way to start the Node.js instance, but as far as I know, we never implemented the .on('ready', ..) API for js-ipfsd-ctl. This is essentially what ipfs-daemon does: provides the .on('ready') API for Orbit and orbit doesn't have to distinct between js-ipfs and go-ipfs in any way.

If we were to switch from ipfs-daemon to ipfs, it should work out-of-the-box ish without other changes than the configuration that is passed to the constructor. For the go-ipfs version (which is used in the Orbit Electron version) that would mean either still using ipfs-daemon or updating the js-ipfsd-ctlAPI to match the one in ipfs OR we drop the support for go-ipfs (using js-ipfs-api) for now.

Also, note that orbit-db currently uses a custom version of floodsub that has the "send-previous-message-on-peering" feature that @dignifiedquire did long ago, and that PR is quite behind from master I believe. So we'd need to sort that out, too, as Orbit really needs the functionality that dignifiedquire's floodsub PR provides.

What do you think?

[daviddias]

The issue with .generateKey is due to this -> libp2p/js-libp2p-crypto#105. The best is for Orbit to notice when it is being loaded from non https resource and recommend or redirect the user to https

So we'd need to sort that out, too, as Orbit really needs the functionality that dignifiedquire's floodsub PR provides.

Not necessarily. That feature is "on peer connect, send last message again" which is pretty much a .on('peer:connect', callFunctionThatSendsLastMessageAgain), it can be done at the Orbit layer.

This not to say that PubSub in the feature won't have more primitives that enable users to do more elaborate things (reliability, the auth log itself, etc), but it might still take some time so I don't want to get you blocked there or constantly using a branch when you can indeed do it on the app level.

[gyuri-lajos]

Hi @daviddias and @haadcode

I really appreciate all the work you do.

I found this issue as I was researching another one that I encountered using Firefox: where the ipfs.on 'ready' event is not called.

Regarding the generateKey exception reported here, I encountered it in Chrome when accessing my Orbitdb based app via http

This is because, in Chrome, as stated int the thread linked here, WebCrypto is not allowed on HTTP

https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/DtOFo51WFMo

" the W3C Web Crypto working group extensively debated this for a number of years, with the resolution in w3c/webcrypto#28 of requiring [SecureContext] in the spec, which is what the W3C advanced to CR and (modulo a special corner case) what "Chrome implemented."

In the same thread you can read Andrew Sampson's comment:
"By locking people out from an API that is meant to protect information, you're forcing people to use insecure methods to achieve their goals.

As my colleague put it, you're not preventing people from using crypto in the web, you're just preventing them from using the fastest method for it. It seems a bit silly to take an "all or nothing" stance."

The following warning I see in Chrome in secure context may well be related to this issue too.

Thankfully, Firefox is more permissive, and allows non secure contexts that can work with non secure signalling servers, like the one I set up over the holidays.

[latenssi]

Closing this as orbit.chat has been updated!

[daviddias]

YEAAAAAAH!!! :D