-
Notifications
You must be signed in to change notification settings - Fork 325
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
Support for js-ipfs as a replacement for HTTP gateway #248
Comments
I've been trying to do this, by intercepting the requests with the API that the web extensions provide and there are ways of canceling or redirecting requests, but I haven't found a way of injecting content into the request's body or overwriting it completely |
Would https://flyweb.github.io/ be a way to achieve this? Seems that the project has matured a lot since I last checked. |
Can't do much with current WebExtension APIs related to WebRequest. One can cancel request, redirect it and modify headers, but we can't create artificial response with arbitrary body. I glanced at FlyWeb and it does not seem to be feasible: my understanding is that "FlyWeb node" can't be run from within WebExtension, and if we expect user to run additional process in her system that could be "discovered" by Firefox.. it is just as good as running The only(??) "stable" thing that could work right now is HTTP gateway, we could use it the same way as go-ipfs one. I am not sure if it is possible for browserified Any ideas / hacks would be appreciated. I am shooting blanks at this one. |
It wouldn't be browserified/webpacked as that step would remove any native Node.js modules dependencies. To confirm, what you are saying is that we can open a TCP server or an HTTP server from a WebExtension? If yes, could you provide me with an example? I'm pretty sure we can get the full gateway working for js-ipfs as well pretty quickly. |
I don't we will be able to open TCP sockets in web extensions, there is no
API for that. However, we might be able to create a Websocket API that you
can use from a webpage, and that way load the content. That would be pretty
nifty actually.
…On Tue, May 9, 2017 at 10:07 PM, David Dias ***@***.***> wrote:
I am not sure if it is possible for browserified js-ipfs to provide local
IPFS2HTTP Gateway (exposing tcp port with HTTP service just like go-ipfs
does),
It wouldn't be browserified/webpacked as that step would remove any native
Node.js modules dependencies. To confirm, what you are saying is that we
can open a TCP server or an HTTP server from a WebExtension? If yes, could
you provide me with an example? I'm pretty sure we can get the full gateway
working for js-ipfs as well pretty quickly.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#248 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAcD9I3SokDUyd-9VKkbq5MiDr0L5zswks5r4MeQgaJpZM4NVxl9>
.
|
@victorbjelkholm even if we hack around and pass resource data over Websocket API, I am not sure how we could construct artificial HTTP response with it. Example: addon intercepts request to resource at @diasdavid there is an open Bug 1247628 - Enable "TCP and UDP Socket API" for WebExtensions, which would be game-changer for us. Without it, we can't really have real "http gateway" provided by |
Yeah, not fully developed thought yet but if we inject a tiny script to
read from websocket endpoint on `onHeadersReceived` and use that to read
the content, it might be possible. But as I said, not fully sure this is
even possible.
…On Tue, May 9, 2017 at 10:23 PM, Marcin Rataj ***@***.***> wrote:
@victorbjelkholm <https://github.com/VictorBjelkholm> even if we hack
around and pass resource data over Websocket API, I am not sure how we
could construct artificial HTTP response with it.
Example: addon intercepts request to resource at https://ipfs.io/ipfs/
<mhash>, we read data at <mhash> from js-ipfs instance via Websocket API.
And.. what then?
PS. FYI there is an open Bug 1247628 - Enable "TCP and UDP Socket API"
for WebExtensions <https://bugzilla.mozilla.org/show_bug.cgi?id=1247628>,
which would be game-changer for us.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#248 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAcD9G0StJDqgekBZehgzbAOw66EGCDKks5r4MtNgaJpZM4NVxl9>
.
|
There is no obvious way to "manually build response" with WX APIs, but I wonder if thinking outside the WX box and using something like Service Worker API could be our silver bullet[3]:
[1]: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/webRequest |
That would require Service Workers to be spawned from a WebExtension and we would have to spawn one for every domain so that the requests can be captured. That gives me an idea of having a |
Idea: if we keep already existing redirect in |
Yeah, that can work two
|
So, just to make sure we are all on the same page (this is indeed very interesting). This is what I'm proposing: I'm convinced that this actually works! Then, we can juice this up by running another js-ipfs node in the extension so that we can also have WebRTC enabled, since WebExtensions are closer to get RTC DataChannel than Service Workers. |
This means offline use cases will be impossible eh? What about @kyledrake's search bar hack? |
@lgierth it doesn't mean that at all. You just need to load it once and you are golden. What search bar hack? Could you provide url? |
Okay that's much better :) Still not ideal but something one could work with :) I just checked about the search bar hack, and it was purely to capture |
So, service-worker.ipfs.io would have to expose:
right? |
Yes :) |
Ideally the serviceworker installation could happen semi-automatically when installing the webextension. So that's it's just really hard to miss it. |
Does service-worker.ipfs.io have to be a js-ipfs node? I figure it can just be a regular gateway, with |
@diasdavid would the service worker run in an iframe as @kumavis suggested? That gives you the ability of sharing the IPFS node across all the tabs that load the iframe. |
@lgierth the point of it being a js-ipfs node is so that you don't have to touch the Gateway through HTTP and you route all the content requests through http. I might be missing your point if it happens to be a gateway node, how would that be better than just making requests to the gateway? @dryajov no need to do it for what we are trying to achieve with the WebExtension, but yeah we could. The point is not to share the IPFS node so that apps can use it programmatically, it is to fetch content through IPFS protocol. |
Oh yeah the actual service-worker is of course a js-ipfs node -- what I mean is the thing that serves the service-worker.js in the first place. That can be a simple dnslink page from what I understand. |
Ah! Yeah, sure, the service-worker is not any endpoint on the Web, it just needs to be a place to fetch a blob of JS, so yes, even the way the service-worker is loaded can be done through IPFS :) |
Cool cool 👍 |
do requests across domains hit the service worker?
seems likes no, but they are considering it because of this, we need to redirect the request to a service worker or iframe
cant use tcp/udp or webrtc in ServiceWorker atm tho 😿 |
Can you use FlyWeb in a ServiceWorker though? FlyWeb will take care of local discovery, and the upcoming merge of the js-ipfs and go-ipfs networks takes care of global discovery. With this, the lack of webrtc discovery is less of a pressing issue imho. |
@lgierth the assumption is you're running a node locally? |
metamask (ethereum browser integration) deals with these same limitations: happy to share all i've learned and hope we can come up with something else clever |
Yes, that is what is being proposed here: #248 (comment) :) Just to be clear, what we are trying to solve first with this approach is to make any
Unfortunately no. FlyWeb won't appear on Chrome anytime soon too.
Yeah, with relay in it will work just fine :)
Locally as in "inside the Service Worker", no daemon needed |
I believe this is what circuit will bring. |
@dryajov i was talking more about the ethereum network, but yes ipfs has a nice solution on the roadmap there |
@diasdavid no tcp/udp or webrtc - just going to hit a local node via http and fallback to the gateway? |
@kumavis Not necesarily, with circuit you can dial to a browser node, albeit over a third relay node, but all content in browser should be reachable without the need of HTTP or the gateway. |
quick update: making progress here -> https://github.com/ipfs/ipfs-service-worker/tree/v0.1.0 Now I need to complete this the Awesome WebWorkers endeavor because WebWorkers and Service Workers share the same limitations (i.e: Window is not defined) |
:+1 |
Update: ipfs-shipyard/ipfs-service-worker-demos#1 (comment) Any service worker experts out there? I've a couple of questions that I'm not finding good answers on the interwebs |
We may also be able to redirect to an extension URL. On firefox, this would be |
I feel a quick update is due, so here are some news from "js-ipfs in webextension" land:
Implementation is experimental (and Brave-only), Due to missing apis, we can't use js-ipfs in Firefox and Chrome yet, but we are playing with idea of using js-ipfs as a fallback for uploading content when go-ipfs is down. |
Closing this with Q3 2018 status update :) Service Worker endeavor
Follow above links for future SW updates. Injecting payload from js-ipfsAs for "js-ipfs fetching responses and returning them to user without hitting HTTP" we have a prototype of mozilla/libdweb native protocol handler capable of doing just that (works with both js-ipfs and js-ipfs-api). Protocol handler work continues in #533 We also have working prototype of local discovery and TCP transport, which reuses FlyWeb's internals via some high level APIs: #553 |
Right now this extension relays on the HTTP Gateway to serve the pages through IPFS. Ideally, we should be able to capture the requests and reply back without having to make a request to a gateway, this way we could serve pages from js-ipfs too.
Thoughts @lidel ?
The text was updated successfully, but these errors were encountered: