Romanshorn

The road (and ferry) to a data space future

Georg C. F. Greve
7 min readJul 6, 2023

Travel is a great source of inspiration and learning. Especially when travelling to the Eclipse Software Defined Vehicle Community Day.

Isn’t it ironic?

My car decided to teach me a lesson how urgent and important all the work done in Eclipse is just as I was driving to the Eclipse Software Defined Vehicle (SDV) Community Day where I was going to discuss the Eclipse Cross Federation Services (XFSC) data space components, and especially their Self Sovereign Identity (SSI) stack. Also, how impotent Google can be. But let me start at the beginning.

As a technologist, I always aim to experience the “normal user experience” as much as possible. I want to know what people are getting when they use today’s services. Also, I like to go beyond dog-fooding, the common practice of using one’s own products and services, because I’m concerned about too myopic a perspective.

So right now I am driving a Volvo, with their latest software, which is based on Google everything. My car has a Google identity, it uses Google maps, and Google speech input. I’m experiencing the full surveillance package and loss of privacy that comes with that. But I was curious about the potential benefits. What do you really get in return?

The speech input is a constant nuisance. My boys have done their best to test its limits and capabilities. And basically, it is really bland and corporate washed, with horrible results when you are dealing with places that have names in non English languages. Which tends to happen a lot when you travel in Switzerland, Italy, Germany and Austria, the four countries we spend most of our time in. Even when it does not try to send us to drive to India instead of that trattoria in the next village, which has happened more than once, it’s very hit and miss. So we mostly no longer use it. And for the love of everything you hold dear, do not ask it to tell jokes. The jokes it tells make the lamest dad jokes seem spicy in comparison.

Even 12 year olds are rolling their eyes at how devoid of humor and life the jokes are.

But today it is all about navigation. Driving from Zurich to Friedrichshafen is usually a less than two hours affair, and everything went well until I approached the Bodensee. Google decided that I could save 20 minutes on the trip by going via the ferry in Romanshorn.

It did not need to convince me very hard. Romanshorn is special to me ever since I spent weeks during the summer there with a wild bunch of awesome ice hockey kids and fantastic group of coaches as an assistant junior coach for the SC Rapperswil-Jona Lakers. We had such a great time, and the ice hockey rink is right next to the ferry.

Nostalgia met “Google knows everything”, so to Romanshorn I went.

Only to discover — again — that Google is much less intelligent than one would think. The ferry did not leave for another hour. Which is a schedule that upon research turned out to be well known and constant, and meant my 20 minute gain due to traffic conditions turned out to be a 60 minute delay due to ferry schedules.

So Google Maps obviously does not take schedules into account when ferries are involved. Good to know for the future. But it’s really quite the let down. I mean, I could Google the ferry schedule without a problem. It even has the special treatment for public transport improved display.

Google knows it’s a ferry — and its schedule

In a sovereign world of data spaces, the schedule of the ferry would be available with verification from the transport provider, including real-time information about potential disruptions or delays. The car would pull that information and integrate it into its route planning, along with other relevant information, e.g. possible charging stations for electric cars, and aggregate all that information into a vehicle specific information picture that is used to suggest informed decisions to the user.

All that information would remain local to the vehicle itself, maintaining full privacy and control of personal data of the driver while gaining all the benefits of a networked world.

The car could even automatically negotiate pricing and payment for transport with the ferry operator, potentially including surge / lull pricing to optimize utilization and get more customers into its on-board bistro. Drive on, enjoy the ride with a coffee and croissant, and drive off.

We could do all of this, today. But there are substantial obstacles to overcome, including those rooted in properties of the platform economy. Many of which boil down to people having caught on to the most important lesson:

In the platform economy, the platform provider always wins.

Imagine the ferry operator were willing to invest time and effort into connecting itself into a data ecosystem. In the current example, they would need to convince Google to work with them. They need Google’s permission to be able to make Google Maps take their schedule into account.

The ferry still has some capacity

Assuming that Google is willing to cooperate, it is now in control of when people get re-routed to the ferry. Which may happen always, or never. For automatic accounting, it is also in a position to insert itself into the payment chain, taking a cut, and gaining access to payment information. All of which stops working the moment Google decides it is not in their own best interest to continue delivering them.

But what about cars that do not use Google software? Will they enjoy better or worse service? Will they be able to use this service, at all? Or will the ferry operator now need to invest time and effort into individual agreements and integrations with each of them?

This is the eternal condundrum of trying to build data ecosystems, which are by definition many sided markets. Platforms always raise concerns of central control, permission, and lasting commitment. They are a hard dependency and natural choke point for all participants who will have needed to invest at the beginning to become part of the ecosystem.

The ride across the lake sure was beautiful

So how should this work?

Data ecosystems must be understood as public utilities, much like the internet itself.

Which is why they must be open, permissionless, and built on software freedom & open standards. It should be possible to create new data spaces without asking for permission, and multiple data spaces should be capable of interconnecting and negotiating exchange based on the merits of the data in question— without a private enterprise acting as choke point.

Eclipse is one of the most important organizations at the forefront of making this happen. A truly European Open Source association, it drives essential activities like the Software Defined Vehicle where the industry is working together on projects like in-vehicle digital twins, or visualization of vehicle sensor data, including external cameras or other sensors.

I like to think of this as “The stuff that makes futuristic Tesla self-driving cars possible, but fully Open Source” — and without the sociopath in control.

But that is not all. Eclipse also is home to the Eclipse Dataspace Components, which are used by many of the current data space lighthouses, including Catena-X, the automotive supply chain, and Marispace-X, which is about marine dataspaces including information such as location of munitions, or offshore wind farms.

The Cross Federation Services Components (XFSC) are the latest addition and they contain a complete tool box for federating data spaces, helping them to connect, broker and exchange information between domain specific data spaces.

So, in the future, cars running on top of Eclipse SDV will connect to their vehicle specific data spaces run using Eclipse Dataspace Components, connecting via Eclipse XFSC to get information from the North Sea wind farms to charge when there is a surplus of wind and electricity is currently available at a discount.

This will only work if the different systems and organizations can agree on a common approach for identity and authentication that is independent from any patform, as well as secure, trustworthy for all participants, and privacy preserving. Identity is what ties all of this together.

Which is why I found myself on the road to Friedrichshafen. Because identity use cases that are open, decentralized, privacy preserving and decentralized are what our team at Vereign is working on. We built the components for Verifiable Credential management and Self Sovereign Identity for organizations as part of the XFSC stack together in addition to the mobile identity wallet.

So no, I don’t think it is ironic. It is very motivating. Because I am truly motivated to throw out the invasive presence of Google in my own car. My goal is to finally be in control of my own data without losing all the comforts of a modern, data driven world. I am really looking forward to the future we’re working towards.

Meanwhile, the delay wasn’t all bad. I got to enjoy a truly scenic trip including landing zeppelins.

Zeppelin over Friedrichshafen
P.S. Guess how I ended up going back ;-)

--

--

Georg C. F. Greve

Chairman and Head of Product @VereignAG. Founding president FSFE. Software developer, physicist, author. Loves self-sovereign, open technologies and ice hockey.