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

[2021 Theme Proposal] IPFS ❤️ Starlink #72

Closed
RubenKelevra opened this issue Nov 27, 2020 · 11 comments
Closed

[2021 Theme Proposal] IPFS ❤️ Starlink #72

RubenKelevra opened this issue Nov 27, 2020 · 11 comments

Comments

@RubenKelevra
Copy link

Note, this is part of the 2021 IPFS project planning process - feel free to add other potential 2021 themes for the IPFS project by opening a new issue or discuss this proposed theme in the comments, especially other example workstreams that could fit under this theme for 2021. Please also review others’ proposed themes and leave feedback here!

Theme description

Starlink from SpaceX is a new way to access the Internet everywhere on this planet, by pointing automatically tracking satellite antenna into the sky. Allowing for affordable, fast, low-latency internet on the go, in the wilderness, in the arctic circle, and in developing countries. IPFS nodes on the satellites and the ground stations could offer users fast access to cached content while reducing the overall bandwidth needs for SpaceX to the ground stations and the internet.

Hypothesis

The satellite would run an IPFS node. Requests by the end-user node would be proxied through the satellite, allowing the satellite node to fetch and cache the content and keep it in it's memory for other users to request.

The satellite nodes would connect to the other satellites and the ground stations, requesting the content from the 'cheapest' location possible. This would require a cost estimation per connection, like how much bandwidth is currently already used on the link.

This way the satellite could fetch content either from its ground station, when the bandwidth use is low or via different transmitters from other satellites, when the interconnection links are not too busy, dynamically.

As a fallback, the satellite node would try to fetch it from the internet for the end-user.

Vision statement

This technology can also be used in any other network where multiple internet connections with limited bandwidth are available. And bring IPFS to more end-users and expand the versatility of the network.

Why focus this year

SpaceX's Starlink just started a closed beta but is expanded rapidly in size and is soon to be expected to launch publicly.

Example workstreams

  • Contact the SpaceX-Starlink team to see how we can work together
  • Plan the limitations/available resources on the satellites for node hardware
  • Plan and Implement non-equal node-to-node relations to make proxied requests possible from the end-users through the SpaceX-Nodes
  • Plan and Implement link-cost-aware connections between nodes, to allow to weight the cost to fetch CIDs when multiple connections offer it
  • Plan and Implement a way to trust a changing list of nodes, to avoid MITM-attacks

Other content

I've mentioned some of the content of this ticket before in a note: ipfs/notes#432

@RubenKelevra RubenKelevra changed the title [2021 Theme Proposal] IPFS ♥️ Starlink [2021 Theme Proposal] IPFS ❤️ Starlink Nov 27, 2020
@rklaehn
Copy link

rklaehn commented Dec 1, 2020

I like this idea.

I am pretty sure that SpaceX has some kind of CDN on the satellites already, possibly content-addressed. They are pretty powerful compared to traditional satellites. They are using modern, non radiation hardened CPUs in a byzantine fault tolerant configuration.

The question would be if the current ipfs is efficient enough to be of benefit to spacex.

But possibly, if IPFS has sufficient mind share, you could convince them to do an IPFS adapter for their existing CDN. Especially if this saves bandwidth. You could also run ipfs nodes on the gateways.

@rklaehn
Copy link

rklaehn commented Dec 1, 2020

Not going to start a new issue for this, but a general theme of using IPFS in space might also be a good idea. Starlink would of course be the largest deployment. But there are other companies that are planning to do basically micro data centers in space.

E.g. https://orbitsedge.com/ . They have a technology to operate normal data center servers in the space environment. Last I checked with them, they want to offer Kubernetes as a means of deployment on these servers.

So one slightly less ambitious goal could be to have IPFS nodes in space one way or another. This would also require focusing on operating ipfs nodes in an extremely high latency environment or completely offline.

@bertrandfalguiere
Copy link

@autonome mentioned libre.space project to embed IPFS, too. ipfs/notes#432 (comment)

@jacobheun
Copy link
Contributor

Not going to start a new issue for this, but a general theme of using IPFS in space might also be a good idea. Starlink would of course be the largest deployment.

I think it does make sense for this to be more general. One of the longer term goals of IPFS is to run on Mars, https:/ipfs/roadmap#-interplanetary-web---mars-2024-d3-e3-i4, and there are a lot of dependencies here that we can benefit from in the shorter term; high latency tolerance, bandwidth efficient, intermittent/low connectivity.

@ipfs ipfs deleted a comment from welcome bot Dec 1, 2020
@GeorgeTsagk
Copy link

GeorgeTsagk commented Dec 2, 2020

@rklaehn

Not going to start a new issue for this, but a general theme of using IPFS in space might also be a good idea

@bertrandfalguiere

@autonome mentioned libre.space project to embed IPFS, too. ipfs/notes#432 (comment)

In Libre Space Foundation, we are trying to create a prototype IPFS library (called IPFS-tiny) that is lightweight and OS independent. Within our main scope is the support for many target systems, which enables embedding the library on satellites as well. We also introduce a "bridge" component to help networks consisting of such systems to integrate with current IPFS.

Coming back to the main topic here: if you consider in-orbit satellites running IPFS-tiny, and ground stations around the world (like SatNOGS stations for example) to be the bridges, you can create a layer of satellites which are frequently communicating with each other as much as with earth. As a result, you have created a file system consisting of satellites in orbit, which is also accessible by ground stations, who in turn integrate with IPFS.

Then for example it would be possible for you to ipfs get a picture of earth taken seconds ago!

I am not stating that our current programme includes research and investigation of such topologies, but IPFS-tiny will surely bootstrap many new opportunities in space applications.

@RubenKelevra
Copy link
Author

Cool discussion. I think that some content providers, like Netflix, could be interested to rent parts of the cache of the satellites, to accelerate the streaming. It would for example make sense to hold the first 1% of each movie in the database on the satellites to allow a faster burst-like push to overcome the delay of buffering. While the rest of the movie is fetched via a ground-station.

@RubenKelevra
Copy link
Author

My probabilistic tiering proposal fits in this starlink idea, where the satellites would 'route' data from the nearest and least crowded connection.

It would just need to be extended to send different tiering values to clients via different network interfaces / ips.

#80

@RubenKelevra
Copy link
Author

@GeorgeTsagk I worked on a RFC which describes ways to make IPFS proxy node possible.

That on three different levels: Local, ISP level and global with spacial awareness.

I'll fix my text up a bit and will link it here :)

@BigLep
Copy link
Contributor

BigLep commented Jul 19, 2023

I'll fix my text up a bit and will link it here :)

@RubenKelevra: not expected, but just curious if you have this doc available to share?

@RubenKelevra
Copy link
Author

Hey @BigLep,

this ended up as a roadmap entry here as well:

#89

@github-actions
Copy link

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 Sep 25, 2023
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Oct 1, 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

8 participants