A report on the state of ipfs on iOS.

[seclorum]

On this repo:

EDIT: new repo: https://github.com/seclorum/ios-go-ipfs

.. is now a functioning iOS project set up to allow Go and Objective-C/frameworks to co-exist - i.e. Go on iOS. It works well enough to host a web server (from Go side) and do basic data interchange between Obj-C/Go runtimes. Just the basics, but functional so far for a basic set of Go packages.

The ipfsios XCode project is also set up to include and build a test ipfs daemon, with the intention that "ipfs daemon" is done alongside good ol' ApplicationDelegate at startup, and PeerID's are a-happenin' .. although this is currently in broken state and unrealistic at present - some things are simply missing in the goios syscall department, it seems. But at least the framework is there to include ipfs on iOS as a target.

So far the list of things to fix seems promising - but I'd be happy if you ipfs guys could take a look at the build output in this issue and make comments? End-goal, ipfs on iOS! :)

https://github.com/seclorum/ipfs-on-ios/issues/1

[seclorum]

Okay, ipfs is building fine on iOS now. Time to construct a client or server app for the iPhone! :)

[jbenet]

This is really great!! thanks @seclorum -- i want to take a closer look but dont have time atm. will try to spend time next week checking it out. would be awesome to have some demo app too! :)

also if you want the repo to be part of the ipfs org happy to setup a dedicated org team for iOS and hand you the reins.

[seclorum]

Its mostly just a build environment at the moment, which does little more than demonstrate that ipfs can be built and linked-to with XCode, but I plan on making a GUI for the whole set of *-cmds this week, so I'll keep you up to date on progress. The goal is to get ipfs running as a functional tool on iOS, so if you think this would be valuable work to contribute to the ipfs effort, I'm quite happy to have a place in the official ipfs repo to put this work ..

[jbenet]

@seclorum

• any progress on this? Ipfs should be much better now, and go mobile should make this process way easier
• want to move it over to ipfs/ ?
• we can write an altered DHT to be merely a client
• we can get the resource limits (mem, net, disk) into 0.5.0

[whyrusleeping]

The link to his repo changed: https://github.com/seclorum/ios-go-ipfs

[seclorum]

@whyrusleeping thanks for correcting the link to the repo.

@jbenet no progress on this since i left it in the last state - primarily because this was just prior to go mobile being made available/released, and also because i wanted to pause while ipfs made further progress. Now that go mobile is up and running and seems pretty smooth, I'll come back to this project and improve things.

If you like I'll have another go at it this week and see if I can get a working ipfs backend.. It is my goal to participate in the effort to get ipfs running on iOS as a first-class player, so anything I can do to help - or questions/answers, please let me know. I'm very eager to continue ..

Re: moving to ipfs/ - yes we can do that, it should in my opinion just be part of mainline ipfs. But let me get it working first. ;)

Re: Resource limits/DHT client - yes, we should probably address this as an optimization/tweaking step once things are building and runnable .. will keep an eye on this as I do the go mobile port of ipfs and tear out all my other dodgy hacks for building it in iOS ..

[daviddias]

This looks really great! @neoteo might be interested on this as he was building a native Swift implementation of IPFS

[NeoTeo]

Interesting indeed. I wrote the IPFS API client in Swift and have used it to write an iOS app that communicates with an IPFS node, but had only gotten to the stage of investigating the feasibility/usefulness of writing a native Swift implementation of IPFS. With Go actually running on iOS it seems this effort would be slightly wasted?

[whyrusleeping]

@NeoTeo having a native swift implementation would probably allow you to take advantage of a lot of the neat system features you get on iOS. I doubt that would be an easy feat cross-compiling go to the system. An easy 'middle step' might be to build the go daemon for the iPhone, and then use a swift api to communicate with it

[NeoTeo]

The 'middle-step' idea might be an interesting test. That would give all(?) the platform advantages without having to rely on an external daemon. At the very least it would make it clearer what advantages we would get from a full Swift libp2p/IPFS implementation.

[whyrusleeping]

I think that would be a super awesome thing to work on, even if it kills the battery life (sorry, i havent gotten to tweaking those things yet) it would provide a really great proof of concept

[jbenet]

Fully agreed! I want "ipfstagram" On Sat, Jan 2, 2016 at 08:12 Jeromy Johnson notifications@github.com wrote:

I think that would be a super awesome thing to work on, even if it kills the battery life (sorry, i havent gotten to tweaking those things yet) it would provide a really great proof of concept

— Reply to this email directly or view it on GitHub https://github.com/ipfs/go-ipfs/issues/1126#issuecomment-168389620.

[NeoTeo]

I'm probably going to press ahead, when I can carve out some time, with some kind of ipfstagram that works with an external but local (or alternatively any explicitly given ip) and then changing it to work with an x-compiled local node should be trivial.

[johndpope]

Thanks to anyone who has worked on these frameworks for others to consume. It may take more time for people to fully appreciate this master piece. but awesome job. Thank you. I finally have a use case where I think this will really shine. I want to design some sample code to allow a single device to seed to offline peers on a local wifi network with a large file. database that's been downloaded from the internet. Can't wait. This is going to be cool. Offline twitter would be another good use case that I always crave going through the subway.

[johndpope]

I think we collectively need to ipfs to jump on the cocopods bandwagon.

[NeoTeo]

As it turns out I have yet to press ahead (or any other direction) with this, partly because the x-compiled go-daemon for iOS hasn't happened, but mostly because of paid work "interfering". There has also been (still ongoing?) a great refactoring of IPFS -> libp2p as well as an API and ABI breaking transition of Swift from 2 -> 3 both of which would be nice to have settled before embarking on a native implementation. Still keen though.

[johndpope]

fyi - http://p2pkit.io/ these look more polished for publishing / maybe able to cherry pick some of the samples.

https://github.com/ls1intum/sReto

https://twitter.com/p2pkitio https://youtu.be/_tL371MUNDg

[jbenet]

yeah we should have support for p2pkit in libp2p.

note that the scope of libp2p is different and broader in other ways (including dhts, etc)

[NeoTeo]

@johndpope Note that my iOS example project that shows a simple use of the swift-ipfs api lib also finds nearby IPFS nodes using mdns and could trivially be expanded to list all nearby nodes.

[codynhat]

Hey there. I am new to IPFS and libp2p and I’m trying to learn more about how iOS devices could be used as nodes.

I’ve stumbled upon the MultipeerConnectivity framework that is available on iOS, macOS, and tvOS.

https://developer.apple.com/documentation/multipeerconnectivity

Could this potentially be used one day to implement libp2p on these platforms? It seems to be a layer higher, since it doesn’t expose any transport or discovery protocols. Or would this really be used in lieu of libp2p?

[NeoTeo]

As far as I can see multipeer connectivity doesn't provide anything we don't already have through mdns discovery. The issue is mainly finding the resources to do a native port libp2p to Swift/iOS. I think a good starting place would be a generic libp2p porting guide (eg. where to start, tests along the way, etc.) for anyone interested in implementing a version on their preferred platform.

[adamski]

@NeoTeo does https://github.com/Agorise/c-libp2p not fit that bill? Being written in C pretty much makes it compatible with every platform, and also allows it to be wrapped in any language that supports a C ABI.

[NeoTeo]

Possibly. I am personally not interested in developing a version that wraps a C lib, but others might be.

[kjaylee]

Also try, my repo. https://github.com/kjaylee/ios-ipfs-api (swift ipfs http api wrapper)

[johndpope]

@kjaylee - well done.