WEBVTT 00:00.000 --> 00:12.120 So, I'm Kelly, I'm a fellow at the European decentralization institute, which is an independent 00:12.120 --> 00:15.280 think tank for the decentralized economy. 00:15.280 --> 00:20.080 And this talk is about a layer of digital infrastructure that rarely appears in European 00:20.080 --> 00:22.280 digital policy. 00:22.280 --> 00:28.520 I know that sovereignty, digital sovereignty, is a hot topic today and for a good reason, 00:28.520 --> 00:34.280 that's a good thing, but especially on the EU level, the focus usually stays on things 00:34.280 --> 00:42.400 like cloud, AI, semiconductors, big US tech platforms and software, because these are the 00:42.400 --> 00:46.400 things that institutions already know how to deal with, right? 00:46.400 --> 00:52.200 They fit into existing legal categories and they map clearly onto procurement frameworks. 00:52.200 --> 00:57.760 But what tends to be invisible is the protocol layer that runs beneath everything. 00:57.760 --> 01:02.760 And yet this is the layer that determines how systems communicate, how they remain 01:02.760 --> 01:06.600 inoperative and how they evolve over time. 01:06.600 --> 01:11.320 It's the coordination infrastructure that makes everything else function. 01:11.320 --> 01:16.760 Public institutions increasingly depend on open protocols, sometimes at very large scale, 01:16.760 --> 01:22.200 which we'll see in a minute, while the governance of these protocols remains largely absent 01:22.200 --> 01:25.880 from strategy, procurement and long-term planning. 01:25.880 --> 01:30.880 The dependencies already exist, but the understanding of protocol governance, how the 01:30.880 --> 01:33.640 protocol evolves, often does not. 01:33.640 --> 01:36.880 And this talk is about exactly that blind spot. 01:36.880 --> 01:41.080 But before I continue, let me be very explicit what I will not argue for. 01:41.080 --> 01:45.160 I'm not here, of course, to advocate for regulating protocols. 01:45.160 --> 01:51.080 I'm not here, even, to argue that governments should enter protocol governance in all cases. 01:51.080 --> 01:54.680 The goal is much more basic and much more necessary. 01:54.680 --> 02:00.040 It is to make the protocol layer legible, so that institutions and technical communities 02:00.040 --> 02:05.920 share an understanding of what it means to be dependent on the systems over time. 02:05.920 --> 02:12.080 So I think it's helpful to first start with how European digital policy tends to look at 02:12.080 --> 02:13.440 technology. 02:13.440 --> 02:18.760 First, of course, there is the infrastructure, the chip, status, and the networks, cloud 02:18.760 --> 02:24.640 regions, the underlying hardware and functions that can be owned geographically located 02:24.640 --> 02:25.640 and audited. 02:25.640 --> 02:31.640 Second, of course, something we're very familiar with in Brussels, regulation, the legal 02:31.640 --> 02:38.640 instruments that govern digital infrastructure and services, and most of the aforementioned 02:38.640 --> 02:44.640 infrastructure items they are already regulated through data protection rules, the AI Act, 02:44.640 --> 02:48.640 platform obligations, cybersecurity frameworks, and so on. 02:48.640 --> 02:53.640 And of course, the institutions, the formal authorities, the agencies, funding programs, 02:53.640 --> 02:59.640 and governance bodies, with budget mandates and formal authority to implement policy. 02:59.640 --> 03:05.360 Now, open protocols, by contrast, are, of course, they're borderless, they're non-onable, 03:05.360 --> 03:08.840 and they're maintained by loose global communities. 03:08.840 --> 03:15.400 They determine how systems inoperative it, inoperate, but they do so without ownership, without 03:15.400 --> 03:19.160 jurisdiction, and without institutional control. 03:19.160 --> 03:23.520 And that's a good thing, of course, but as a result, they sit outside the field of 03:23.520 --> 03:26.400 vision of most policy frameworks. 03:26.400 --> 03:31.840 In practice, this means that protocols are often treated as technical background conditions, 03:31.840 --> 03:37.680 something that is almost assumed to be stable, neutral, and external to governance. 03:37.680 --> 03:42.160 That assumption, of course, as most of you here will know, is wrong. 03:42.160 --> 03:43.760 Protocols are not static. 03:43.760 --> 03:49.920 They are continuously modified through governance processes, proposal mechanism, consensus 03:50.000 --> 03:55.840 norms, backwards compatibility decisions, and informal power that accrues over time. 03:55.840 --> 04:00.960 These processes determine what the protocol allows, what it forbids, and what kinds of 04:00.960 --> 04:04.720 behavior are allowed to build on top of it. 04:04.720 --> 04:07.320 In other words, protocols make rules. 04:07.320 --> 04:12.880 They just do so without being recognized as rule-making systems by law or policy. 04:12.880 --> 04:15.880 And this creates a structural blind spots. 04:15.880 --> 04:22.440 Digital policy already routinely produces dependencies on open protocols, but without 04:22.440 --> 04:27.480 identifying them explicitly, without funding the work that keeps them scalable, without 04:27.480 --> 04:34.480 assessing how their evolution might react with regulatory goals. 04:34.480 --> 04:40.720 And I think the distinction becomes even more obvious when you look at the procurement processes. 04:40.720 --> 04:46.000 Now, when an institution adopts the software, it, of course, does so through a contract. 04:46.000 --> 04:50.760 There is a vendor, a liability regime, a defined update path. 04:50.760 --> 04:53.600 Governance is externalized. 04:53.600 --> 04:58.720 On the contrast, when an institution adopts an open protocol, even though they might not 04:58.720 --> 05:01.720 be fully aware of it, none of that exists. 05:01.720 --> 05:09.720 The institution enters an existing coordination system whose evolution is shaped by participation, 05:09.720 --> 05:10.720 not authority. 05:10.720 --> 05:18.720 There is no counterparty to contract with and no mechanism to align change with public objectives. 05:18.720 --> 05:25.320 Protocol governance is simply how those coordination systems change over time, who can 05:25.320 --> 05:32.760 propose changes, how do proposals gain adoption, and what constraints a well-funded actor 05:32.760 --> 05:39.280 from steering the system when there's no formal video, no regulator, or no enforceable obligation. 05:39.280 --> 05:43.200 From within the protocol communities, this is all super obvious, right? 05:43.200 --> 05:48.280 But from a legal and policy perspective, it is not what is visible is the repository, 05:48.280 --> 05:50.560 the documentation, and so on. 05:50.560 --> 05:56.160 What is not visible is decision thresholds, the power dynamics, and the coordination costs 05:56.160 --> 05:59.080 that shape future behavior. 05:59.080 --> 06:04.880 That opacity makes it quite difficult for institutions to assess in what ways they are dependent 06:04.880 --> 06:06.760 on open protocols. 06:06.840 --> 06:12.840 Institutions are not only relying on how a protocol behaves today, but also how it might 06:12.840 --> 06:15.120 change in the future. 06:15.120 --> 06:20.880 And it is really a big mismatch with existing policy and procurement frameworks, because 06:20.880 --> 06:27.040 policy tools and procurement frameworks usually assume at least one of three things. 06:27.040 --> 06:33.560 First, a regulatory move, subject a contractual counterparty or an accountable entity, but 06:33.640 --> 06:38.920 Ethereum has no central governance body, matrix has no vendor relationship. 06:38.920 --> 06:43.560 They have moved through distributed coordination proposals, discussions, and voluntary 06:43.560 --> 06:44.840 adoption. 06:44.840 --> 06:50.280 None of the usual levers apply, and that makes it very complicated for policy makers. 06:50.280 --> 06:55.960 But I would argue that in network systems, sovereignty does not come from formal ownership 06:55.960 --> 06:57.880 or formal control. 06:57.880 --> 07:03.720 It comes from understanding how rule changes occur, who participates in them, and where 07:03.720 --> 07:06.240 influence actually sits. 07:06.240 --> 07:09.960 Open protocols already structure behavior at scale. 07:09.960 --> 07:14.240 Policy simply doesn't see that yet, and this, I would argue, is a massive gap that we 07:14.240 --> 07:16.520 should address. 07:16.520 --> 07:18.320 But what exactly is the issue here? 07:18.320 --> 07:23.520 Why does it matter that protocol governance is a blind spot in digital policy? 07:23.560 --> 07:27.360 The problem is, of course, not that open protocols lack governance, most of them are 07:27.360 --> 07:31.160 governed carefully and completely. 07:31.160 --> 07:36.200 The problem is that digital policy increasingly, whether they're aware not to create dependencies 07:36.200 --> 07:39.760 on protocols without accounting for their governance. 07:39.760 --> 07:45.920 Through standard references, interoperability mandates, and funding programs, and long-term 07:45.920 --> 07:51.480 compliance requirements, policy choices, already determined which protocols institutions 07:51.520 --> 07:52.480 come to rely on. 07:52.480 --> 07:58.040 But the governance of these protocols remain largely outside institutional awareness, 07:58.040 --> 08:00.760 though there are, of course, some examples. 08:00.760 --> 08:05.080 When governance is invisible, dependencies do not disappear. 08:05.080 --> 08:10.640 They simply move downstream into procurement decisions, operational risk, and incident 08:10.640 --> 08:12.240 responses. 08:12.240 --> 08:17.120 When their institutions are left managing the consequences, they did not anticipate and cannot 08:17.200 --> 08:22.000 easily influence, and this creates three structural risks. 08:22.000 --> 08:28.200 First of all, interoperability becomes fragile, thought about the deployments assume long-term 08:28.200 --> 08:31.960 capability, but of course, protocols evolve. 08:31.960 --> 08:35.680 Specifications change, methods get depreciated. 08:35.680 --> 08:41.320 The decisions make today can surface later as breakage, and are far away from the original 08:41.320 --> 08:42.320 discussion. 08:42.560 --> 08:46.560 There is no contract enforcing compatibility. 08:46.560 --> 08:52.160 Governments are users of the protocol, not parties to its governments, usually. 08:52.160 --> 08:57.360 Unlike traditional interoperability mandates, which assume bilateral or multilateral 08:57.360 --> 09:00.240 agreements between accountable parties. 09:00.240 --> 09:06.120 So when a breaking change happens, and an institution relies on open protocols, they have 09:06.120 --> 09:08.080 to absorb the risk. 09:08.520 --> 09:14.120 Seconds, and I think this is an important one, exit options become costly. 09:14.120 --> 09:19.320 When protocol evolution diverges from institutional constraints, the options become very 09:19.320 --> 09:25.200 narrow, because working a protocol at the deployed at scale is very expensive. 09:25.200 --> 09:29.000 It's operationally risky, and politically difficult. 09:29.000 --> 09:35.400 You inherit the full main in spurdon, and slowly lose alignment with the wider ecosystem, 09:35.440 --> 09:38.800 which gives you network benefits. 09:38.800 --> 09:43.840 Abandoning the protocol also often means falling back to vendor-centric alternatives, 09:43.840 --> 09:50.400 recreating the very dependencies that sovereignty strategies are meant to avoid. 09:50.400 --> 09:54.360 There's no one to negotiate with when you are adopting an open protocol. 09:54.360 --> 09:56.960 Governance is distributed by design. 09:56.960 --> 10:02.080 You either participate in shaping it, or you accept what the community decides. 10:02.080 --> 10:07.040 And finally, change arrives at an operational surprise. 10:07.040 --> 10:13.400 So yeah, when a protocol changes through open coordination, if institutions do not track 10:13.400 --> 10:20.080 these processes, governance decisions, surface-as-urgent incidents, instead of predictable 10:20.080 --> 10:22.480 lifecycle maintenance work. 10:22.480 --> 10:27.240 So security fixes, specification protocols, protocol upgrades. 10:27.280 --> 10:30.200 Of course, these are not failures of a protocol. 10:30.200 --> 10:36.800 They are completely normal, but usually there is no institutional capacity to track these. 10:36.800 --> 10:38.720 So what does that look like in practice? 10:38.720 --> 10:45.360 I want to use matrix protocol as an example, because matrix is already used for governance 10:45.360 --> 10:48.920 communications at a very large scale. 10:48.920 --> 10:56.240 France teach-up serves hundreds of thousands of civil servants on a daily basis. 10:56.240 --> 11:02.840 And in Germany, you have PMV messenger, which serves over a hundred thousand users, and is 11:02.840 --> 11:06.840 used in the Bundeswehr and parts of public administration. 11:06.840 --> 11:12.920 And TI messenger, the German healthcare sector, is a user, and over a hundred and fifty 11:12.920 --> 11:17.760 thousand healthcare organizations, large and small reliance. 11:17.760 --> 11:20.320 So these deployments stay work very well, right? 11:20.320 --> 11:21.320 They scale. 11:21.320 --> 11:25.720 An adoption of the matrix protocol is increasing, accelerating. 11:25.720 --> 11:31.640 I know Sweden, the Netherlands, and the European Commission, they all have matrix deployments 11:31.640 --> 11:33.440 in process. 11:33.440 --> 11:40.920 And this is mainly driven by the EU's push for digital security, but also new interoperability 11:40.920 --> 11:42.960 mandates. 11:42.960 --> 11:47.720 But here is where the dependency looks like operationally. 11:47.720 --> 11:54.040 In matrix addresses a security vulnerability through a coordinated release, server operators 11:54.040 --> 12:00.240 must decide whether they to upgrade immediately or run a version with a known issue. 12:00.240 --> 12:03.240 Of course, the decision is not made in a vacuum. 12:03.240 --> 12:08.760 The timing scope and mitigation are shaped upstream through matrix governance, through the 12:08.760 --> 12:15.880 MCSC sorry discussions, embargo coordination and release planning. 12:15.880 --> 12:20.440 But if your institution is not tracking these, you do not learn about them when decisions 12:20.440 --> 12:21.760 are being debated. 12:21.760 --> 12:25.120 You learn when the security advisory becomes public. 12:25.120 --> 12:28.560 And at that point, the choice is no longer strategic. 12:28.560 --> 12:29.560 It's reactive. 12:29.560 --> 12:35.160 You have to respond almost immediately, and you have to choose between operational risk 12:35.160 --> 12:37.800 or compatibility risk. 12:37.800 --> 12:42.120 The same dynamic applies, of course, to room version upgrades. 12:42.120 --> 12:48.640 matrix has introduced multiple room versions to improve security and federation behavior. 12:48.640 --> 12:54.720 If a critical coordination room upgrades and your deployment will not update clients, 12:54.720 --> 12:56.720 users can lose access. 12:56.720 --> 13:03.320 And decisions about when a room version are introduced, backwards compatibility is handled, 13:03.320 --> 13:09.320 and what migration pad exists are all made through the official governance process of matrix. 13:09.320 --> 13:11.920 So it's very important to track this. 13:11.920 --> 13:19.280 And this is not something hypothetical, because since France has adopted matrix, for example, 13:19.280 --> 13:26.200 there was the authenticated media that was rolled out across the matrix network in 2024, and 13:26.200 --> 13:28.880 every client and bridge had to adapt. 13:28.880 --> 13:34.800 So governance decisions in the protocol directly translated into operational work for 13:34.800 --> 13:37.400 institutional deployments. 13:37.960 --> 13:39.200 Now, here's the fragility. 13:39.200 --> 13:46.760 These deployments, they succeed because a small number of individuals understood the protocol 13:46.760 --> 13:50.120 governance and the institutional deployments. 13:50.120 --> 13:55.800 So people inside DINAM, for example, in France, in engineers at GMATIC in Germany. 13:55.800 --> 14:00.160 These people are very capable of following the governance. 14:00.160 --> 14:06.160 And I think in the case of matrix, since October, they have actually, in the case of T-CAP, 14:06.200 --> 14:11.760 they have actually joined the matrix foundation in October, so quite recently. 14:11.760 --> 14:16.240 So matrix is, France is doing quite well there. 14:16.240 --> 14:19.760 But the knowledge is highly concentrated in a few people. 14:19.760 --> 14:21.880 Does not scale automatically. 14:21.880 --> 14:27.680 And when those individuals move on, there is a risk that the institutional understanding disappears 14:27.680 --> 14:28.720 with them. 14:28.720 --> 14:35.200 So I think Europe does definitely not lack the technical capacity to rely on open protocols. 14:35.240 --> 14:41.520 But they do lack a systematic institutional capacity, and that is a risk. 14:41.520 --> 14:48.240 So they need the capacity to monitor governance process processes and security advisories. 14:48.240 --> 14:54.880 The capacity to plan upgrades as part of regular life cycle management, not as an incident 14:54.880 --> 14:56.160 response. 14:56.160 --> 15:03.120 And the capacity to understand how specification changes affect operational continuity before 15:03.200 --> 15:06.800 they become breakage or big failures. 15:06.800 --> 15:12.320 Without that capacity, institutions depend on protocol governance that they do not track, 15:12.320 --> 15:16.560 and discover the consequences only when it's almost too late. 15:16.560 --> 15:19.040 And of course matrix is not an exception here. 15:19.040 --> 15:24.720 This goes for any open protocol used in life deployments that scale by institutions 15:24.720 --> 15:29.520 from identity to messaging, from payments to data exchange, right? 15:29.520 --> 15:34.560 They can all create the same dependence on protocol governance indirectly. 15:34.560 --> 15:39.520 Once institutions adopt something that uses that open protocol at scale. 15:39.520 --> 15:41.280 Now there is some very good news. 15:41.280 --> 15:45.360 There is an opportunity to address the challenges I just mentioned. 15:45.360 --> 15:52.400 As we speak, the European Commission is preparing its open source digital ecosystems strategy. 15:52.400 --> 15:57.840 In fact, the public consultation is closing this Tuesday. 15:57.840 --> 16:01.520 So if you want to get your comments in, there's still some time. 16:01.520 --> 16:06.480 And the ambition of the European Commission is very well placed. 16:06.480 --> 16:10.880 It is to support the full open source life cycle, right? 16:10.880 --> 16:18.400 From deployment to market update, mainly across cloud AI and digital commons. 16:18.400 --> 16:22.640 And the European Commission also has directly identified 16:22.640 --> 16:27.120 that a significant share of value created by European open source 16:27.200 --> 16:28.880 flows outside Europe. 16:28.880 --> 16:31.360 Of course, this is an important diagnosis. 16:31.360 --> 16:36.160 And I'm sure the Commission will look at all the public consultation inputs. 16:36.160 --> 16:42.000 But I, in my view, it remains incomplete unless the strategy also addresses what happens once 16:42.000 --> 16:45.200 open technologies are deployed at scale. 16:45.200 --> 16:51.520 If the open digital ecosystem strategy only focuses on supply site measures. 16:51.520 --> 16:56.160 For example, funding projects encouraging adoption and building markets. 16:56.240 --> 17:01.840 It will continue to underestimate a central source of digital dependency. 17:01.840 --> 17:10.720 Many public deployments rely on protocols whose evolution Europe does not yet track resource or plan for. 17:10.720 --> 17:16.720 And to address this gap, I argue that there should be four pillars in this new strategy. 17:17.520 --> 17:22.320 First, require protocol governance assessment in public procurement. 17:22.400 --> 17:28.080 Second, recognize protocol stewardship as a critical to digital infrastructure. 17:28.080 --> 17:31.760 And of course, funding accordingly and sustainably. 17:32.400 --> 17:38.480 Third, build institutional capacity to track and plan for protocol evolution and 17:38.480 --> 17:44.240 force a line for procurement incentives with upstream contribution. 17:44.240 --> 17:46.080 Now go through them quickly. 17:46.800 --> 17:54.240 So as I said, first, the strategy should require protocol governance assessment in public procurement. 17:54.240 --> 17:57.920 And I think this is one of the biggest blind spots we have right now. 17:57.920 --> 18:05.040 Because today, institutions routinely make strategic procurement decisions based on the 18:05.040 --> 18:10.640 assumption that protocols are technically stable, but in reality, of course, they are not. 18:11.360 --> 18:18.320 And this is a huge issue because public tenders specify the use of open protocol sometimes. 18:18.960 --> 18:26.240 But they do not include the needs to assess the protocol itself only the supplier. 18:26.960 --> 18:33.840 So I think when you look at public procurement, it should include an understanding of where 18:33.840 --> 18:40.560 protocol decisions are made, how changes proposed and adopted and how backwards compatibility 18:40.640 --> 18:43.920 is managed and how breaking changes can surface. 18:44.640 --> 18:50.080 The objective is not to influence governance outcomes of course, but to make protocol risk visible. 18:50.720 --> 18:56.720 Second, the strategy should recognize protocols towards ship as digital infrastructure and fundates. 18:56.720 --> 19:03.280 Because of course, protocols require often invisible work maintaining specifications, 19:03.280 --> 19:05.680 reviewing proposed changes and so on. 19:05.680 --> 19:12.160 But this work is rarely funded through market mechanisms and is systematically missed by project-based funding. 19:12.720 --> 19:17.920 And when it is under resource fragility becomes, yeah, accumulates. 19:18.320 --> 19:22.480 I think here the great example is the German sovereign tech funds, 19:22.480 --> 19:26.960 which demonstrates that it's problem can be addressed without exercising control. 19:27.520 --> 19:34.720 Since 2020, it's invested more than 23 million in over 60 open source components. 19:34.800 --> 19:41.440 And I think the open digital ecosystem strategy should apply this logic as at European level. 19:43.120 --> 19:50.160 Third, the strategy should build institutional capacity to track and plan for protocol evolution. 19:50.560 --> 19:55.680 Public agencies need practical literacy and how protocol changes happens, 19:55.680 --> 20:00.400 knowing where the discussion stake place, which forums and repositories carry authority, 20:00.400 --> 20:07.440 how timelines are set, etc. Without this capacity, institutions will remain only reactive 20:07.440 --> 20:11.120 and repeatedly surprise by upstream governance decisions. 20:11.120 --> 20:16.640 And I think this is already quite visible and at risk in regulated deployments. 20:16.640 --> 20:23.920 For example, under the EID does two member states are required to roll out digital identity. 20:23.920 --> 20:31.440 wallets at population scale by late 2026. And these wallets depend on internationally developed 20:31.440 --> 20:36.320 identity and credential specifications that continue to evolve. 20:36.320 --> 20:42.640 And if European wallets implementations do not actively track and plan for this evolution, 20:42.640 --> 20:48.160 cross-border interoperability might feel because member states will be implementing different 20:48.240 --> 20:54.240 assumptions based on the same underlying standards. And finally, the strategies should 20:54.240 --> 20:58.480 align procurement incentives with upstream contribution. 20:59.600 --> 21:06.640 For now, public procurement rewards systems integrators who resell or deploy protocol-based 21:06.640 --> 21:12.080 systems, while the maintainers usually do not benefit from this procurement value. 21:12.960 --> 21:18.720 This is risky because vendors that actively contribute to protocol specifications. 21:18.720 --> 21:24.320 And so, on their far better position to anticipate change and fix issues quickly, 21:24.880 --> 21:30.640 while keeping deployments aligned with upstream evolution. The strategy should therefore support 21:30.640 --> 21:37.520 procurement models that recognize contribution as a sort of resilience signal. 21:37.520 --> 21:43.680 And I think proposals from initiatives such as euro stack are already points in this direction 21:43.680 --> 21:48.080 to make contribution and explicit procurement criterion points. 21:48.960 --> 21:54.480 This is not only just about a ideological preference for open source, but also about 21:55.760 --> 22:00.080 sound risk management. And taken together, this would really help 22:00.560 --> 22:06.000 taking the strategy from a real framework to supporting open protocols. 22:06.560 --> 22:12.320 So, of course, the first responsibility lies with institutions to track an account for 22:12.320 --> 22:17.040 protocol governance. But then there is a natural question. Is there anything that 22:17.040 --> 22:22.800 protocol communities can do to help the dependencies easier to understand? 22:23.440 --> 22:28.240 Not to change how government works, of course, but to reduce misunderstanding. 22:28.320 --> 22:32.080 Now, I know some of you are thinking, you know, ready documents your governance. 22:32.960 --> 22:37.280 Why is it my problem that institutions don't know how open source works? 22:37.280 --> 22:43.360 And I think it's a fair question, but it matters because when institutions don't 22:43.360 --> 22:50.400 understand your governance and something breaks, they tend to not absorb the risk quietly. 22:50.400 --> 22:53.440 They write regulations. And they could, uh, 22:53.440 --> 22:58.640 really, and change your even the developers of the open protocol we've seen that before. 22:59.280 --> 23:05.920 So, matrix documented governance very early and clearly. So, when governments like France 23:05.920 --> 23:11.360 and Germany adopted it at scale, it helped them understand what they were depending on. 23:11.360 --> 23:16.240 So, here are some practical tips you could do. Make sure that government's 23:16.240 --> 23:20.640 documentation is easy to understand because usually it's written for 23:20.720 --> 23:27.200 contributors, of course, and not for dependence. If the ministry official asks, 23:27.200 --> 23:31.680 how does the protocol decision make, how does the protocol make decisions? Is there 23:31.680 --> 23:37.440 one's documents or a repository that is very clear that you could point them to or do the kind 23:37.440 --> 23:43.760 of have to reverse engineer everything? If you're inclined to formalize something like this, 23:43.760 --> 23:50.400 you should think about covering decision venues, propose a life cycle, participation norms, 23:50.880 --> 23:56.160 safeguards, and upgrade expectations. For example, it could be just even a single 23:56.160 --> 24:01.760 realm written page that could provide significant defensive value. I think you can look here at 24:01.760 --> 24:09.840 a posh Linux foundation product foundation project and matrix as a good example. And seconds 24:09.840 --> 24:15.840 be clear about the on-ramps for participation without, of course, promising influence. So, 24:15.840 --> 24:21.680 means being explicit about which calls are open and relevant, what participation looks like 24:21.680 --> 24:25.920 without disturbing governance. And importantly, and this is something that 24:25.920 --> 24:32.960 protocol communities are often not explicit about, what does participation not confirm? So, 24:32.960 --> 24:40.400 being very explicit that participation does not mean the ability to influence or guarantee 24:40.400 --> 24:45.840 response to feedback. But when governance is legible to institutions, 24:45.840 --> 24:51.760 institutions make better procurement decisions, unrealistic expectations are avoided, 24:51.760 --> 24:58.400 and communities are also less likely to be pulled into very bad regulatory or legal dynamics. 24:59.680 --> 25:05.680 So, it allows institutions to depend on you responsibly without you having to constantly explain 25:05.680 --> 25:14.640 or mediates. So, finally, in conclusion, protocols already underpin many of Europe's digital 25:14.640 --> 25:21.360 infrastructure. Digital sovereignty does not mean controlling open protocols, but it means 25:21.360 --> 25:26.960 accounting for their governance, through stewardship, through clarity, and through institutional 25:26.960 --> 25:33.520 literacy. For policy makers and institutional adopters, this means naming protocol dependencies, 25:33.920 --> 25:39.120 planning for their evolution, and funding the work that keeps them reliable over time. 25:39.120 --> 25:46.080 For developers, it means making your stewardship legible not to invite control, but to prevent 25:46.080 --> 25:52.080 misunderstanding and backlash. And I think if we can get this right, then Europe does not need to 25:52.080 --> 25:57.280 choose between sovereignty and openness. Because, of course, I think many in this room here 25:58.240 --> 26:05.520 will say that sovereignty depends on open technologies, but if we can strengthen the 26:06.320 --> 26:11.680 institutional understanding of the protocol layer, that can strengthen the layer where the 26:11.680 --> 26:16.080 sovereignty actually begins. Thank you. 26:20.400 --> 26:26.160 We have time for one short question. So, we can have one short question, and then we have to go 26:26.160 --> 26:30.160 on to the next talk. So, just go ahead and then please repeat the question. Can you speak 26:30.160 --> 26:32.160 loudly or do you need microphone? 26:44.160 --> 26:46.160 Can you repeat the question? 26:56.160 --> 27:05.840 I was referring mainly to open source protocols. I'm sorry if that wasn't clear, but of course, 27:05.840 --> 27:12.080 I think the problems usually do not occur at the technical level where institutions participate 27:12.080 --> 27:20.880 in standardization meetings, but higher up when the commissioner for digital decides 27:20.880 --> 27:28.320 something she also needs some basic awareness of what her decisions might imply, and so I think 27:28.320 --> 27:33.360 yeah, it's more like at the higher political level that these things are not well understood.