Jens Finkhäuser - Interpeer
Secure and efficient peer-to-peer networking stack
Middleware and identity
Can you introduce yourself and your project?
My name is Jens Finkhäuser, and I started the Interpeer Project in 2019. I was a peer-to-peer engineer at a video startup called Joost, which used Skype’s p2p technology to power streaming platforms. Sadly, it no longer exists, though we can claim to have paved the way for the video streaming you have today.
In 2018/2019, I worked with a company that tried to do comparable things ten years later, and I realised how much knowledge was lost since then. But that partnership did not work out, so I applied for an NGI grant to produce much the same thing as FLOSS. Since then, my focus has shifted from merely distributing data streams over peer-to-peer networks toward broader questions:
- How do we want the Internet to work in the future?
- What are our individual needs that are not addressed well today?
The Interpeer Project, as I see it today, is both a technological exploration of what is possible when you do not choose the default web stack, a human rights exploration of how you can use Internet technology more safely, and finally, a philosophical exploration of what benefits the Internet brings and should bring
What are the key issues you see with the state of the internet today?
The Internet has many issues, plenty of which are worked on by people better suited to that task. However, most people are focused on making incremental improvements to the state of the art. Today, the state of the art is in using web technology.
One of the critical issues I’ve identified in talks I’ve given over the years is that the web is fundamentally centralised in some sense and grants too much power to its centralised components. Take this interview as an example, which we’re conducting over email:
- You wrote your questions in some email client.
- The client then sends the email to an email server under your control.
- This server then forwards the email to my email server.
- I fetch the email from there with my email client.
Email is relatively decentralised in that you and I are free to choose our email servers, and they will find each other and forward emails between them. Not so on the web. If I create an account on one platform and you create an account on another platform, we won’t be able to collaborate or communicate between these accounts.
The platform becomes a centralised component, permitting or disallowing our human-to-human interactions. It can censor what we do, extract payment simply to see each other’s contact information, and so forth. The web is incredibly centralised
Email is a technology that is designed to work on relatively sparse metadata. At the same time, the data it transports is opaque to the servers (in theory, in practice, it is rather thoroughly scanned). If you and I were to run programs that emailed each other to collaborate, we could do so without having to adapt or ask permission from email servers.
This is not the case on the web. The web is designed to be extensible only by extending the server with additional functionality. Then, for clients to adapt to this, we need them to be able to run the arbitrary code that the server sends. Thus, all exchanges we try to conduct between us, the people on the web, are arbitrated by whoever runs the server we choose.
I paint an incomplete picture here. Tech is always flexible. People have used web technology to build the Fediverse (you may have heard of Mastodon), which works much more like email. It just uses the web as a transport medium of sorts. But this is folk deliberately picking a path through the weeds instead of following the well-paved road. As much as I applaud what has been done and is being done in that space, I can’t help but notice that the easy way is not the human-centric way. For people to do people stuff, we have to pick a path through the weeds. Surely we can do better than that?
How does your project contribute to correcting some of those issues?
I suppose the main contribution is that we have analysed the web technology stack and alternative architectures, such as information-centric networking and delay-tolerant networking, regarding their respective strengths and weaknesses in supporting human interaction use cases. From that, we’ve derived an alternative, human-centric architecture. Our work now is to implement this.
The web’s strength is that it centres interactions on resources, which have characteristics to model the interaction. URLs represent resources on the web. You write to or read from the resource and receive updates from other participants or send yours to them. Where the web fails is that it ties this resource to a specific server, as outlined before, which then needs to run very specific code.
This turns human-to-human interaction into human-to-server-to-human interaction, placing a third party in the middle of everything. This model of expressing interest in a topic by reading from a resource and participating in writing to it is good in capturing most use cases we see (a more publish/subscribe style of interaction captures even more).
We can keep this abstract model and find a basis that doesn’t require a man in the middle. This is necessarily a kind of group communication mechanism because our computers need to start talking directly to each other without a central instance to redistribute changes to other interested parties. But on top of that layer, you also need to find a way for all the parties chattering with each other to reach some kind of consensus on the current state.
Luckily, recent research into conflict-free, replicated data types has allowed for this. We have made several components of such a system so far, but there are still more to build. Then, they have to be tested together, which will likely reveal some issues we haven’t seen so far.
What do you like most about (working on) your project?
I have a love/hate relationship with the fact that so many things about this are research, not things we can just build because we know they will work. We think they will work because other people have made them work similarly, but nobody seems to have put together the same set of considerations yet. It’s exciting because it’s new! But it’s also a lot of work with uncertain outcomes, which can be daunting.
It’s sometimes easier to talk about what I don’t like about it. One is that because we’re re-assembling a bunch of reasonably understood things, a common reaction is to compare something we do to some other project. I get that reaction. I do the same thing myself, and I think it’s a human trait to try to understand stuff by comparing it to things you already know! But often, the things we build are subtly different, in a way that has a negligible effect when used as the other project uses it but behaves significantly differently when used how we use it.
So, to explain subtle choices in a sub-component, you need to impart an understanding of all other parts. I think I found the best high-level explanation I could give last year when I was on stage with the Tor project discussing our approaches. For the record, I think the Tor project is fantastic!
However, the interviewer caught on to something and presented Interpeer as a project that would make Tor obsolete. I explained then that the Tor project is like seat belts. Nobody in their right mind would debate the merit of seat belts—they’ve saved so many lives! Making seat belts mandatory in cars is a sensible idea (in hindsight: as a kid, they were not yet ubiquitous).
At the same time, we don’t use seat belts in trains. Each train transports orders of magnitude more people than a car does, and they often go way faster as well. Why do we deem trains less in need of seat belts than cars? It’s probably something to do with trains running on rails. Rail usage is tightly controlled by a team of people, ensuring no conflicting schedules, etc. Trains are part of a system that is inherently designed to be safer and to better transport large numbers of people.What I like about working on the Interpeer Project is that, in the end, I am doing something new enough that it’s difficult to explain concisely, but that should make the Internet better for us in the same way that trains are safer than cars. That’s not only the future I want, but I get to build it, too!
Where will you take your project next?
As I wrote a little above, there are still plenty more individual components to build, and then we need to ensure they interact as well as we’re currently thinking. I have plans for what I can do with the project after this is done, but for now, this is more than enough.
Practically speaking, the following steps are getting a more stable funding basis going. I started this in 2019 and incorporated the public interest entity “Interpeer gUG” in 2022. This now fills a weird niche in that it’s both an SME and a research institute, which means, in principle, I can use it to join consortia for Horizon Research & Innovation or similar grants. That gives me more funding security to hire people permanently (so far, my collaborators were contractors) and scale the work better. It’s “boring” administrative work, but it’s necessary to get us where we need to go. It enables the exciting stuff, so it has to be done!
If you were to give one piece of advice to other technologists who want to work on improving the Internet, what would it be?
The human brain is built to cut corners. In tech, that’s not different: we tend to focus on incremental improvements to the state of the art because that’s much easier and arguably a much better-understood thing than trying to question whether our starting point is good. Just like our brain fills in blind spots in our vision, if your goal is to improve the internet, you must be aware of when you’re doing that.
One of the talks I gave a while back is called “The Constraints of Innovation.” It discusses how many incremental changes that led us to today’s web were local optima but not globally optimal. So my advice is this: “Just because something is in place and it works, doesn’t mean it is the best starting point for improvements. Sometimes, it is worth going back to the drawing board.”
Acknowledgements
Image: courtesy of Jens Finkhäuser.
Published on October 22, 2024
Interpeer received funding through the NGI Assure Fund, a fund established by NLnet with financial support from the European Commission's Next Generation Internet programme, under the aegis of DG Communications Networks, Content and Technology under grant agreement No 957073.
