Thanks for the details about torrada, I'll check it out!
Seems that for peer apps on mobile, we need to make it easy for the user to understand their bandwidth-usage - indeed in my testing I never run the app where I don't have solid, unlimited Wifi. For these classes of apps, I think the presentation of this problem to the user is going to be important.
>ipfs port
Its more of a harness than a port - basically, its possible to use Go on iOS, and so I have a project set up to include Go, cross the bridge between Obj-C and Go runtimes, and so on .. and, then I've built a Go app with ipfs, running on iOS. There aren't any features yet - but the harness is done, so, TODO: write Go, use ipfs framework, interface with iOS-GUI normatives, etc.
When I get actual ipfs functionality coded, I'll put it up on a repo .. too much futzing around is required right now to see anything actually functioning.
Ah, I had a look at goios, I can imagine that it is a lot of work, the integration looks quite complicated and far from being finished, good luck.
About sharing bandwidth, was thinking about only enabling when the user is on wifi, but I think I'll use torrent more as a distributed mirror network than a "real" P2P system, which is difficult in a mobile context. People can easily "donate" bandwidth by seeding the data files needed for the app (using a separate torrent client though, not the app itself).
Actually, I got everything working, and can build and include an ipfs project in the iOS bundle .. I just don't have a UI to wire it up to the Go-side functionality. But in case you're interested you can have a look here:
Might have to change a few paths in the build-script, but it'll give you an idea (if you're interested) how to go about building Go apps on iOS. Turns out its not that hard! :)
>Sharing bandwidth
Yes, I see the same sort of conclusion from my perspective of wanting to put ipfs on iOS - its really only as a way of committing content to the mesh when the User wants to serve - i.e. idle times connected/charging on local Wifi .. I think my next step will be to wire up the camera and a few fields to be used to create a publishable set of content ..
Seems that for peer apps on mobile, we need to make it easy for the user to understand their bandwidth-usage - indeed in my testing I never run the app where I don't have solid, unlimited Wifi. For these classes of apps, I think the presentation of this problem to the user is going to be important.
>ipfs port
Its more of a harness than a port - basically, its possible to use Go on iOS, and so I have a project set up to include Go, cross the bridge between Obj-C and Go runtimes, and so on .. and, then I've built a Go app with ipfs, running on iOS. There aren't any features yet - but the harness is done, so, TODO: write Go, use ipfs framework, interface with iOS-GUI normatives, etc.
When I get actual ipfs functionality coded, I'll put it up on a repo .. too much futzing around is required right now to see anything actually functioning.