ResNetLab was invited to meet with the Decentralised Internet Infrastructure Research Group (DINRG) of the Internet Research Task Force (IRTF) to present and discuss the Software Architecture of the IPFS protocol.
There were a total of 4 talks at the meeting. Ours was titled “High-Level Overview of the IPFS Architecture”. The presentation covered what happens when importing, naming, finding, and fetching content on IPFS, and was followed by some great questions from the 29 participants that attended in real time. You can watch the full recording and check the slide deck.
New to DINRG? The Decentralized Internet Infrastructure Group (DINRG) is part of the Internet Research Task Force (IRTF), which is part of the Internet Engineering Task Force (IETF) - the main standardisation body for Internet protocols. The IRTF is its research arm, and its task is to “promote research of importance to the evolution of Internet protocols”. While the IETF focuses on short-term engineering, the IRTF looks at longer-term issues relating to Internet protocols, architecture and applications. IRTF groups often proceed to become standards groups in the IETF.
Within the IRTF, the DINRG is investigating issues related to the decentralisation of core Internet infrastructure and related protocols. As such, the DINRG group’s vision is very aligned with many of our projects at Protocol Labs. Apart from distributed-ledger and issues related to blockchains, the DINRG is interested in general-purpose protocols that can contribute to the decentralisation of Internet services and architectures.
The DINRG meets at least three times a year as part of the main IETF meetings. For this edition, the meeting was held remotely as the world readjusts to the disruption caused by the COVID-19 pandemic. We appreciate the support and hard work that went into preparing this event - it was great to discuss new ideas and solicit feedback on our work from this group.
Questions that came up during the talk
We got a few great questions during the talk that we wanted to write down for others to find. Enjoy!
Q: How well does Kademlia work with Disconnected applications?
A: Kademlia (and IPFS) can work without problems in disconnected LAN scenarios. In this case, the local DHT is not part of the mainnet DHT and vice versa (i.e. content stored in one cannot be found from the other). There is significant interest within the IPFS ecosystem in supporting fully offline communication: companies such as Berty are working towards Bluetooth-based transports for libp2p to enable local, offline device interactions. Communication in these types of environments will likely not use the DHT as the content routing infrastructure, due to the high levels of node mobility and small network scale, which the DHT is not optimised to handle.
Q: In a non-local network, with occasional connectivity, how can you differentiate failure from longer disconnection periods?
A: You don’t necessarily need to differentiate between the two. What is important is for the network to know what content is available and where. In IPFS, provider records are the main mechanism by which providers let the network know of content they store/cache. Provider records have to be refreshed, i.e. sent periodically to the DHT to keep up-to-date information. You could still provide content locally, even when a node is disconnected from the DHT (e.g. via Bluetooth). Such mechanisms would be built as separate transports within libp2p.
Q: How do you manage the ID space in an offline case?
A: In LAN-based disconnected scenarios, where the DHT is not connected to the main, public DHT, the Peer ID space can be managed the same way as in the online/connected case, where each node on the network is represented as a leaf of a binary tree. According to Kademlia, the position of a node on the tree is determined by the shortest unique prefix of its ID. PeerIDs in the libp2p KAD-DHT use 256-bit keys, as opposed to 160-bit keys as suggested in the original Kademlia paper.
Q: Are real-time, interactive applications supported by IPFS?
A: Absolutely! IPFS provides a messaging layer (through libp2p PubSub) and a name system (IPNS) that enables applications to support update broadcasts and mutable pointers. There are several distributed and real-time applications using IPFS today; some highlights are PeerPad (a real-time, P2P collaborative editor that does not use or depend on any central server), Orbit.chat (a real-time chat platform), OpenBazaar (a P2P e-commerce market), Filecoin, the Distributed Storage Market), and in the near future, ETH2.0. If you want to know more, we recommend the following talks and demos:
- Introduction to libp2p (the network layer that supports these interactions)
- Tutorial on how to use libp2p PubSub (build an app in less than 10 minutes)
- Enter Gossipsub (the scalable message layer of libp2p)
- The libp2p PubSub interface spec
Thank you to everyone that attended the talk and to the DINRG for organizing this event and inviting us. We look forward to future editions! If you’re interested in working on large scale P2P Research Problems, check our RFPs and Open Positions.
