Skip to content
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

[2020 Theme Proposal] IPFS Mobile - The Future is in Our Hands #45

Closed
autonome opened this issue Nov 8, 2019 · 6 comments
Closed

[2020 Theme Proposal] IPFS Mobile - The Future is in Our Hands #45

autonome opened this issue Nov 8, 2019 · 6 comments

Comments

@autonome
Copy link
Contributor

autonome commented Nov 8, 2019

Note, this is part of the 2020 Theme Proposals Process - feel free to create additional/alternate proposals, or discuss this one in the comments!

Theme description

Please describe the theme and what it means for the IPFS Project.

The focus of development of IPFS to date has been primarily on desktop and server class hardware. However, the growth of the internet for more than a decade has been entirely in mobile.

This growth at the furthest edge of the network requires solutions at that edge. As long as the IPFS network remains inaccessable on mobile devices, the value of the network where it matters most is not realized - IPFS will remain stoppable, and its offline use-cases constrained by application development patterns of the centralized ecosystem.

A focus on IPFS embedded in mobile applications would be through the development of a reference implementation which serves both as our testground for core work and also a vehicle for end-user product experimentation.

The shift in IPFS core team priorities to mobile as the highest priority use-case will eventually happen, and the sooner that reorientation happens, the sooner end-users will get the true benefits of the technology.

Core needs & gaps

Please describe in more detail what needs or gaps in our current state this theme addresses, and how it will create value for the IPFS ecosystem.

Resource constraints are a harsh teacher. Google, Microsoft, Apple and Mozilla have all learned this lesson in different product initiatives over the years. All made hard decisions that ultimately were based on the same conclusion: Shooting to operate best where conditions are worst will pay dividends for a decade.

A laser focus on IPFS on mobile will have positive secondary effects on our 2019 target audience while setting the stage for the next billions.

Additionally, the IPFS project does not have a vehicle for end-user features that we fully control. We are restricted by our deployment channels, none of which allow us to easily demonstrate the power of our technology. With a mobile reference application we can showcase how IPFS meets end-user needs in a product-forkable way.

Why focus this year

Please provide rhetoric for why this theme deserves focus in 2020 in particular.

A project-wide focus on mobile infrastructure is a strategy designed to leapfrog our current development trajectory. The focus on package managers in 2019 showed us that narrow focus on particular needs can identify specific shortcomings of IPFS. A narrow focus on a particular environment like mobile provides an even less forgiving set of requirements for IPFS node operation, demanding a level of focus and execution unavailable by picking a vertical focus.

Additionally, in 2019 our collaboration partners set the stage by proving the concept:

  • Textile innovated with mobile application patterns that revealed the possibility for reduced power consumption.
  • Berty pushed forward in phyisical proximity p2p computing with their Bluetooth transport for libp2p.

With those early learnings, we can develop these collaborations and partnerships into core functionality in 2020.

Milestones & rough roadmap

Please list relevant development milestones and the high-level timeline for these efforts.

Core Engineering Milestones

  • go mobile becomes P0 reference testing platform for go-ipfs
  • Mobile platform tooling such as React Native become P0 reference testing platform for js-ipfs
  • Power consumption tests in CI for all platforms
  • Bandwidth consumption test in CI for all platforms

Product Engineering Milestones

  • Reference application for iOS launched
  • Reference application for Android launched
  • Reference web app launched as a PWA using web-rtc for connectivity
  • Collaborations launches mobile partner showcase

Desired / expected impact

How will we measure success? What will working on this problem statement unlock for future years?

Core implementation impacts

  • Memory use radically reduced
  • Robustness and reliability in adversarial network conditions as the new status quo
  • Power consumption reduces drastically
  • Bandwidth awareness guides architectural decision making
  • IPFS is now ready for further embedding, as ubiquitous computing expands, into IoT, wearables and ambient computing devices.

Ecosystem impacts

  • Developer adoption increases through the direct availability of IPFS in tooling and product deployment channels
  • Application patterns develop which create new mobile market dynamics
  • IPFS becomes the default choice for developers for reliable and secure networked mobile applications with built-in protection from exposure to user data
@momack2
Copy link
Contributor

momack2 commented Nov 8, 2019

Thanks for suggesting this theme! A few questions to help parse your recommendations:

A laser focus on IPFS on mobile will have positive secondary effects on our 2019 target audience while setting the stage for the next billions.

Can you explain how mobile as a focus area bridges between the work we took on to enable package managers in 2019 and larger scale adoption? What latent needs or communities are we missing by not refocusing all our efforts here, and what are the potential costs of switching focus to this platform?

We are restricted by our deployment channels, none of which allow us to easily demonstrate the power of our technology. With a mobile reference application we can showcase how IPFS meets end-user needs in a product-forkable way.

Can you expand on this? What restrictions are we experiencing with web / desktop? What do you mean by this “product-forkability” of mobile apps with ipfs?

@autonome
Copy link
Contributor Author

Can you explain how mobile as a focus area bridges between the work we took on to enable package managers in 2019 and larger scale adoption?
What latent needs or communities are we missing by not refocusing all our efforts here, and what are the potential costs of switching focus to this platform?

I'm not suggesting a bridge between package managers and mobile themes - we get different benefits. Package manager focus has side effects that enable desktop/server use-cases. Table-stakes operation of IPFS in mobile device environments unlocks much larger market opportunities if only due to size of consumer addressable market.

Video is a good example of a place where IPFS on mobile might shine, given the right target performance profile. We've already know video is #1 use-case by current users of IPFS. Targeting video over IPFS on mobile opens up possibility of that same outsized usage but in massively larger addressable market.

What restrictions are we experiencing with web / desktop?

Our consumer channels in desktop web browsers are severely constrained, hampered by paradigmatic resistance to even the most basic networking APIs in the browser. At its best, our end-user install topology is a Rube Goldberg machine: IPFS Desktop + IPFS Companion + a browser is mostly broken: Major browsers are actively fighting against the APIs we need... and that's just in extensions, let alone native support or operation in regular web content.

We have some small but mighty allies in browser world, and will continue to move those efforts forward. However, prioritizing mobile as the P0 target in our core implementations leapfrogs that effort in order reach the market where the global internet consumer permanently resides, while simultaneously achieving performance side-effects that help desktop use-cases anyway.

What do you mean by this “product-forkability” of mobile apps with ipfs?

We can design our reference mobile application(s) that we implement in and test against as a forkable application base for rapid product development.

Mozilla's Android Components project is doing this for mobile browsers by having their Reference Browser application be 1) the testing target for their components, 2) the base for multiple Android browser products and 3) an easily forkable open source base for anyone to build products on top of.

@mikeal
Copy link

mikeal commented Nov 14, 2019

Video is a good example of a place where IPFS on mobile might shine, given the right target performance profile. We've already know video is #1 use-case by current users of IPFS. Targeting video over IPFS on mobile opens up possibility of that same outsized usage but in massively larger addressable market.

Are these users serving video directly to clients via IPFS or is IPFS a storage backend to a middle tier that does the actual video streaming?

I think the distinction here is important if you’re talking about mobile, because if the protocol between these two endpoints is not IPFS then it would actually lean more towards “IPFS for service providers” rather than “IPFS for mobile.”

That said, WebTorrent has a very good streaming video story and is in fairly wide use even with many limitations IPFS does not have, so if we’re expanding the scope of users under consideration to other p2p technology consumers that would be another point for video, and in the case of WebTorrent it’s WebTorrent the whole way through, there isn’t a middle tier unless you count trackers ;)

@autonome
Copy link
Contributor Author

Are these users serving video directly to clients via IPFS or is IPFS a storage backend to a middle tier that does the actual video streaming?

I think the distinction here is important if you’re talking about mobile, because if the protocol between these two endpoints is not IPFS then it would actually lean more towards “IPFS for service providers” rather than “IPFS for mobile.”

DTube appears to be using IPFS directly. Seems like the benefits at scale are lost (or at least unreaped) if IPFS isn't used out to the edge.

That said, WebTorrent has a very good streaming video story and is in fairly wide use even with many limitations IPFS does not have, so if we’re expanding the scope of users under consideration to other p2p technology consumers that would be another point for video, and in the case of WebTorrent it’s WebTorrent the whole way through, there isn’t a middle tier unless you count trackers ;)

Definitely WebTorrent proved out ground as well for the video use-case.

@Gozala
Copy link

Gozala commented Dec 16, 2019

I’d like to add few things here that aren’t captured in original proposal:

  • Not only mobile is less constrained (or rather constrained in different ways) platform to target than web it also offers some unique capabilities specific to the medium like Apple’s Multipeer connectivity framework and Google’s Nearby Android framework for letting nearby devices communicate. I think those provide unique opportunities to enable applications in environment where today they would simply not work. Additionally those frameworks do not necessarily fit existing IPFS networking model, which suggests it’s would be a great idea to consider how this unique constraints affect current design.

  • Unlike computers that are mostly well connected to internet, mobile devices often face spotty networks on subways, large concerts, off the grid etc .... where centralized systems fail. This creates a unique opportunity for distributed networks to use it unfair advantage and demonstrate it’s value.

  • There is an increasing signals showing that AirDrop is growing in popularity among teens this days which suggests there is an opportunity in edge to edge space that could be filled.

@github-actions
Copy link

github-actions bot commented Oct 5, 2023

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

@github-actions github-actions bot added the Stale label Oct 5, 2023
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Oct 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants