A persistent source of confusion and misalignment in the Blockchain space stems from a conflation between specification documents and standards. The tendency to think of the EIP process as a complete standards process or, worse, to think of EIP editors and CatHerders as a decentralized “standards development organization” (SDO) does the EIP process an injustice by making it responsible for things outside of its scope. The EIP editors, magicians, and catherders help documents through a document process; whether each document is widely and uniformly adopted (and thus can be called a “standard”) is something they have not been (and should not be!) resourced or empowered to influence. It is our belief that adoption is healthiest and most efficient as a separate (and carefully separated) concern. It is also our belief that supporting and coordinating across different categories of standard is worth doing, and worth doing now, given the juncture at which we find ourselves.
To start with, we should recognize that the meaning of “adoption” varies widely between different kinds of standard, or in EIP terms, between different categories of EIP, particularly as many shades of EVM-compatibility are rolled out. At the level of Ethereum clients (core
and networking
proposals, as well as Rollup Improvement proposals in the case of Layer-2 clients, i.e. validators), the ethereum client working group (“AllCoreDevs”, or “ACD”) can encourage individual clients to adopt a proposal, and later schedule it onto a hardfork to make it mandatory for all clients, making “adoption” a fairly binary category. At the level of smart contracts and wallets, however, protocol changes don’t come into play and market adoption is both paramount and fuzzy, and currently somewhat ad hoc and thus intransparent to boot. At the level of changes to smart contract bytecode or specific compiled languages like Solidity and Vyper, distinct communities beyond Ethereum coordinate adoption and backwards compatibility. To some degree, wallet<>node interfaces are specified and regularized by the “execution API” and OpenRPC project, but this is not yet an integral part of the EIP process or the standardization process more generally.
As the blockchain space is growing in maturity and complexity, the gaps between these various adoption communities seems to be growing. The monolithic “EIP process” is starting to adapt to these divergent constituencies, who are lobbying for greater control over the standards process as a whole, of which the specification process is just a middle-step. To mitigate the risk of a “splintering” or “siloing” of those processes, this document seeks to describe a “big picture” that might be shared across all of them and create a common language that maximizes understanding and interaction between them.
We could generalize the lifecycle of standards in evolving software markets to a 5-stage process:
We could say that stages 1 & 2 are currently optional; they are sometimes done in an ad hoc manner on ethereum-magicians or equivalent discussion fora online, or at public events, leading to an “initial draft” of an EIP, but while this might be considered “best practice” there is little incentive to do it so publicly. Indeed, particularly at the level of wallets and smart contracts, there are many incentives NOT to design in the open what might otherwise end up a differentiating, competitive feature. Many design discussions happen in private or company-internal channels and proceed straight to step 3 by opening a PR containing an initial draft of an EIP.
The current EIP process encompasses step 3, and optionally step 4; the “feature freeze” part is entirely up to the EIP author to propose and incentivize, and can even be skipped over since the EIP process is relatively unopinionated about the normative “content” (features and security or privacy implications thereof), by design. One could say the current process is maximally permissionless, putting a high premium on neutrality. It is worth mentioning that in more formal SDO processes like W3C, IETF, and ISO, there is a designated maximum and minimum time for this “post-feature freeze” review of implications, usually combined with structured horizontal review processes to ensure uninterested parties with security and/or privacy expertise “red team” the specification.
The fifth step is currently outside the scope of the EIP process, to such an extent that security professionals keep complaining that they don’t know how or where to publish security guidance relevant to the implementers of long-final documents like ERC-20. While the feedback loop of errata to new features is closed to some degree in the ACD categories, there is a pronounced lack of an ACD equivalent at other levels to support either function, much less coordinate them into a feedback loop. The following describes ways this could be formalized and extended to other category-bound standing working groups, or even replicated in other decentralized improvement processes.
In the first stage, the initial idea is to highlight the problem being solved, potential use cases, and a high level idea of the technical idea, defining a problem space and one or more solutions that would benefit from standardization. Input from far afield (especially non-technical and business specialists!) can be a stitch in time here!
This is really about getting the initial problem statement down on paper to determine if one solution might be worth standardizing on (rather than solving independently or competitively). In many cases, even a general category of solution might be premature, although in other cases a sketch of a solution might be needed to find the right counterparties to design it together. The equivalent stage in the IETF would be something like a rudimentary first draft published as an “internet draft” or an informational-track use-case or problem statement circulated for review (usually through the mailing list of a standing working group or even dispatch-wide). Within a less formalized context like the Chromium developer community, the equivalent would be the publication of an explainer. By having a document that’s shareable we can sanity-check the impulse to standardize in the first place, and find collaborators and potential implementers as soon as possible. An ethereum-magicians thread with a few in-depth responses might be enough to be ready to start an EIP process (if a final EIP is the only goal), and that could be called the bare minimum “stage 1” for a specification, but something a little more complex, the captures the imagination of companies or projects rather than individual, researchers and hobbyists, would be table-stakes if for “stage 1” of an adopted, multi-stakeholder standard, at the level of wallets or smart contracts.
These “problem space”/groundwork documents will likely be published on an individual or organizational Github or collaboration tool like HackMD or Cryptpad, and they do not need any sort of formal document process in place for them (unless IP is particularly sensitive at this stage). They’re intended to be low stakes design documents that can be shared and if they’re not retained it won’t harm the development of a future standard. At this stage, there may be many competing solutions to address a problem, and that is often a good sign that there’s desire by numerous parties to standardize on this and move it forward. There might just as well be no solutions yet in prod or publicly described, but in this case, the thing to look for is multiple stakeholders (competitors, perhaps) all recognizing a shared business problem, or a business problem in common that would be better solved by a small number of common solutions rather than 100 incompatible parallel solutions.
In general, Working Groups at SDOs tend to be rightly be wary of taking on work items that are championed only by a single party, that arrives suspiciouly complete; working groups in the EIP context should similarly discourage or at least be skeptical of such specification projects. Perhaps, with enough momentum and institutional memory collected in the relevant working groups, authors or organizations pushing single-author specifications could be asked (or even required) to find a collaborator among the active membership or previous authors in a given category, to provide some credible proof of openness to compromise and co-design.
Once a goal has been set, collaborative design begins in one or more common solution(s); multiple organizations/projects are investing significant labor in going from idea to specification, and want certain guarantees to raise the likelihood of arriving at a standard some day. Standing Working Groups are a sensible default here, efficiently maximizing feedback and front-loading adoption-oriented coordination.
If the main goal of stage 1 is to identify multiple stakeholders and convince them of the value of working together on a solution (ideally, towards an adoption strategy and a standard, not just a spec), the main goal of stage 2 is convince 51% of them of a shortlist of candidate solutions at a high level, as well as a process for agreeing to implement one of them in common. The primary output of stage 2 should be a shared vision of the scope of the work to be done, a rough timeline, and a “plan for a plan”, if not a detailed plan. Maybe that work includes user research, testing design, or other inputs; maybe that work is just a specification, or even a “retrospecification” of something already implemented two different mostly-compatible ways. But the to-do list is less important than the plan for crossing off all the items.
In an “ad hoc working group” (i.e., a group that works on 1 specification or a discreet set of interlinked specifications, but disbands after that), this could be called a “working group charter”, but as a work item or formation within a standing working group, this might be more accurately called a “specification charter.” In either case, it often helps to cover things like the IP boundaries of the collaboration, resolution mechanisms/authority, ragequit rights, communications channels, disclosures/transparency expectations, etc. Defining all these explicitly can be a major lift, but a standing working group might provide pre-filled templates or sensible defaults for all these questions. These questions are important for people who actively contribute to help resolve conflicts that may arise after the fact as well as helps non-active contributors to know when they may want to provide feedback or when they may want to consider implementing even if they aren’t active in the specification development.
An explicit “spec charter” document should define:
Often, many of the above are decided implicitly or on-the-fly by the individuals involved, rather than their organizations or process-helpers. As the stakes rise over time, however, there are benefits to being more explicit about them, even if just in the form of GitHub “issue templates” or other formulaic guidance docs. Since working groups covering certain categories naturally accumulate experience with these issues and are familiar with the often unstated business incentives and market dynamics at work, it is far simpler and faster for them to suss out these risks and make these agreements more explicit internally, having already assembled the right people.
On a mechanical note, these same working groups can also centralize (and cross-pollinate) these processes by hosting repositories, document collaboration tools, and/or discussion channels for each current and former standard. It often makes sense to “fork” older ones or related ones to iterate on documents and artefacts originally published elsewhere (whether by another group or by some of the same participants at Stage 1). Using an issue tracker in that repository is recommended to project-manage this stage, since the next stage will likely be centered on the repository somewhere else with its own issue tracker (and perhaps a very different document process and linting regime).
The goal of stage 3 shouldn’t be getting to Review status, but rather, significant adoption and consensus to make that Review phase meaningful– getting the former without the latter can add noise to the channel and erode confidence in the process.
The “charter” (and in particular, its success criteria) could be a very explicit, formal, serious document or it could be a github issue created from a template; in either case, it is best for it to “follow” a specification from its small incubating group (whether in a standing working group or not) into the more public arena of EIP hardening and review by a wider public. This allows the focus to be on the specification qua specification; if other work streams have to be parallelized (like implementation feedback, testing artefacts, sample apps to facilitate evaluation or implementation, etc), it can continue off to the sides, with or without being explicitly referenced on the editorial threads discussing the text of the specification itself.
The degree of formality of this “charter” and how much it bears on the hardening process of the text itself is definitely up for debate, and balancing flexibility against adoption-maximizing mechanisms is difficult. More formal standards bodies generally have a hard requirement of charter-approval by some kind of Technical Architecture Board or other cross-working group coordinating body. That might sound too centralized or top-down for a decentralized stack, but some middle ground might be worth reaching where “approval” by a sponsoring working group, or by one or more coordinating bodies, serves at least as a market signal, if not a hard requirement to EIP review.
If anything, the charter process should be considered orthogonal to the specification hardening process; instead, an explicit charter is an upfront investment in adoption and concensus around the specification being hardened. The value in explicitly “signing up” to a specification charter before or while collaborating on the specification is that offers an early opportunity for concerns or objections to be expressed and addressed. One consequence of more formal and public forms of consensus-building is that conflict resolution might also benefit from a little formality; this should be monitored as working groups develop independently.
Once an EIP is in “draft” status and being edited in public, the goal of the 3rd stage could be defined as refining the specification (on the EIP side), achieve the success criteria of the spec charter (on the non-EIP/WG side), and to ultimately lead to the development of multiple interoperable implementations if the goal is a standard, not just a specification. In the case of All Core Devs, this is also going to be the time in which a implementations will be tested through the test networks. In the case of Wallets and hopefully ERCs, different measures of adoption “viability” should be satisfied, such as turning sample dapps or implementation artefacts into test suites or conformance regimes, or prototyping actual builds. These implementation activities aren’t strictly necessary to a good specification and should probably never be hard requires of the EIP process itself, yet if the goal is an adopted standard and changing behavior in the market, standards-oriented project should probably coordinate them at this stage and benefit from feedback between specification and prototyping. Debatably, some working groups might even want to link the two processes explicitly or track implementation feedback in the same threads and repos where the specification is happening, to ensure and maximize that feedback.
It’s been suggested that one way to improve draft specifications is for prototype and user-research discussions to take place as close to the sspecification a possible, e.g. in Github issues, links to other repos, and discussions. This might be too prescriptive if applied across a whole working group, though, as some communities or teams may prefer their discussions to center on recurring calls or informal communication channels such as Discord as well. It’s up to the group developing the spec to define the ways in which they want to communicate, but it helps to keep the focus on feedback and coordination as activity spans out across private implementations, prototypes, user research, etc.
The “review” phase can and should be more than a polite last call for objections–it should be where the circle of adoption grows and valuable feedback comes in from a different class of implementer.
As currently structured, the “Review” phase (and the minimum-two-week “Last Call” phase that ends it) represent a completed, finalizable document receiving its last feedback before going final, at which point the EIP process ends (and adoption happens, or doesn’t, completely outside its purview). There is a sort of unspoken rule that substantial changes “reset the clock” and extend the time for review, particularly in “Last Call”. It is a very finality-focused process focused on the specification at present, and there are often implied or interpreted stakes of importance or legitimacy mapped onto that status.
We propose rethinking this “home stretch” more holistically, as a chance to expand the circle of implementers beyond those who committed in advance (e.g. by collaborating on a charter or contributing), and for listening to implementer and evaluators further afield. Instead of thinking of this stage as “cement pouring” after which no interventions are possible, we could think of it as the transition from specification-driven to adoption-driven, opening the latter door at the same time that the former closes. Particularly in cases where adoption and consensus have been supported all along by supplemental artefacts and public events, the “last call” period can be a springboard for more adoption, an occasion to reach out to participants that dropped off, and a time to start thinking long-term after the afterlife of the specification.
These cases, where adoption and standardization is the goal, might be difficult to coordinate without, e.g., the non-specification deliverables slowing down the usual specification timelines. We believe this stage will vary widely, and we should resist the temptation to complicate or formalize too much the expectations of this stage, even in specific working groups, as a greater degree of formality and adoption-oriented supplemental work could multiply the stakes and the potential for serious conflicts. As mentioned above, more centralized standards organizations handle differently objections that arrive after “feature freeze”, adjudicating them with some kind of organization-wide Review Board (often Architectural or Technical in scope). This approach would be harder to replicate in some categories than others, but working groups could certainly adopt some version of this (whether mandatory or recommended) as they tailor their processes.
There is a temptation to formalize the relationship between the specification-finality side of stage 4 and the “running code” or product-launch or testing side of stage 4, to protect early implementers from major breakage with minutes left on the clock, but this crosses the streams of specification and adoption a bit. We do not feel that a one-size-fits-all solution makes sense here, even working-group wide, although perhaps it would make sense to consider this less as a gating condition or hard requirements than as an optional sidequest, such as an orthogonal (but public) badge of approval or working group “certification”.
Sometimes the best implementation reports comes months after adoption picks up– after the painful hack post mortems, for example. How to create upgrade paths and feedback loops informing future documents and standards?
Currently, the EIP process is optimized for “immutability”– much of the editorial review gating “Review” status is focused on maximizing the longevity and maintainability of documents, on the assumption they will never be changed again. There is no errata process currently, nor a mechanism for searching the current EIP corpus for later EIPs that update or extend an earlier EIP, much less dynamic “forward links” on an earlier EIP to later EIPs. The only way to update an EIP is to publish a new informational one, and then make sure the right people see it somehow.
While any or even all of the above-mentioned mechanisms would be welcome, they are hard to implement permissionlessly without some kind of counterweight to self-attested claims of relevance. This is partly because stage 5 isn’t really about documents or specifications, but about interpretations, implementations, ongoing conversations outside of the documents. While more formal standards bodies use testing bounties and standing topical working groups to gate new specifications and monitor adoption of finalized one in a closed and expert-filled feedback loop, that kind of centralization might be unpopular in our space. What is the more transparent, do-ocratic equivalent that relies less on authority and more on sweat equity?
In communities such as AllCoreDevs
where there is a large importance placed on specification and testing, implementers and specification writers past and future are already in dialogue, so this fifth stage happens automatically, or “falls out” of other communications channels and discussions. In the smart contract and wallet spaces, however, business incentives do not align with and support this kind of feedback, and figuring out what mechanisms will support it cheaply, without being onerous on all involved, is something of an open question.
Our intuition is that working groups that share a similar function to AllCoreDevs
, which require of their proposal authors a certain degree of prototyping and adoption-strategizing and prior-art research to happen before taking on a work item, is a low-risk place to start. Top-down solutions beyond that seem premature, but coordinating and finding a common language across categories for what these working groups do would allow them all to experiment and compare results before trying to generalize common solutions. Kicking off the Wallet Working Group seems like a great start, now that the wallet testing framework is achieving maturity and we can run experiments like asking authors to link to prototypes that implement proposed features while fully passing the WTF (a kind of lightweight “reference framework” requirement that aids adoption and evaluation).
To put it another way, Stages 1 and 5 bleed into one another and are best done by the same people or in the same places, but both are currently done in an ad hoc way at best, by volunteers or passionate individuals, sometimes on long meandering ethereum-magicians threads and sometimes not done at all. Insofar as Stages 1 and 5 are a recognizable part of standards process in more formal, less permissionless environments like technical SDOs, the blockchain community’s treatment of them could well be the most underfunded, undersupported, and underdeveloped part of how we “do” standards, and the lowest-hanging fruit in doing them better. We firmly believe that bridging stages 5 and 1 is best done by standing working groups, and we stand ready and motivated to help this crucial function be fulfilled across the space.
We have tried sketching out how to start thinking about a broader standardization process beyond the publishing of documents, and we hope reframes the familiar questions and expectations around EIPs. We have tried to stop short of prescriptions or excessive formality, while still signaling where centralized standardization has landed in its solutions to analogous problems. We hope that this document can percolate and influence people over time, on a long-term vision level rather than on a short- or medium-term tactical level.
Tactically, however, it is 2024 and there is a distinctly wintery chill in the air, prices notwithstanding. Most employed heads are down and furiously building, making this a great time to shift incentives and encourage more transparent alignment and coordination on the dapp and wallet level. This coordination takes many forms, which could add up to a lot even if each seems small on its own:
The authors would like to thank, in no particular order, @chaals
, @SamWilsn
, and Annett Rolikova for reviewing this before it was published, and you for reading this far.
See A.L. Russell’s 2006 article in IEEE Annals of Computing Hstiroy for a detailed history of the phrase. ↩
Since 2020, my (bumblefudge’s) career northstar has been sustainably making myself helpful to the advancement of human agency in the digital realm, an umbrella that encompassing disparate work in the “self-sovereign” identity-tech world, the “on-chain money” world, the “interplanetary data” world, and the “social web”. In fact, in 2020 this work didn’t even feel all that disparate, and only when checking back in with my feelings last week did I realize there was more under the umbrella than I realized at the time. Thematic focus aside, the euphemism “sustainably” is doing a lot of work in that first sentence; I try never to work “for free,” even more so now that I am a father, but naturally higher-paying work subsidizes lower-paying work when I’m lucky enough to get both.
Doing so while trying to “own” any part of my work (to seek rents in the present or future from that ownership claim) never sat well with me, so I have not taken equity, intellectual property, or even cryptographic (“on-chain”) tokens as payment for my time in any of this work. Perhaps there is a transparent, ethical, no-risk way of doing so, but I have been too busy playing connect the dots and learning all I can to bother with those details; “maybe later,” I say every time it comes up.
For as much as I never wanted to “own” a rent-seeking apparatus, or for that matter a “company,” it quickly became clear that in much of today’s world, and particularly in the software world (as befits an industry centered on seeking rents from intellectual property), companies get better property rights than individuals, and companies (particularly foreign companies) prefer to deal with other companies anywhere they can, as do governments. The conventional path of working across organization borders by “freelancing” doesn’t really work as well across national boundaries, however. To de-risk and simplify this situation for my clients, collaborators and the funders of agile prototyping and R&D efforts, some of them public, Balázs and I incorporated learningProof UG in 2020 precisely to “abstract out” the legal requirements and liabilities required of employment, contracting, and consulting, letting me (bumblefudge) and, as needed, my collaborators and colleagues on various projects focus on the work at hand, tracking hours and minimizing administrivia. To date, it’s mostly been a “pass-through” (or a “shell corporation” as I like to joke), simplifying how I bill my hours when I’m working for people outside Germany, which most of my clients have been. It has worked great for spinning up (and down) lightweight collaborations across and beyond the EU to do the kind of specialist tinkering that is required when you are proposing novel infrastructures for future internets.
But last year was different. The utopian vision of a more just “Social Web” seemed to hit everyone all at once in 2023 like some kind of ideological pandemic, as the critical communications infrastructure we euphemistically call “social media” underwent one of those “multicrises” that are so in vogue these days. Most of the crises reported as distinct were, to the cynical eyes, simply two sides of one coin: they governance crises triggered by omnipotent billionaires indulging in seemingly personal brinkmanship was just the tabloid sideshow distracting us all from the real macro-narrative: with the sudden end of the US Fed’s zero-interest experiment, the shareholders of virtually every major technology platform demanded rapid “enshittification” (forgive the technical jargon) of their formerly benign-seeming freemium platforms, seeing no other way to quickly ratchet up dividends to perform above interest rates. Putting critical infrastructure for democracy and global information flows into the hands of advertising monopolies governed by private equity and openly maximizing profits above all public obligations and functions was starting to look like a bad idea even to observers who generally like public infrastructure to be operated for private profits.
What could little learningProof do to tilt at these world-historical windmills? A privately-held, profit-maximizing endeavor (however small and agile) was neither the right shape nor the right speed for this side-quest; the vibes were off, dear reader. Billionaires and boards running information business like health insurance companies got us into this mess; whatever was the opposite of that seemed a good way of going 180 degrees in the opposite direction. We needed to think bigger, flatter, not just learningProof but enshittificationProof, profitLocal or even profitNeutral, sharing the work and its wages do-ocratically and humbly. No C-suite, no shareholders, no masters to whom profits could be expected or demanded to be exfiltrated.
Wait, who is we
, you may be asking?
Wasn’t the first-person singular until now?
For now, the we
began as @codenamedmitri, bengo.is, and myself.
I have been collaborating sporadically and coordinating efforts with the former since 2019 on all things decentralized identity, since almost the minute I understood that phrase to refer to one path to human agency in the digital realm.
Unbenownst to me, I somehow failed to meet the latter at an ActivityPub conference in Prague that the former invited me to when I was in town for the 2019 Rebooting the Web of Trust conference a few blocks away.
Over the last two years, I’ve been discussing ActivityPub more and more with both Bengo and Dmitri, collaborating where we can, aligning our disparate efforts, particularly in the context of ActivityPub, a headless protocol formalized in 2019 and self-governed in the most wonderfully and chaotically decentralized way. Our collaboration started as a simple, almost daily groupchat about current events, filling one another in on all kinds of backstory and perspectives on what was unfolding every day on the various relevant hashtags, making sense of it together. It quickly grew to feel like a team working together on shared problems and toward a shared vision.
We decided that a conventional shareholder corporation wasn’t the right fit for working on public infrastructure verging ever closer to being “critical”; many of our role-models in public-good technology were B-corporations, non-profits, unincorporated collectives, and worker-owned co-operatives. The last of these felt the closest to our do-ocratic way of working and our transparency goals: a conventional LLC, except incapable of selling equity, keeping 100% of the governance of all assets, projects, and liabilities within the organization.
The three of us agreed from the beginning that this protocol, in comparison to other global networks of loosely or trustlessly federated “servers” (matrix, secure scuttlebutt, blockchains, SoLiD, etc.), somehow grew to serve millions of users without a reference implementations and a conformance regime; a community of doggèd developers gritted their teeth through a lot of ad hoc coordination and experimentation to arrive at an open social graph that worked well enough for its millions of emmigrants from the industrialized attention economy commonly referred to as “social media”. In 2023, the social media & personal messaging “sector” of the software industry from which this ad hoc federated social web had rebelled and run screaming was suddenly collapsing and people were pouring out of the exits; the “Fediverse”, long artesanal and proudly devoid of an internal economy, might just need to blitzscale and adapt to a reality in which some commercial or semi-commercial form of Fediverse couldn’t help but develop.
At the same time as we were speaking to each other about how the Social Web might harness these market forces, regulatory groundswells, and cultural narratives, we were also speaking to developers across our various social and professional worlds. It was clear that ActivityPub, the protocol out of which today’s Fediverse grew as a tentative first instantiation, was really no more visible than in 2019 as a vision or as a reality. The Fediverse was experiencing growing pains (as millions of new users poured into web2 server architectures that had never really been optimized to scale efficiently), but also upgrading pains, as there was no medium-term shared vision on the horizon behind the immediate technical debts or user needs that plague software this ambitious. In the most practical sense, ActivityPub had never become a “protocol” anyone knew or thought about distinct from the Fediverse because it didn’t have a reference implementation and a conformance system anyone could use in decision-making about its capabilities, its strengths and weaknesses, and its role in the greater web; all we had was a few implementations, interoperating with one another patchily, and no one incentivized, much less funded in a sustainably and credibly neutral way, to get us to that point.
Left to play out naturally, these market conditions would likely push the already ad hoc Fediverse to move rapidly further from the ambitious (and admittedly difficult) path imagined by the open protocol’s early designers. Without a lot of work on the neutral core that powers the federation of diverse software and user experiences and products, the goals of the ActivityPub community whose conference Dmitri invited me to crash in 2019 would likely get lost in the shuffle. And without the typical foundation people have when trying to build on an existing protocol or platform (i.e. a reference implementation and a testing regime), who could blame selfless community-motivated developers for optimizing for local maxima and clearer, better-documented goals?
Fortuitiously, we weren’t the only people thinking about credible neutrality and the kinds of investments needed to defend the digital Commons from market forces in 2023. Our conversations about ActivityPub landed in the right place at the right time, in that they coincided with the entrance of a major new force in the funding landscape for open source. It was a big year for public-good technology in Germany: increasingly, the German Fediverse was coming into its own and trying to strategize about the culture clash implied by massive US-based companies entering the Fediverse at the Chaos Communications Camp and many smaller fediverse- or data-sovereignty events.
At the same time, the Sovereign Tech Fund was emerging to channel energies from the policy and civil society communities trying to navigate these topics. Incubated by FOSS powerhouse SprinD GmbH, STF was establishing itself as a funder of exactly the kind of credibly neutral Free Open-Source Software that favors protocols over platforms. Sovereign Technology Fund’s mission, and in particular it’s pursuit of sustainable, long-term governance for open infrastructure resonated with our project to keep ActivityPub (the underlying protocol) up to date with the evolving product landscape built on top of it. We worked with the exceedingly excellent @tarakiyee@mastodon.online to scope a service contract that would fall squarely within the mission of STF and also be timely to the evolving landscape of the Fediverse, focusing on industrial-strength CI testing to make protocol conformance more objective and protocol extension more time-efficient, user portability, data portability, and developer community integration. It was a match!
One problem with a cooperative is that you can’t “raise” “money” (or, less euphemistically, you can’t borrow cash or pre-sell governance rights against the future organization); you can only keep a portion of the money passing through the organization on its way to the workers doing the work, and use that to amass operating capital for collective outlays. The coöp had, in Sovereign Technology Fund, its first paying contract to bootstrap itself into existence, and Sovereign Technology Fund was happy to be investing (non-dilutively) in a sustainable enterprise committed to keeping open infrastructure open, as usable. Most contracts, however, are signed between pre-existing organizations, so learningProof is, on paper, fulfilling this contract, as a pass-through, fiscal sponsor, and liability host.
The contract we signed was broken up into a few workstreams (testing, new features, and community support/integration), which structure the contract into three phases punctuated by three milestones.
We’ll be posting grant reports here on the coop project’s own website, as each of the milestones of the project are reached and outputs thereof open-sourced. In the meantime, stay tuned to the #ActivityPub channel on the Fediverse for developer chatter and the mailing list of the W3C Community Group for standards topics.
]]>2023 was wild: my first child was born, I took the longest sabbatical I’ve taken since my professor days, I made some drastic moves professionally and geographically:
multiformats
could go from “some repo on github” to an IETF working group (god, and IETF’s membership, willing!), which only has a chance at working if I concomitantly get my hands dirty throughout the greater protocol labs interplanetary archipelago, working on conformance this and specifications that as that archipelago nucleates out into something even more anarchic. For as corny as it sounds, it has truly been a joy to get to know both the immediate collaborators in my core team and also the whole ipfs
-loving community of collaborators, contributors, and even loving defectors and re-implementers, from whom I have learned so much in 2023 that I should probably write another, longer piece just to fail at doing justice to their intellectual generosity. Lucky is the researcher who gets paid on the job, even when the job is not this novel and bizarre and ambitious and world-building.did:web
to support new architectures and projects across the education space but also the decentralization and alternative publication spaces.On a more banal, personal note:
Going forward, 2024 might just be the year where learningProof’s blogs are written in the first-person plural, since all my goals for this year are really goals for various us
s.
oh and we need a new internet, this should be the year we actually make one.
lfg, –bumble
]]>Over a year ago, someone asked me for a personal essay on why I care so much about decentralized identity. What I ended up with after a weekend of freewriting was more manifesto and jeremiad than explanation (technological or emotional) but I went with it and published on Medium. I’m including it here as an overview of the context in which LearningProof does its work. The original tagline was, “An optimistic introduction to what could come after the total sovereignty of the VC-funded cycle of disruptions and consolidations” and in this context I would only add that at LearningProof, we do only (and anything) we are confident moves our world closer to that “after.”
Various new kinds of software, we are endlessly being told, are the Next Big Thing, just about to disrupt like a volcano of New e-Things that will certainly upend all of the things in the next X years. After you’ve read enough in this genre, it turns into a guessing game: will they put X at 5 years, or 9, or 7? You can usually tell by the adjectives in the first three sentences, as the rhetoric is at best overblown Ciceronian pomp and at worst Ted Talk runoff. I like to fill out a bingo card seeing how many rhetorical and ideological crimes I can identify in a given breathless Medium “article” promoting a new startup, written by someone literally overleveraged in the success of its product offering. Here’s a partial list, in case you want to make up bingo cards of your own:
Venture capital is the real audience of these missives, and, as Mike Judge’s blunt, Aspie CEO seminally quips on the HBO comedy, Silicon Valley, “The stock is the product.” The winner of this debate tournament is whoever promises the most disruption, since that is what the gamblers came to bet on. As we say in Spanish, “A río revuelto, ganancia de pescadores”—when the waters are choppy, [only] the fisherman comes out ahead. (And no, there are not fisherwomen in this analogy.)
These mammoth disruptions very rarely correspond to giant technical leaps, however; most of them are results of the tiniest of innovations in user experience design, marketing, or convenience engineering. From a computer science point of view, these disruptive apps are apex predators on many levels. They centralize or repackage the data traces left by human experience in a tidy, privatized bureaucracy of monetizable information, but to do so, they stand on the shoulders of data processing giants, mammoth infrastructural investments, decades-long collective refinements funding by private-public partnerships and backroom deals with national-security agencies. In just a few short decades, to the tune of neoliberalism’s mantra (“but who will pay for it, surely not me, or us?”), all of this mammoth infrastructural apparatus was rapidly and irrevocably privatized in both legal substance and public perception. The casino of speculative finance not only wrested away from government any control or even regulatory power over the internet “industry,” but in the process it has also convinced the public that many new, dangerous economic practices and social structures are permanent, natural, and inherent to “the internet age”.
Increasingly, access to monetizable data is distributed even less fairly than access to capital or to credit, while we keep being told ad nauseum that this is just how the internet works, end of story. As public distrust and even anger grows towards the ever-consolidating data traps holding our baby photos and high school acquaintances hostage, we are told that there is no alternative to trading privacy and anonymity for access to a public sphere hosted on private servers and monetized for shareholders. The internet has been defined as a giant machine trading us convenience for our data, which it must necessarily convert into fodder for “machine learning” (aka job-eviscerating automation) and dividends for shareholders (offshored and undertaxed, if taxed at all). We are told that our private thoughts and personal details are the lifeblood of the whole system, that without our data there is no there there, that no business or information technology or convenience is imaginable without it.
I am here to tell you, dear reader, that the next big thing in software is the opposite of all that naturalized and coercive data profiteering. The Next Big Thing is granular and total control over all the data pertaining to your “account” anywhere you open one, with no other data held there, and none of that data shared with anyone else. The next internet will not be a giant pyramid scheme devised to pry your data from you and then sell it to third parties. The Next Big Thing is not privacy or anonymity, although it includes a systematic right to exercise both a lot more easily and often. The Next Big Thing is granular data sovereignty and more sophisticated interactions of the public and private spheres. The Next Big Thing is Self-Sovereign Identity, as it is called among its devoted nerds. You are the Next Big Thing.
To the non-technical, but politically savvy reader, “sovereignty” might seem a hyperbolic term to use for better data controls, but there is a crucial distinction to be made between having the “right” to have your data “forgotten” by request (a right enforced by government regulation and by after-the-fact fines) on the one hand, and on the other, having the power to easily and conveniently delete your own data anywhere it’s stored (a power guaranteed by the design of, and exerted directly through, the data structures themselves). The latter power is sovereignty; the former right is a 19th century form of liberalism held limply in check by shaky, contingent regulation, the kinks in which are still very much being worked out. And supply-side regulation at that, not the most historically effective or popular at time of press.
But speaking of unpopular supply-side regulations, the European Union has recently started enforcing an ambitious set of supply-side data protections, limits, and regulations, a mammoth piece of continental legislature commonly referred to as GDPR (“General Data Protection Regulation”). It was the result of millions of hours of research and multiparty negotiations, a finely-engineered Great Wall of a law, which basically set out to update aging legal concepts around privacy and consumer protections, disincentivizing coercive and secretive business practices rather than banning them outright.
No one in the industry missed this epochal challenge, particularly no one reading quarter call reports. The data industry was, and remains, shook. Every internet business entangled in the ecosystem of data capture and data processing is currently scrambling to shut down a whole continent of its data harvesting operations, rewriting their already-baroque, hundred-page terms of service contracts and privacy policies statements to reflect newly-obligatory protections of the end-user’s rights. Other than a global tidal wave of emails notifying these end-users about updates to those contracts, a less legally-savvy internet dweller could totally miss the importance of this legal paradigm shift. But lawyers and accountants at massive conglomerates like Google have put serious resources behind simultaneously fighting against and planning for this sea-change for years, even if it could seem they’re still playing catchup today. In fact, most of the key players in the data industry will need many more years of retooling to come into full compliance, and in the meantime they have no choice but to budget in massive non-compliance fines levied by the day. Middle-sized data concerns have, so far, been the hardest hit (relative to their operating budgets), but the future of these legal battles is hard to predict, given the amounts of money and jobs at play, much less the politics. At least insofar as the same was said of the Big Banks after the speculation crisis of 2008, perhaps the Big Data concerns are too big to fail, or at least, so big that their failing in the near future would be a hassle to the interests that the EU represents.
But focusing too much on how GDPR affects the big players in today’s data economy is giving far too little credit to the EU’s long-term vision of competition and protectionism. I, an optimist, see the real long game of GDPR to be one of distracting and slowing Big Data, buying some time for the little guys to keep trying radically new things. In my opinion, an understudied positive outcome of GDPR is that it stacks the investment and licensing cards in favor of any business minimizing its reliance on re-appropriated personal data and psychological manipulation. GDPR is a godsend for everyone trying to build slower tech, more ethical tech, tactical tech that Silicon Valley would not only never invest in, but has historically tried to strangle in the crib to protect its deep investments in the most nefarious forms of surveillance capitalism. (Full disclosure: I live in Berlin and I contribute in small ways to various non-profit and commercial projects, in addition to doing paid research and consulting for an SSI-specialized research firm called The Purple Tornado.)
One thing that GDPR seems specifically geared towards encouraging is new kinds of networking and services built on a foundation of Self-Sovereign Identity, which many glibly (and perhaps inaccurately) summarize as “GDPR-compliant by design” at a time when GDPR compliance seems a distant fever-dream to every large internet company operating in Europe. Much like the nerdier, more public-sector-oriented corners of the broader blockchain ecosystem, or the peer-to-peer networking scene, self-sovereign identity is currently more of a community than an industry, with engineers and ideologues heavily represented at conferences without much of the smell of money in the air. There are a few standards organizations working out the interoperability of future large-scale platforms and infrastructure projects, and these have, to date, been relatively good about keeping a place at the table for smaller, non-profit players and government initiatives. There are conferences and whitepapers, there are roundtables at Davos and reports by industry futurists and public-good technologists. There are small, closely-watch trials being run of government systems built on a foundation of SSI in Northern Europe, Switzerland, and Canada.
For obvious reasons, there aren’t huge pots of speculative capital rushing this or that specific initiative to market; for the most part, SSI is starting small and open-source, mostly funded by government grants and long-view R&D investments from industry giants. Of the few companies incorporated and running a payroll already, a surprisingly high portion are B-corps, “social enterprises,” and true, independent non-profits. SSI tech is not coming soon to the walled garden of a cellphone app store near you. But if you follow the weirder, more cutting-edge trade papers and tech conferences, you might hear whispers blowing through the trees.
In many ways, SSI is not a bold new vision of the internet, but a return to the foundations of the internet, when the costs of building new infrastructure were still openly shared and the Sharing Economy hadn’t been patented and monetized yet. (To those that would challenge such a linear intellectual history, I would perhaps caveat this reference to the “foundational” vision of the internet as perhaps a tad more indebted to Ted Nelson than to Tim Berners-Lee.) If anything, GDPR crystallized and acted on decades of mounting unease with which the global middle class watched an increasingly homogenous and overtly neoliberal software industry bully all other industries and governments worldwide. GDPR is hardly a perfect law and I would hate to come across as a cheerleader for it, but it has proven a decisive move to shift the ground under the most powerful industry on earth, disincentivizing business models that it implicitly designated as toxic and protecting a space in which to experiment with new ones. At its best, that space will foment scrappy, righteous alternatives (and yes, more startups, for better or worse) that no one will tell you about on pay-to-play information platforms like Facebook or Google News. Or, to put it another way, that no one has borrowed enough venture capital to pay Facebook and Instagram to spread the word about, at their current rates.
Back to brass tacks: what does an internet built on the basis of self-sovereign identity actually look like? How can you retain “sovereign” control over your data if it’s still being stored on a company’s servers and processed to do cool stuff with it?
First off, there is far less of your data going to each company and the companies aren’t sharing it between them, so there is a lot less data at play in any given transaction. Indeed, limiting each transaction or account’s data access to the “minimum data necessary” is a kind of mantra to the most hard-line SSI thinkers. And to be clear, these hard-liners have a pretty solid point about “SSO” (single sign-on), the user-friendly password workaround that give the google/facebook duopoly access to the lion’s share of personal data on earth. Every account you access “through” a facebook or google account gets lumped in with all the data facebook or google already got from you directly, making the “files” that data brokers legally gather on each of us massive archives by comparison to what the East German secret police kept in filing cabinets on its most suspicious and free-thinking citizens.
Why is it so easy for shady data brokerage companies to collate all your data from diverse sources and sell those composites on the open market legally? Why are there copies of your address and social security number on every server and cloud on earth, if all you really need to prove is age here, address there, valid driver’s license or car insurance in a few cases? How did we get to a place in history where it is so terrifyingly easy to track the location of anyone by their mobile phone number? Not by using the minimum data necessary, for starters, and for the profits to outweigh the costs of misusing data, lying to the people that generate it, and selling it to the highest bidder.
Secondly, your “sovereignty” over the valuable and scarce data you do choose to give out hinges on complex systems of cryptography: the shift in power on the social level is effected by a shift in data structures whereby the access you grant others to your data is enforced by the lending, granting, and changing of “keys” and “locks”. (For the highly non-technical, just remember the worst breakup of your life, whether personal or professional, and that moment when you think to yourself: “What if I change the locks while they’re out?”).
In a cryptographically-enforced data sovereignty model, you prove your identity each time you sign in by presenting a one-time cryptographic “key” that the site then uses to encrypt your data anywhere it is stored or transmitted, aka, anywhere it could be hacked or breached. Your data is meaningless without temporary and revocable access to a key that lives in your private wallet. In the case of most current SSI pilots and betas, that key lives in a MetaMask wallet or something similar– a browser add-on or app that securely stores your key to various accounts. Alternative storage methods exist as well, for more complicated security situations. To put it another way, every time you log off, you pull your key out of the lock and all the core, protected data of your account gets instantly encrypted back into gobbledygook; until you log back in, no one, not even the site itself, should be able to read, much less change or sell, any of it.
The “attack surfaces” for malfeasance or unauthorized access to your data are not reduced to zero, but they are smaller, and enforcing fair play on the remaining ones might only be possible if the core code is, if not completely open, at least periodically reviewed by neutral third parties, be they governments, competitors, or white-hats. From the end-user’s point of view, all this translates to a simpler social contract: you have at no point traded or “sold” your data to a company that doesn’t have powerful access to it even while it’s processing it. You have rented your data out to one party, and you can effectively erase it yourself without logging in to that party’s platform, simply by revoking the access credentials you issued to the site.
This might seem like an overzealously individualistic foundation for a new digital economy, but many see it as more akin to double-entry bookkeeping, forcing the designers and builders of data systems to factor user privacy and more thoughtful data design into their core architecture rather than dismissing data breaches and complex user needs as “externalities” or “corner-cases” for the lawyers to worry about later. As anyone who has worked in information security can tell you, the vast majority of data systems were not (and are still not) designed with security or privacy as core functions; instead, they are built insecurely, shown to investors, and then at the last minute, just before rushing them to market, they have flimsy security and privacy controls “bolted on” after the fact.
This organizational dysfunction within the industry might have been less consequential in earlier moment in the history of capitalism, but in this one, there is a worldwide shortage of qualified information security professionals keeping those controls bolted on, and a rapidly growing black market for, shall we say, informal information security professionals trying to loosen those bolts day in and day out. “Web 2.0”, as some people call our current dominant model of social media and other platforms powered by personal data and surveillance, has evolved from a global village to a hacker’s paradise, a data broker’s fire-sale, and a private, cautious person’s hellscape in less than two decades.
Scrapping it all and starting over is starting to sound like a good idea to whole swathes of the world’s population. If we get lucky, Web 3.0 will be a lot less vertically-consolidated, powered by collectively-governed systems and peer-to-peer networks, with a lot less robber-barons and stock-rich oligopolies moving fast and breaking shit. Maybe the coming internet will be a much smaller, quieter, slower, and more humble internet that, plainly put, just does less and disrupts nothing at all. I can almost guarantee it will be drastically less convenient, at least for the first generation or two. But if that’s the price of getting the teeth of the data vampires out of our necks, it might be worth a shot. Maybe we’re drunk on seemingly boundless convenience, and it would do us some good to build something a little more slowly and empathetically for a change.
]]>