run make build_core.android error
How to resolve this error?

Any plans to support flutter?

Here's the Weekly Digest for berty/gomobile-ipfs:

ISSUES

Last week, no issues were created.

PULL REQUESTS

Last week, no pull requests were created, updated or merged.

COMMITS

Last week there were no commits.

CONTRIBUTORS

Last week there were no contributors.

STARGAZERS

Last week there were no stargazers.

RELEASES

Last week there were no releases.

That's all for last week, please 👀 Watch and ⭐ Star the repository berty/gomobile-ipfs to receive next weekly updates. 😃

You can also view all Weekly Digests by clicking here.

Your Weekly Digest bot. 📆

We noticed that the settings tab was inaccessible on the webui. It would be convenient to be able to modify the config without having to recompile the application while debugging/testing.

Since the tab is greyed out, we figured it was a planned behavior, probably just a boolean to modify somewhere so we didn't dig any deeper. :)

Unable to download dependencies ？？
https://dl.bintray.com/berty/gomobile-ipfs-ios/bridge/1.2.1/bridge-1.2.1.zip

• Write and integrate doc alongside the official go-ipfs documentation on the IPFS doc website
• Write various simple and complex examples

Very excited to see this repo take shape! At Textile, we've done a lot of the work that will be done here, but instead of wrapping the go-ipfs API, we've wrapped the go-textile API (which wraps the go-ifps API). I think we can transfer a lot of what we've done to this repo, and ultimately build the Textile mobile SDKs on top of gomobile-ipfs.

I want to start some general conversation and mention some high-level ideas that could point to more specific issues we could create and work on.

• HTTP API vs native API - We went quite far down the path of running the HTTP API, but ultimately found it be very insecure. Any method of securing the API seemed very complicated, especially on Android. It would be interesting to see if anyone figured out something here that we couldn't figure out.
• Golang to native data serialization - In the case of using native (non-HTTP) methods, we found it necessary to serialize data for passing back and forth from go to native and back. This is because gobind supported data types are limited and changes in object interfaces are hard to deal with. For these reasons, we went with Protobuf, but maybe there are other ideas.
• Node lifecycle - The app that the IPFS node is embedded within can't be running all the time. The OS will suspend and kill the app on a regular basis. If you start the node and the OS suspends the app, it's not clear what happens to the IPFS node, but when the app is un-suspended, it seems the node isn't functioning properly. Perhaps network connections were closed, etc. For this reason, we found it necessary to explicitly control the starting and stopping of the node using app lifecycle events.
• Maximize runtime in background - We're able to take advantage of native APIs to run the host app in the background opportunistically so that the IPFS node runs as much as possible.
• Repo/project structure - As you can see, the iOS and Android native-layer code gets complex and potentially should be managed as a separate projects. We settled on a nice setup where we have separate repos for the Go, iOS, Android, and React Native libraries. The structure of the code and APIs within each librarary is similar to provide a consistent developer experience and consistent API.
• CI integration - We have the Go, iOS, Android, and React Native libraries all building in CI and publishing release artifacts to Cocopods, Maven, and NPM.
• App Store compliance - Go 12 doesn’t build the framework in a way that passes the Apple App Store review, so there is a workaround we’ve patched together on our CI server to use a working combination of Go an Gobind.

Those are some of the areas that come to mind where I think we can contribute a lot. Let me know if any of those seem particularly important or not important at all. We can break things down into smaller pieces and get to work!

We noticed when writing/testing the example application that go-ipfs can barely connect to bootstrap nodes. It seems not to be able to do peer discovery and we see a lot of dial error and timeout in the logs.

We have since tested on our laptops with a classic go-ipfs node and a 4G tethering connection: same problem. In both cases we tried to do as much as possible to tweak the configuration without success. For the moment, we haven't had time to investigate further and It is possible that we missed an obvious detail.

Note that there are differences in connection characteristics depending on the mobile operator used (for example, some allow port forwarding). We tested only with the same French operator.

Also note that we didn't have that kind of problems with Berty which is built on top of libp2p. We were able to connect in 4G to relays without any problems and by using quic-transport, we could easily stay connected to a peer when switching between wifi <-> 4G.

Replace gomobile logger (GoLog) by a better binding for ipfs-go-log -> native logger.

Currently, all logs including their metadata are displayed by native logger as a plain text string with GoLog as namespace/tag and error as level. Logs are less readable, filterable, sortable, etc...

We need to forward each metadata (level, namespace, timestamp, etc...) and the log itself from ipfs-go-log to corresponding functions/parameters of Android logcat and iOS os_log.

In the Berty app, we have developed a system to update the network configuration according to the device's connectivity, it is currently complicated to extract this part from our code to integrate it to gomobile-ipfs but we will deal with it as soon as possible.

Android and iOS offer APIs that allow the OS to notify your application when a connectivity change occurs: 4G, Wifi, Bluetooth, internet access, etc....

Depending on the new state, several things are conceivable to save resources (CPU, network, etc...). For example:

• modify the different watermarks
• disable the mDNS if we are not connected to a LAN
• disable the reconnection attempt to bootstrap nodes (see bootstrapConfig) if there is no internet access, set the Period to 5 seconds if we are connected via a cellular connection and to 30 if we are connected via wifi
• etc....

infoRaw = ipfs.newRequest("add")
.withHeader("Content-Type","multipart/form-data; boundary=---AAA")
.withBody("---AAA\n" +
"Content-Disposition: form-data; name="file"; filename="file.txt"\n" +
"\n\n" +
"123\n" +
"---AAA--")
.send();

I'm trying to build the project for testing on iOS, I can't find any build instructions.

I have tried using the Makefile, but I am unable to successfully run any of the targets.

I tried various build targets, without luck, I guessed core was the base dependency and tried "make build_core.ios"

/Users/ajres/projects/go/bin/gomobile: /Users/ajres/projects/go/bin/gobind -lang=go,objc -outdir=/var/folders/qg/z2z6dspj3wz035snflhkf3vh0000gn/T/gomobile-work-188711949 -tags=ios github.com/ipfs-shipyard/gomobile-ipfs/go/bind/core failed: exit status 1
no exported names in the package "github.com/ipfs-shipyard/gomobile-ipfs/go/bind/core"
no exported names in the package "github.com/ipfs-shipyard/gomobile-ipfs/go/bind/core"
no exported names in the package "github.com/ipfs-shipyard/gomobile-ipfs/go/bind/core"
no exported names in the package "github.com/ipfs-shipyard/gomobile-ipfs/go/bind/core"

make: *** [/Users/ajres/projects/gomobile-ipfs/packages/build/ios/intermediates/core/Core.framework] Error 1

Add Berty team (https://github.com/orgs/ipfs-shipyard/teams/berty/members minus Alan) as lead maintainers for this repo!

In the Makefile,

If I remove the maccatalyst target it will works, or else it will report an clang error:
clang: error: invalid version number in '-target arm64-apple-ios13.0-macabi'

I'm trying to find an IPFS library to download some images on iOS. Came across this library from a blog article, but can't find any instructions on how to install it. The zipped releases seem to only contain the repository code.

Can you add support for Swift package manager? or provide some direction on how to include everything in a project?

• This step can be particularly tricky to implement, so we will add some helpers with sane default behaviors

• Using PL's existing CI for IPFS, setup a mobile CI pipeline that continuously tries to build go-ipfs with gomobile in order to track the evolution of stability and performance directly from the go-ipfs repo
• This won't be one the gomobile-ipfs repo but directly on go-ipfs with new GitHub action pipelines

DNS Lookup does not work by default with gomobile on Android and iOS (only on physical device). We needed to find a workaround until this golang issue is fixed.

At the moment we are using this method which is very hacky.

We could instead:

• Define a go interface containing a LookupTXT method
• Implement it in Java (using DnsResolver) and Swift (using DNSServiceQueryRecord)
• Find a clean way to override the default go-ipfs DNSResolver

• This will allow developers using gomobile-ipfs to simply establish p2p connections and implement logic around them.
• Example: a developer wants to create an application that displays notifications from a smartphone on a desktop PC without using servers will be able to use gomobile-ipfs to simply establish a direct connection between the two devices and implement the notifications transfer logic in the handlers.
• TODO: add code example for SetStreamHandler(protocolID, handler) and NewStream(peerID, protocolID) usage

The current build fails with the error You must specify a URL for a Maven repository. This is fixed by adding bintray_url to Manifest.yml. See c14bbe2 for an example of this happening.

This is fixed in #106, which is created to fix a different issue but also fixes this one.

Android Gradle build failed. Core has been compiled。
I don't know if anyone has ever encountered this problem

The example(s) can be made directly available from this repo or consist of a set of links to other repos.

The idea is clearly to help people find the relevant pieces of information.

I install the iOS demo on my iPhone, the "Share file" and "Fetch file" worked very well. But the "Random XKCD" report error:
cat: could not resolve name.

Caused by: go.Universe$proxyerror: pubsub/sub: experimental pubsub feature not enabled. Run daemon with --enable-pubsub-experiment to use

M1Pro
export GOROOT=/usr/local/go
export GOPATH=/Users/ym/gopath
export PATH=$PATH:$GOROOT/bin:$GOPATH/bin
export ANDROID_HOME=/Users/ym/Library/Android/sdk
export ANDROID_NDK_HOME=$ANDROID_HOME/ndk-bundle
export PATH=$PATH:$ANDROID_NDK_HOME

ym@ymdeMacBook-Pro ~ % go version
go version go1.17.6 darwin/arm64
ym@ymdeMacBook-Pro ~ % gomobile
Gomobile is a tool for building and running mobile apps written in Go.

To install:

$ go get golang.org/x/mobile/cmd/gomobile
$ gomobile init

At least Go 1.10 is required.
For detailed instructions, see https://golang.org/wiki/Mobile.

Usage:

gomobile command [arguments]

Commands:

bind        build a library for Android and iOS
build       compile android APK and iOS app
clean       remove object files and cached gomobile files
init        build OpenAL for Android
install     compile android APK and install on device
version     print version

Use 'gomobile help [command]' for more information about that command.

ym@ymdeMacBook-Pro ~ % cd /Users/ym/Desktop/gomobile-ipfs-master/packages
ym@ymdeMacBook-Pro packages % make build_core.android
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git

  Go: installing modules        

go mod download
go install golang.org/x/mobile/cmd/gomobile
go install golang.org/x/mobile/cmd/gobind
go run golang.org/x/mobile/cmd/gomobile init -v
panic: unsupported GOARCH: arm64

goroutine 1 [running]:
main.archNDK(...)
/Users/ym/go/pkg/mod/github.com/aeddi/[email protected]/cmd/gomobile/env.go:339
main.(*ndkToolchain).Path(0x14000199c90, {0x140000262d0, 0x28}, {0x103050931, 0x5})
/Users/ym/go/pkg/mod/github.com/aeddi/[email protected]/cmd/gomobile/env.go:368 +0x78
main.envInit()
/Users/ym/go/pkg/mod/github.com/aeddi/[email protected]/cmd/gomobile/env.go:142 +0x2f0
main.runInit(0x10336c480)
/Users/ym/go/pkg/mod/github.com/aeddi/[email protected]/cmd/gomobile/init.go:95 +0x558
main.main()
/Users/ym/go/pkg/mod/github.com/aeddi/[email protected]/cmd/gomobile/main.go:73 +0x4b0
exit status 2
make: *** [go] Error 1
ym@ymdeMacBook-Pro packages %

Can the writer help me to have a look

I have compiled the source code into aar package, but I still couldn't use the API after I introduced it into the Android project. Is there something wrong with it? Please advise

It is suggested that demo can be developed with object-C language

Because there are so many people using Object c these days

I've attempted to build and run the android example provided, and attempted to download the maven package using the repository listed in the .pom provided in the package on github.

Either way, the error:

Could not GET 'https://dl.bintray.com/berty/gomobile-ipfs-android/ipfs/gomobile/core/0.0.42-dev/core-0.0.42-dev.pom'. Received status code 403 from server: Forbidden

is thrown.

How do I resolve this? Thanks.

I can't find this “Core.framework”！！！

Where can I download it “Core.framework”？？？

Please reply me, thank you**

I don't know where to put "swarm. Key" to build my own private library.

Even if its interest is quite limited for the moment, we could easily make the demo application available on the different mobile stores so that developers/users could simply test it.

Concerning Android we could also make the APK available on Github releases.

• What makes IPFS on mobile special? What are the problems to solve on mobile?
• How can this repository be helpful for people? (code helpers, configuration tips, good place for mobile related discussions)
• Specify that for now, it's maybe easier to mix IPFS and libp2p stuff in this repo but in a few times it will worth splitting it and have a github.com/libp2p/gomobile-libp2p repo too
• Present Berty in the README
• Invite Textile team so they can do the same

We plan to add CI rules that build different artifacts: .apk for Android and .ipa for iOS

To build iOS artifacts, we need to have OS X hosts with Xcode installed

From what I can see, other ipfs-shipyard are using mostly Travis and CircleCI, and projects that require OS X are only using Travis:

• https://github.com/ipfs-shipyard/ipfs-companion/blob/8e2eaeeeec05797b166e0ac2e149e61c4527bf61/.travis.yml#L14
• https://github.com/ipfs-shipyard/ipfs-desktop/blob/92fcdd024caeaeeec864171f49a409dd0b2e3eb8/.travis.yml#L11-L13
• https://github.com/ipfs-shipyard/js-ipfs-http-client-lite/blob/b04523834f9a17275c7c076de6bd505af3756f63/.travis.yml#L14
• https://github.com/ipfs-shipyard/ipfs-pubsub-room/blob/b8556eccfa51c4d7110090f40fd6c934621aa8cf/.travis.yml#L17
• https://github.com/ipfs-shipyard/js-hamt-sharding/blob/23566a1215ab83c77c5cbd0037de3781279393b2/.travis.yml#L13
• https://github.com/ipfs-shipyard/service-worker-gateway/blob/1715faa70879418240ad3e4cf7237d060de60d37/.travis.yml#L13

Is it just a coincidence or is it expected to use Travis when having OS X builds to do?

Maybe we can update a CONTRIBUTING.md file with this info, feel free to indicate me the most appropriate place

Following up from the email thread and looping in @Stebalien. Let's move this repo into an ipfs-related org so we can get more eyes on the discussion + code.

There are two choices:

• Move into ipfs-shipyard: package this as a kind of "mobile SDK" on top of IPFS, similar to how peer-base relates to building dynamic data apps, or how ipfs-provider helps use multiple backends. Pros: loose coupling, lower integration overhead upfront. Cons: somewhat lower visibility, requires ongoing community stewardship.
• Move into ipfs core: integrate more deeply into the core modules (required to be placed in ipfs org). Pros: potentially deeper integration, lower risk of APIs going out of sync, etc. Cons: upfront evaluation and integration cost, needs core maintainer time.

My suggestion is to move into ipfs-shipyard and make public ASAP, possibly even before merging #5. We saw some amazing energy around this application area at IPFS camp, and not letting it wither is very important. Having a visible place for the discussion of IPFS-on-mobile is a big win even without shipped code. However, It might be worth completing #2, or otherwise clarifying what this module will actually do.

(N.B. most code is currently in #5, waiting on @gfanton to return from vacation)

`compileSdkVersion 30
buildToolsVersion "30.0.3"

defaultConfig {
    applicationId "com.example.ipfs_andorid"
    minSdkVersion 28
    targetSdkVersion 30
    versionCode 1
    versionName "1.0"

    testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
}`

basichost failed to resolve local interface addresses {"error": "route ip+net: netlinkrib: permission denied"}

• Improve the following bridge documentations: https://github.com/ipfs-shipyard/gomobile-ipfs
• Improve GoDoc: https://pkg.go.dev/github.com/ipfs-shipyard/gomobile-ipfs/go
• Add more unit tests

Seems that GitHub will remove set-env at some point, and that will break your CI:

Action and workflow authors who are setting environment variables via STDOUT should update any usage of the set-env and add-path workflow commands to use the new environment files.

Details: https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/

cc @aeddi (lmk if you need help with migrating)

比如**移动，**联通，**电信
美国 AT&T，Verizon和Sprint

It would be convenient for developers to have the ability to download the lib from the Github releases system to integrate it directly into their project without configuring the entire build system.

When the lib will be more stable / less "PoC", it would also be great to make it available on the repo of the Android and iOS dependency managers (Gradle, Cocoapods, etc...).

We could use the Github actions to automatically build and upload the lib for each version.

Hi guys,

I created React Native bindings for Android and iOS.

https://github.com/tesseract-one/react-native-gomobile-ipfs

Can get XKCD image from React Native :)

• improve the description
• add build example
• add code example

Hey guys,

just read the weekly newsletter, awesome project!

I wrote down some ideas how a WebOfTrust could help in personal usage of IPFS by adding nodes as "friends" and allow them to (push/)store a given amount of data onto your node.

This way you could use IPFS as some kind of cloud storage, while only your friends hold the data in a sharded/redundantly way.

This can allow allow for easier access to the network for mobile clients, since you could connect primarily to your own nodes and nodes of your friends, having them do the heavy lifting, like running a constant connection to many hundreds of clients to allow a properly working DHT.

The mobile clients can just query them to let them query the DHT and let them push the results as soon as they are available to the mobile client.

They could also buffer/cache downloads to avoid that bursty/lossy connections dropping your download connections all the time, resulting in constant reconnects to nodes which might throttle back the reconnect speed or block the connects all together to avoid DDoS.

It would also allow for sharing personal data between devices while only one of your device is online at a time, which would be a quite exiting feature.

ipfs/notes#397

@gfanton can you start an initial import of generic gomobile+IPFS code?

Feel free to make it small at the beginning, we will progressively add more and more code, but it will be easier to discuss the whole strategy based on something concrete.

Thx!

For the moment, the limits that we set in the config concerning the number of peers (high/low watermarks, grace period) does not seem to regulate correctly the maximum number of connected peers (probably due to a misuse / misunderstanding on our part).

We need to find a way to precisely control the maximum number of peers a device is connected to because:

• On iOS and Android, the number of connected peers is strongly related to the resource consumption
• On iOS a problem occurs very quickly: the OS throws "too many open files" errors when it reaches about 200 connected peers (this limit is not configurable on iOS)

I will do precise tests with different high/low watermarks and grace period settings and post reports on this issue so that we have a better view of the problem before thinking about solutions.