Decentralised Devconnect: Swarm-Based Profiles and Forums for Attendees and Speakers

Devcon Improvement Proposals (DIPs)
1

Title: Decentralised Devconnect – A Swarm-Native App for Profiles and Forums

Authors: WoCo team (World Computer Foundation) – Written by Nabil Abbas (NTL) with contributions from the Swarm core team and Luke Martin (WoCo)

Resources Required:

  • Technical contact for the Devconnect app
  • Speaker onboarding coordination for profile setup
  • Optional: Table or small booth for showcasing and live support during the event
  • Optional: Devconnect team sets up a Bee node

:brain: What do you suggest?

We propose decentralising the user experience on the Devconnect app by hosting its core user features on Swarm – Ethereum’s decentralised storage layer.
This includes:

  • Swarm-hosted user profiles created using cryptographic signatures
  • Embedded message boards on session/talk pages and a general forum
  • Optional one-time email login for recovering a signature-based account
  • An interactive, decentralised speaker directory
  • Lightweight integration via modular npm packages or embeddable components

This proposal builds upon DIP-45 (Meerkat Q&A), which showcased the use of digital signatures, expanding on that by enabling persistent, signature-based profiles and content, stored immutably on Swarm – creating a self-sovereign user experience that lives beyond the event itself.

All content is censorship-resistant, verifiable by signature, and ultimately owned by the user.

:dart: Motivation & Rationale

We aim to extend the current Devconnect application by fully decentralising how attendees engage – with a focus on persistence, censorship resistance, and self-sovereign identity.

While Devconnect already uses decentralised elements, this proposal offers a more unified, Ethereum-native experience by hosting attendee profiles and discussions entirely on Swarm. A single user profile, linked to a cryptographic account, serves as the gateway to interacting across the app: from embedded forums to speaker bios.

This eliminates reliance on centralised servers and ensures all data is stored in a way that’s tamper-proof, user-verifiable, and persistent beyond the event itself.

DIP-45 proved the power of digital signatures using Zupass for Q&A and badges. Our proposal continues this line, using signatures to power content ownership and identity across the event UI.

Every profile (attendee or speaker) is updateable at any time and is tied to a unique Swarm hash, generated from deterministic inputs (public address + feed name), stored via Swarm Feeds / Single Owner Chunks (SOCs).

This provides:
• Long-term ownership of profiles and content
• Seamless access to embedded session forums
• An interactive speaker directory with decentralised credentials
• A truly persistent Devconnect experience - even after the event concludes

:hammer_and_wrench: Implementation

The MVP is currently in development and includes:

  • Swarm-hosted profiles, signed by users
  • Optional one-time email login tied to cryptographic accounts
  • Embedded forums powered by Swarm feeds or graffiti chunks
  • Gateway fallback for upload/download (prior to light clients)

Users who opt to use the platform-owned storage batch will receive a guaranteed Time To Live (e.g. 1 year). While this doesn’t give them full batch ownership, their content remains downloadable at any time. By default, users will have the option to connect with their own Bee node and storage batch, circumventing the centralised element.

We’re working closely with the Swarm core team to ensure performance, resilience, and timely delivery. Platforms like bchan already demonstrate forums on Swarm, with our proposal expanding this into a cohesive event layer focused on profiles and forums.

:gear: Operational Requirements & Ownership

Devconnect Collaboration

We’d work closely with the Devconnect team to define where forums and profiles will be embedded – for example, on session or speaker pages. These additions will not interfere with existing functionality or hosting workflows.

We will provide modular npm packages or embeddable components that add Swarm-based identity and forums to the existing application. This ensures minimal disruption while adding persistent, censorship-resistant, user-owned functionality.

Speaker Profiles

Speaker profiles follow the same process as attendee profiles. We recommend speakers create theirs ahead of the scheduled release – profiles are editable at any time and follow the same structure, using cryptographic signing.

On-site Ownership

The Woco team would be on-site and responsible for application uptime and troubleshooting. Swarm storage ensures minimal reliance on back-end services.

Ecosystem Integrations

Our stack is built with interoperability in mind. We’re actively exploring integrations with Meerkat (from DIP-45), which demonstrated badge and Q&A features using zk tech.

Swarm may also complement existing tools like PODs, especially around storing event badge metadata in a decentralised, tamper-proof way. This proposal is designed to interoperate with emerging standards, acting as a launchpad for future integrations.

:link: Links & Additional Information

Alternatives Considered

  • Federated or backend-based login systems – Introduce platform dependencies and shift control away from the user
  • IPFS-based hosting – While useful, IPFS lacks incentivisation and is not truly decentralised in practice, especially without long-term pinning or mutable feed support
  • Web2-style comment platforms – Rely on centralised databases and logins, failing to preserve user data or align with Ethereum’s decentralised ethos

Future Developments

App Frontend Hosted on Swarm

Following a successful rollout and demonstrated resilience of Swarm, we would propose that the Devcon/nect team consider hosting the app itself on Swarm. This would further showcase Ethereum-native infrastructure and reinforce a commitment to full decentralisation.

Swarm Light Clients

Once Swarm light clients are production-ready, all users can interact with Swarm directly, eliminating reliance on gateway infrastructure. This will allow for a fully interoperable and decentralised user experience, aligned with the broader vision of the World Computer.

2

Since my post above, I’ve been experimenting a bit more with PODs and have some questions about the current user flow on the Devcon app.

I exported my DC7 PODs from Zupass and uploaded them as an encrypted file to Swarm. I was then able to retrieve the file via its Swarm hash and render it using an adapted Zupass UI.

For anyone curious, here’s a link to a small prototype in my Swarm uploader that includes the POD Passport Viewer. You can try uploading a POD to Swarm and rendering it directly. After the upload, a button will appear to launch the viewer. Please note the app is very rough and intended for testing: GitHub - yea-80y/Swarm-Uploader: Swarm Uploader Website

One thing I haven’t been able to test, as I can’t log into the Devcon app, is what happens when a user logs in. Is the relevant POD automatically made available in the session/browser so they can respond to a GPC proof request to access Meerkat Q&A without additional steps? Or does the user still need to log into Zupass separately to get access?

If it’s the latter, I’m wondering how that worked for users who signed in with a Web3 account only – would they have been able to use the Meerkat Q&A feature without also providing an email login?

From previous DIPs, I understand that each ticket is associated with a POD. It would be great to know more about how that was handled in the Devcon app, especially in terms of how it linked with Zupass for different login types.

3

Some of the questions raised privately on Discord were whether our proposal would mean replacing existing integrations like Zupass and Meerkat, or altering the sign-in/ticketing flow. To be clear, it will not. This proposal is meant to slot in alongside and not replace any existing functionality. Users already have a profile created when they register/login with Devcon – we are simply expanding this with profile metadata and media. These will be stored on Swarm and integrated with a Swarm fetcher via a lightweight npm module (as proposed in our DIP) into the Devcon app for a true dweb experience. These Swarm-backed profiles then provide the foundation for session and speaker forums.

From digging into the Devcon and Devconnect app repos, we now know that the flow works as follows:

  • A user buys a ticket using either email/card or a crypto account, and a ticket POD is created.
  • When they log into Devcon, the ticket POD is not automatically injected into the app session.
  • To use features like Meerkat Q&A, they must still log in with Zupass, regardless of whether they used email or a wallet.
  • Only after that Zupass login is the POD made available for the GPC proof.

This means that Web3-only users who don’t want to use email are currently excluded from Q&A. To address this, we have opened meerkat-events/meerkat#15, proposing to trial an alternative path where Web3 users could use a ticket POD stored on Swarm as input to Meerkat’s existing proof flow.

Our approach keeps the app functioning exactly as it does today, while Swarm adds a decentralised layer that supports profiles and forums for all users. It also allows Web3-only users to access Meerkat Q&A with their ticket PODs on Swarm.