feat(mobile): create main package #5
Conversation
Addresses #3
chore: add some context in the README
* Split pkg into repo/host/node
* host build mobile dedicated host (noop for the moment)
* repo build mobile dedicated repo, exactly the same as ipfs repo but add the
ability to add some custom configuration
* node build mobile dedicated node with the particularity to create a mobile host
* the main package can be bind using gomobile to create a ready-to-use
framework/aar
* individual pkg can be imported instead and be used for specific project
* Add simple makefile that show how to build the thing
gfanton
changed the title
aeddi
changed the title
host/host.go
Outdated
| // MobileHost is an host | ||
| var _ p2p_host.Host = (*MobileHost)(nil) | ||
|
|
||
| type MobileHost struct { |
There was a problem hiding this comment.
What's the purpose of this wrapper?
There was a problem hiding this comment.
The main purpose of this wrapper was to customize the host dedicated to the mobile, for example: we plan to add a native driver that notifies the host of connectivity changes (switch between wifi/4G/nothing, bluetooth enabled/disabled, internet connected/disconnect, etc...) so the host can adapt his behavior accordingly. For the moment, it does nothing but to show where you can add those upgrades. I don't mind to remove it for the moment.
There was a problem hiding this comment.
Got it. SGTM.
You might consider just spawning that as a separate service. However, wrapping the host does give you an easy way to manage the service.
init.go
Outdated
| API: ipfs_config.API{ | ||
| HTTPHeaders: map[string][]string{ | ||
| "Access-Control-Allow-Credentials": []string{"true"}, | ||
| "Access-Control-Allow-Origin": []string{"*"}, |
There was a problem hiding this comment.
This is extremely insecure.
There was a problem hiding this comment.
I agree, despite the fact this was only for testing, it's a real problem. even if we specify localhost, other apps running on the device will be able to access to the API, Also we should use a random port for the api on each run to avoid collision with other app on mobile and force the config to be updated accordingly (on each run). I don't see any way to expose http api securely for the moment, like @asutula said in #14, it should be better and more secure to expose all the core API directly in Java/Swift/Objc using gobind, but this will involve more works to do.
I will just manually rollback to a static port value as temporary solution for the moment.
There was a problem hiding this comment.
If it's for testing, it's probably fine. However, people tend to copy/paste example/test code... that's my main concern.
Actually, I'm pretty sure all apps on the device will get access regardless, right? CORs only applies to browsers. Would a unix domain socket work (ipfs/kubo#6678)? You could put that into a private shared folder (I think...)
There was a problem hiding this comment.
This is exactly what we were thinking yesterday about unix socket. With Android and iOS, it's easy to create files that are only accessible by our app.
We're trying to set this up ASAP.
There was a problem hiding this comment.
I'm excited about the unix domain socket (UDS) idea, but having a hard time finding info about HTTP over UDS for Objective C and/or Java. Not that it's impossible, but I don't see any existing solutions. Anyone seen otherwise?
There was a problem hiding this comment.
On android, you'd construct a java.net.URL with a custom java.net.URLStreamHandler (as far as I can tell). In objective C... you may need to use a third-party library.
There was a problem hiding this comment.
I find a small shortcut for the moment, instead of trying implementing unix socket in java/objc(/swift), I just exposed an IpfsShell with a unix socket transport to the ios/android side.
Im not exposing http api by default anymore but instead I add some helpers to setup API either by unix socket or tcp. It's not the best way to do but I think it will do the trick for the moment.
My main concern is for react native (in the example) it will be hard to make the WebUI works with the shell (via react native-bridge) since it uses the js-ipfs-http-client (it will be tricky to override this), but since it's only for the example I presume it's ok (?). However I can easily call IpfsShell api from react native with the react native bridge (without enabling tpc api).
I'm almost done, but I still need to implement iOS bridge and cleanup some stuff.
Tell me if it's ok for you so I can finish this tomorrow.
There was a problem hiding this comment.
I wonder if we can get js-ipfs-http-client to use an arbitrary socket.
There was a problem hiding this comment.
Cool idea with the "shell" object to be able to use http over UDS in Go! First questions that come to mind...
Are you able to support async/concurrent requests? That seems important for being able to write apps optimized to deal with larger amounts of data. Also, things like starting and stopping the node can take a non-trivial amount of time.
Do you see the possibility of a mechanism to push data from the node to the client? (I'm not totally familiar with the IPFS API, so maybe this isn't needed)
There was a problem hiding this comment.
(And those questions there apply to both the shell and ObjC/Swift/Java HTTP over UDS)
gfanton
force-pushed
the
dev/base
branch
3 times, most recently
from
77f5e43 to
7e0fa7c
Compare
|
There were the following issues with this Pull Request
You may need to change the commit messages to comply with the repository contributing guidelines. 🤖 This comment was generated by commitlint[bot]. Please report issues here. Happy coding! |
framework/aar