This is an intention post and a call for collaborators. I’m convening this topic rather
than proposing to run it single-handed: the framing, the argument and the introductions are
here, and I’m looking for an operating team to build it with — particularly India-based
organisers. See Team for exactly what’s committed and what isn’t.
Summary of Proposal
A hands-on space for running your own connection to Ethereum. Self-custody answered “not
your keys, not your coins.” This hub tackles its unsolved twin — “not your node, not your
data.” Bring the laptop you already carry, and leave with a verifying light client running
on it.
Motivation and Rationale
The problem is invisible and nearly universal. Almost every Ethereum user reaches the
network through a third-party RPC endpoint: a company that sees every question they ask and
chooses what to answer. People who have carefully self-custodied their keys still hand their
entire view of the chain to an intermediary, and mostly don’t know they’re doing it.
The EF Mandate names this directly. Section VI, point 4:
There are already many places across the Ethereum protocol and application layer - block
building, RPC servers, entities attesting to aspects of digital identity - where
intermediaries exist. This state of affairs carries serious risks: one or more
intermediaries may become dominant chokepoints, impose their special interests, censor
users, enforce arbitrary participation rules, or extract value.
And sets the standard:
In particular, we ensure the presence of a “zero option”: for every affordance that has
an intermediated path, any intermediary-free path that is possible must be built and must
remain credible and accessible.
For RPC, that intermediary-free path is thinner than the ecosystem assumes. The Portal
Network was meant to provide it; its reference client, Trin, is now explicitly unmaintained.
Light client work more broadly has a habit of falling off roadmaps — as recently as May 2026,
Lodestar’s light client and prover packages were moved out of the flagship monorepo into a
separate repository. Good work exists, in Nimbus, Helios, Lodestar and elsewhere, and much of
it is genuinely usable today. But it is maintained by very few people, it is largely
invisible to the users who would benefit most, and nobody is currently accountable for the
layer as a whole.
That gap is the reason for this hub. The tooling has quietly become real; almost nobody
knows, and the people maintaining it are working without much company.
How it enhances the attendee experience. Most Devcon content is watched. This is
installed. An attendee walks in depending on someone else’s node and walks out not
depending on it, on the device already in their bag. That is a rare thing to be able to
offer, and it is memorable precisely because it changes something the attendee owns.
On phones the honest answer is different, and it makes for a better session. A
standalone node app on Android has to drop its peer connections when idle or it eats the
battery — and a wallet talking to it over local RPC has no way to know it is addressing a
sleeping node. The fix is not a better standalone app. It is the light client living
inside the wallet, where the host app knows about lifecycle and foreground and can tell
the user “reconnecting, give it a moment.” So the mobile track here is a working session
with wallet developers on a real unsolved design problem, not an install queue for
something that isn’t ready to be one. We would rather show attendees an honest edge than a
demo that works once on stage.
Why a hub, and not a talk or a workshop. A talk can explain that light clients exist. It
cannot get software onto a stranger’s laptop. Installs fail in specific, individual ways —
a Gatekeeper prompt, a firewall, an unfamiliar package manager, a network that filters UDP.
Each one takes a few minutes of one-to-one attention from someone who knows the software.
That is a support desk staffed over four days, not a session. It is also why the format has
to be persistent: people try, hit a wall, wander off to a talk, and come back. A hub lets
them come back.
How it complements Devcon 8 India. Two adjacent hubs are already proposed, and this one
is deliberately the third leg rather than a competitor:
- The P2P Networking Hub serves the people who build the networking layer — protocol
teardowns and cross-client debugging. We are downstream consumers of exactly that work,
and we would rather send traffic their way than duplicate it. - The Self-Custody & OpSec Hub serves the people who hold keys safely. We cover the
other half of the same user’s sovereignty: not the key path, but the data path.
We would actively cross-refer attendees to both, and would welcome joint sessions.
How it supports builders. Light client and node-software maintainers get something they
almost never have: a queue of real users installing their software on unfamiliar hardware,
in front of them, failing in ways no CI catches. That feedback loop is the single most
valuable thing this hub produces, and it runs in both directions.
Have we organized a hub before? This hub is a reframing of the Node Operators Hub, which
Jonathan Meyer ran at previous editions. He isn’t able to host this year and has been
generous with his input on the reframing. What we carry forward: the hardware showcase, the
walk-in support desk, the daily-theme structure. What we change: the centre of gravity moves
from staking to end-user access. Solo staking is well served by EthStaker and others,
whereas the mass-market user who should have a sovereignty-preserving connection to Ethereum
is unrepresented. Staking remains welcome, with emphasis on resource-constrained hardware
and distributed validator technology.
I have not run a Community Hub myself, which is a large part of why this is posted as a
convening call rather than a finished plan. Jonathan is advising on what the format actually
demands, and I would rather recruit people who have done it than discover the gap in
November.
Implementation
Production requirements:
- Wired ethernet at the demo tables — the single most important item. Everything
demonstrated here is peer-to-peer: discovery protocols need outbound UDP, and libp2p needs
sustained TCP connections. Conference wifi that filters UDP or applies aggressive NAT will
break live light-client demos in a way that misrepresents the technology and teaches
attendees the wrong lesson. Wired uplink with unrestricted outbound traffic is what makes
this hub demonstrable rather than theoretical. We are flagging this early as a hard
dependency rather than a preference, and we will test against hostile network conditions
before the event either way. - 4–6 tables with power, for hardware and laptop installs
- 1–2 screens for workshops and walkthroughs
- Microphone/PA for roundtables if the space is open-plan
What we will source ourselves: demonstration hardware brought by participating projects
(single-board computers and phones for the showcase), printed quick-start guides, and testnet
funds for attendees doing hands-on setup. Attendees install on their own laptops, so we are
not asking for or providing loaner machines.
Programming
Possible speakers and topics
Marked honestly: confirmed, interested, or invited-and-awaiting-reply. We would rather show
you the real state than a wish list presented as a line-up.
- CONFIRMED — “Install and use a light client as your local RPC service” (Dirk Jäckel,
Myotis). One or two runs of a practical workshop: get it onto your laptop, point a wallet
at it, and watch queries answered from your own machine instead of a provider’s. - INTERESTED — Colibri Stateless (Steffen Kux and team, corpus-core). Confirmed as
attending and keen to participate and contribute; sessions to be shaped together. - Two architectures for the same problem. Colibri and Myotis solve verified access in
genuinely different ways — Colibri is a stateless prover/verifier in portable C with
bindings for Swift, Kotlin, JS, Python, Dart and Rust, small enough to embed in a browser
or a phone app; Myotis is a node you run, that serves your wallet over local RPC. Which one
is right depends on whether you want to run something or embed something. Putting both
in a room and letting attendees compare them is more useful than either alone. - Running your own RPC — the implementations compared. Invitations going to Nimbus
(verified proxy), Helios, and Lodestar’s light client and prover, alongside the above. The
point is the capability, not any one project; attendees should leave knowing which fits
their machine and their tolerance for rough edges. - Who maintains the light client layer? — an honest panel with maintainers from across
those projects. Not “light clients are good,” but: why does this work keep getting
deprioritised, what does maintaining it actually cost, and what would it take for the layer
to have someone accountable for it? Portal’s reference client going unmaintained and
Lodestar’s light client moving out of the monorepo are both recent, and both worth
discussing in the open rather than around. - Wallet developers — a working session on embedding a light client as a data access
layer: lifecycle, battery, and what a wallet needs from the node it carries. Open
invitation to any Android or iOS wallet team at Devcon. - INTERESTED — Freedom Browser. Meinhard will be in Mumbai and the team are up for
participating; sessions to be shaped together. - NeoMist — sovereignty-preserving end-user tooling. Invited, awaiting reply.
- Ethereum on ARM — full nodes on constrained hardware. Invited, awaiting reply.
- Hands-off provisioning — booting a bare-metal machine into a running, reproducible
Ethereum node with no manual steps. Early work, and a thread we expect to have more to say
about closer to the event. - Obol, SSV — distributed validator technology
- The Portal gap — an open roundtable on what replaces Portal, and who maintains it
- India-based node operators and mobile developers — actively seeking, see Audience
Sample program (9:00–18:00, four days)
Each day pairs a themed morning with open afternoon clinic time, because installs need
unstructured support hours more than they need sessions.
| Day 1 — Access | Day 2 — Mobile | Day 3 — Infrastructure | Day 4 — Futures | |
|---|---|---|---|---|
| 09:00 | Welcome, orientation | Welcome, orientation | Welcome, orientation | Welcome, orientation |
| 10:00 | Talk: not your node, not your data | Working session: light clients inside wallets | Workshop: node on a single-board computer | Roundtable: what replaces Portal? |
| 11:00 | Install clinic | Install clinic | Install clinic | Install clinic |
| 13:00 | Lunch / open hours | Lunch / open hours | Lunch / open hours | Lunch / open hours |
| 14:00 | Workshop: laptop light client, start to finish | Panel: who maintains the light client layer? | Talk: staking on constrained hardware; DVT | Show and tell: what attendees got running |
| 15:30 | Install clinic + hardware showcase | Install clinic + hardware showcase | Install clinic + hardware showcase | Install clinic |
| 17:00 | Open roundtable | Open roundtable | Open roundtable | Closing + where to continue |
Programming is intended as a collaborative effort across participating communities. The
clinic blocks are the backbone; sessions are scheduled around them, not the other way round.
Alignment with Devcon’s focus
The hub is about Ethereum’s core properties as a lived experience rather than a slide.
Censorship resistance and privacy are abstract until you see that your wallet’s balance
query goes to a company that logs it — and then see the same query answered by software on
your own machine, verified against a sync-committee signature. Every project featured is
open source. Several are maintained by one or two unpaid people, which is itself part of the
story worth telling honestly.
Audience
Who it’s for. Anyone who uses Ethereum and hasn’t thought about where their data comes
from — deliberately the broadest possible audience, not only operators. Secondarily:
existing node operators, wallet developers who could embed a light client, and the
maintainers of that software.
No assumed expertise. The entry-level path is “bring your laptop, we’ll help you install
something,” and it needs no prior knowledge. The advanced path is protocol-level and runs in
the same room, which is the point.
Why this matters particularly in India. India is mobile-first at a scale that makes the
usual desktop-centric assumptions about running infrastructure fail. If sovereignty requires
a home server, it is a hobby for the wealthy. If it fits on the phone someone already owns
and tolerates intermittent connectivity and metered data, it is available to hundreds of
millions of people.
That is not yet where the software is, and we would rather say so here than discover it on
stage. The mobile path runs through wallets embedding a light client rather than users
installing a separate node app, and the constraints — battery, backgrounding, metered data —
bite hardest exactly where the need is greatest. Devcon 8 India is the right room in which to
work on that, in front of the developers and users best placed to say what it would take.
Connecting with India’s Ethereum and open-source community. The organising team is
currently based outside India, and we regard that as a gap to close before the event, not a
detail to manage. Concretely, we intend to:
- Recruit India-based co-hosts and bring them into the organising team, with the forum
thread kept active as the recruiting channel - Reach out to the Bhasha CROPS Community Hub organisers about multilingual support, so
install guides and clinic help are not English-only - Invite India-based node operators and mobile developers as speakers rather than only as
attendees
If you organise in India and any of this resonates, this is the most useful reply this
thread could get.
Team
Being straight about where this stands: the topic has a convenor, not yet a full organising
team. That is what this post is for.
Committed:
- Chris Hobcroft — independent, convenor. TG @chrishobcroft. I’ll bring the framing and the
argument, the introductions across light-client and node-software projects, the programme
design, and hands-on time during the event. What I am not offering is to run a
four-day hub single-handed — that takes people who have done it before, and doing it badly
would serve the topic worse than not doing it. - Dirk Jäckel — maintainer of Myotis, an independent sync-committee light client for
desktop, CLI, Android and iOS. Has agreed to run one or two workshops on installing and
using a light client as a local RPC service. Brings direct, current knowledge of what
breaks when a light client meets real hardware and real networks, including the parts that
don’t work yet. Attendance is not yet funded. - Steffen Kux and the Colibri team (corpus-core) — confirmed as attending Devcon and
interested in participating and contributing. Colibri Stateless is an MIT-licensed
prover/verifier for cryptographically verified Ethereum RPC, portable C with bindings for
mobile, browser and embedded targets. Specific sessions to be shaped together. - Jonathan Meyer — in conversation about advising on continuity with previous editions
and on what the format actually demands.
Sought — this is the ask:
- An operating lead or co-hosting organisation, ideally one that has run a hub or a
community space before, to own the floor across the four days. Previous editions of this
hub were run by organisations (EthStaker, Dappnode, Ethereum on ARM, SEED Org) rather than
individuals, and that is the right model. - India-based co-hosts, both for the operational reasons above and because a hub about
sovereign access to Ethereum in India should be shaped by people who live with those
constraints. Currently our most significant gap. - Participating projects and maintainers — light clients, node tooling, privacy-preserving
end-user software. - Wallet developers, particularly Android and iOS, for the mobile working session.
If you are interested in any of these, reply here — that is what this thread is for.
Why convene it at all? Because nobody else has, none of the twenty-odd hub topics
proposed so far covers this ground, the hub that came closest is not returning, and the
underlying problem is getting worse rather than better. I would rather post an honest
half-team and find the other half in public than let the topic go unrepresented at Devcon.
Neutrality. This is a prompt worth answering carefully, because the organising team
includes the maintainer of one of the projects the hub would feature.
- No commercial interests are represented. Myotis is Apache-2.0, independent, has no
token, no company, and no funding. The same is true of most software we intend to feature.
There is nothing here to sell, and no treasury that benefits from attention. - The hub is about a capability, not a product. The light client panel deliberately
spans Helios, Nimbus, Lodestar and Myotis. If an attendee leaves running someone else’s
client, the hub has succeeded exactly as much. - Structurally: any project featured must be open source, and any organiser with an
affiliation to a featured project will say so plainly when presenting it. We would rather
state affiliations out loud than pretend to a neutrality nobody has. - We will not accept sponsorship for hub content or placement.
Connection to the communities served. The node operator community through the previous
Node Operators Hub and its organisers; the light client maintainer community through direct
work with the implementations; the end-user community that this hub is ultimately for is the
one we are least connected to and most want to reach, which is why the India recruitment
above matters.
Languages. English only from the current organisers, with German available through Dirk.
This is a real limitation for an event in India and we are not going to dress it up: the
hub’s language coverage depends entirely on the co-hosts we recruit between now and November,
which is one of the main reasons we are recruiting them. We intend to approach the Bhasha
CROPS Community Hub organisers about collaborating on multilingual install guides and clinic
support.
Proposed for RFP-13: Devcon 8 India Community Hubs — as an intention and a call for
collaborators. If you have run a Community Hub before, if you organise in India, if you
maintain a light client or node tooling, or if you have tried to run a node on a phone and
given up: please reply. The topic needs a team more than it needs another draft.