The Libre Space Foundation (LSF) has been working on developing IPFS-tiny. A project aimed to bring the InterPlanetary File System (IPFS) to…other planets and Space.
The development of IPFS-tiny is funded by Protocol Labs.
IPFS-tiny is built in C++, and it is operating and file system agnostic. It is designed to work well on embedded systems and resource-limited devices, such as satellites and spacecraft.
IPFS in a nutshell
IPFS is “designed to preserve and grow humanity’s knowledge by making the web upgradeable, resilient, and more open.” This is a vision that we at LSF can identify with, especially when it comes to enhancing knowledge and supporting openness for the interests of all humanity.
The way IPFS goes about achieving that is by using a distributed architecture.
Contrary to traditional file systems that store data in a centralised location, the IPFS distributed network stores and accesses data peer-to-peer. The data is stored across multiple nodes in the network, and this allows for faster and more efficient access to files. As well as increased security and resiliency. Even though some nodes in the network may be unavailable, the data can still be accessed.
This approach bears many benefits. Because files live across the network, this enables the downloading of a file from multiple locations, and thus, it enhances decentralisation. Especially since these files are not managed by one organisation alone. This way, IPFS can be used in decentralised web applications, content distribution, and data archiving. It allows the versioning and caching of data, as well as the creation of permanent web links, and it can potentially transform how we think about and access data online.
IPFS: A closer look
IPFS and Content Addressing
Content addressing plays an integral part in IPFS. This is because files are not identified by their location but by what they comprise. In other words, they are identified by their content. The files added to IPFS are split into smaller chunks, cryptographically hashed, and given a unique fingerprint called a content identifier or CID. This CID acts as a permanent record of the file, as the specific file exists at that exact point in time.
When the time comes for other nodes to lookup for that file, they ask their peer nodes which one is storing the content referenced by the file’s CID. When they view or download the file, they cache a copy of it. This way, they become another provider of the content until their cache is cleared. When the original file is modified, its cryptographic hash becomes different, and it gets a new CID. This means that any file stored on IPFS can neither get tampered with nor censored. Any potential changes made to a file do not overwrite the original content. What is more, common chunks across files are reusable and, thus, help cut down on storage costs.
Thus, each CID request results in the correct file being delivered securely and efficiently and protecting against any malicious actors attempting to manipulate the system. The safety of this approach is facilitated by IPLD.
What is IPLD?
IPLD originally began as a part of IPFS, but over time, it has matured and developed to become a project on its own. InterPlanetary Linked Data (IPLD) addresses content through hashes as a unified information space where the data is presented as a graph that can verify itself. The graphs are known as Merkle DAGs or Merkle Directed Acyclic Graphs (DAGs).
In Merkle DAGs, the data structure is illustrated as trees bearing nodes where each node has an Identifier. The nodes are self-descriptive, and every other sub-section of the file can describe itself as well. This provides a multitude of significant information, such as the type of file they are, the type of information they store, and their size too. Every time a tiny bit of information is changed, the graph realises that, and it updates itself with a new, precise self-description. Leading, thus, to compatibility backwards as well as forwards as the graphs are self-verifiable. In other words, the same rules and same graph construction will always have the same CID.
IPLD plays an integral part in IPFS. Its role expands, though and becomes even more significant when IPFS-tiny gets into the picture too.
IPFS-tiny
IPFS and IPFS-tiny: Distinguishing between the two
As we have mentioned, IPFS-tiny is a project developed by LSF attempting to bring IPFS to space and other planets. In essence, IPFS-tiny is a smaller version of IPFS, designed to work well on devices with limited resources.
These devices, including micro and nanosatellites, can have limitations in their processing capabilities, as they often rely on microcontroller units (MCUs) for their main processing needs. They also face storage restrictions with flash storage that may result in wear-off issues. All these challenges restrict the use of IPFS with micro and nanosatellites. And this is why the need for IPFS-tiny has arisen.
This clearly points out that IPFS-tiny is different from IPFS. To connect IPFS-tiny to the main IPFS network, a bridge is required to allow for data to be shared between the two. This is where IPLD is helpful, making it possible for IPFS and IPFS-tiny to interact and work together safely and efficiently.
IPFS-tiny and Space!
By utilising the interoperability of IPLD, we can use IPFS-tiny to bring IPFS (and its benefits) to space. This can be achieved by using SatNOGS, a project run and maintained by LSF. SatNOGS is the largest open-source network of satellite ground stations, with more than 400 stations spread in 54 countries across the globe. Let us take a closer look at some scenarios on how this network can be utilised.
Scenario 1: The SatNOGS Network of ground stations can serve as a bridge, allowing satellites to transmit information blocks using IPFS-tiny. However, if one ground station attempts to alter the data, it will be unsuccessful. As the IPLD ensures that even small changes result in a unique file, it is difficult for malicious actors to manipulate the system.
Scenario 2: The network of ground stations could be further enhanced by incorporating additional satellites, creating a cross-satellite system where information could be shared and made readily available. This expands on Scenario 1 by including additional satellite participants in the network, increasing the overall accessibility and distribution of data.
Scenario 3: Another option would be to expand the network of satellites even further by incorporating IPFS into the setup. This would turn the satellites into dedicated storage units for the IPFS network, making it a true InterPlanetary File System with a space-based layer.
Potential Use cases
Micro and nanosatellites generating much data are increasingly used in missions for various applications. A stable operational state of the space segment must be guaranteed for the missions to be able to complete their goals successfully. Since these micro and nanosatellites operate in Low Earth Orbit (LEO), their communication window with the ground stations is highly limited. In this case, using IPFS could significantly benefit these LEO operations by enabling them to exchange data with IPFS-enabled ground stations as the satellites pass over them. As channel resources are essential, IPFS could significantly assist towards that by uploading or downloading only what is necessary or only those parts of a file that have changed.
This approach helps overcome challenges and reliably transmit information, and share and access data easily and efficiently. Turning the network into a Delay Tolerant Network that is designed in such a way as to operate effectively under extreme conditions, large distances, and challenging circumstances. As is often the case with space communications.
IPFS-tiny: Key implementation features
Let us now take a closer look at some of the key implementation features of IPFS-tiny:
- Nanopb for Protobuf support. Nanopb encodes and decodes messages following the format of Protobuf, Google’s Protocol Buffers. This format comes with minimal requirements for RAM and code space as well as statically allocated memory, and it is, thus, suitable for use in microcontrollers.
- ETLCPP/ETL. The ETL is an embedded template library that improves the features of the Standard Template Library (STL). The latter is not suitable for limited resource requirements. This is why in IPFS-tiny, STL-like C++ containers are used, with a static memory model that is a great fit for lower-resource embedded applications. Allowing, thus, for improved performance in limited-resource devices.
- libcppunit-dev for testing and the CMake build system, which is open-source and versatile enough to support different open-source platforms for software development.
All the key implementation features are designed to be compatible with microcontrollers and ensure efficient, reliable, and accurate performance.
IPFS-tiny supported features
IPFS-tiny supports various features, including Multiformats, CID v0 and v1 support, IPLD dag-pb, and an expandable IPLD implementation. This has the ability to easily implement new coding schemes and support basic IPFS operations such as add(), del(), and get().
Next Steps
IPFS-tiny is a project that is under development, and finalising the implementation of the project is the goal. Once it is completed, it will be tested in orbit. It could fly in space onboard a future QUBIK mission, with SIDLOC and on the SatNOGS-COMMS. Another part of this implementation would have to be to connect IPFS-tiny to IPFS with a bridge through the SatNOGS Network and consider the CCSDS File Delivery Protocol as part of this implementation.
Are we InterPlanetary yet?
The way IPFS is designed supports a vision for data sharing that overcomes boundaries and limitations, enabling a safer and more resilient internet. IPFS-tiny is a more simplified version of IPFS developed to fit the requirements of actual InterPlanetary data sharing. Adapted to the challenging conditions of satellite communications and space, IPFS-tiny is a tool under development that, when completed, will take IPFS to space, making it truly InterPlanetary. Stay tuned…
Leave a Reply