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.

4

Options for Integration (Profiles & Forums)

We propose three complementary paths that the Devconnect team can adopt independently or in combination. Each preserves the existing app or website while adding a layer of decentralisation without disrupting the user experience.

Option A, as outlined in the original DIP, can be integrated through small npm packages we provide – including the profile UI, forum widget, and verification helpers. Implementation details and documentation are available in the project’s GitHub repository and /docs folder.

Option A — Zupass ID + ForumKey Attestation

Summary
Users post with a short ForumKey-Attestation POD issued by Devconnect, which links their Zupass identity to a newly generated forum signing key. The attestation is bound to each post (inline JSON), allowing any client to verify authenticity without backend calls or external state. Users may also create a profile (picture + nickname) that serves as their visual alias on the forum.

Flow

  1. User connects Zupass in the Devconnect app → the public Zupass identifier is read.

  2. Client generates a forum keypair (ephemeral or persistent).

  3. App requests an issuer-signed ForumKey-Attestation from Devconnect, binding { zupassPublicId ↔ forumPublicKey }.

  4. Each post includes { payload, forumSig, forumPubKey, forumKeyAttestation }.

  5. Readers verify (a) the issuer signature on the attestation, (b) that the attestation binds to forumPubKey, and (c) that forumSig covers the payload

Storage
Optionally, the attestation can also be uploaded to Swarm and referenced by hash in later posts to reduce payload size while remaining verifiable offline.

Bee Gateway

Ahead of the rollout of Swarm light clients, we have deployed a Bee gateway that enables users to seamlessly upload and download content to and from Swarm through a public interface. This gateway underpins the prototype version of the Devconnect Profiles & Forums app, available at https://www.woco.eth.limo.
(Please note: the new app will go live later this evening - the current link may still load the previous website.)

Option B — Devcon POD Vault on Swarm (Email OTP Access)

Summary
Modernise the existing “Manual POD Backup” link from the recent Devcon 7 emails by routing users to a new POD Vault UI – a static HTML/JS page (which can itself be hosted on Swarm) The Vault introduces a short email OTP step and then fetches the user’s ticket POD directly from Swarm when they click to download. To avoid exposing email addresses, the backend derives a private Swarm topic using an HMAC of the user’s email – never the raw email. Uploads to Swarm are encrypted and signed by the feed signer’s private key, ensuring both confidentiality and verifiable authenticity of each stored POD.

Deriving the private topic

topic = keccak256("devcon7:ticket:v1:" || HMAC_SHA256(K_server, lower(email)))

  • Only the server performs this derivation; the client never sees the email or HMAC key.

  • Using HMAC with a server secret prevents topic guessing.

Vault UI flow

  1. Email link now points to https://devconnect.org/vault?token= (no email in the URL).

  2. User enters the OTP → UI calls /topic to request the derived topic.

  3. UI fetches the POD from Swarm (feed lookup → BZZ ref → GET).

  4. The same viewer layout used in the current ticket POD download is displayed.

  5. The Download button retrieves the POD from Swarm – no backend database needed.

At-rest protection (optional but recommended)
Each POD can be encrypted before upload with a per-user key derived alongside the topic:

userKey = HKDF(HMAC_SHA256(K_server, lower(email)), "devcon7:ticket:v1")

ciphertext = AEAD_Encrypt(userKey, POD, aad=topic)

On OTP success, the server issues a short-lived token that lets the UI fetch and decrypt client-side (or returns a wrapped key). This keeps storage private even if topics were enumerated. The Devcon team could then safely delete the original ticket PODs from their servers once the Swarm upload is complete.

Perks Page Improvement
On devconnect.org/perks, add an “Upload local POD” button beside the existing Zupass flow. Users who previously downloaded their ticket POD can upload it to claim discounts or perks — no Zupass sign-in required.
(This enhancement belongs on the Perks UI, not in the Vault itself.)

Why this helps

  • Removes plaintext emails from links.

  • Uses Swarm as the durable, portable store instead of a central database.

  • Allows the Devcon team to retire server-side copies after migration to Swarm.

  • Let users recover their POD even if they lose Zupass access.

PODs on Swarm

In August, we uploaded a DC7 collection of PODs (exported from Zupass) to Swarm and successfully downloaded and rendered with a POD viewer. It demonstrated that Swarm can be used to store PODs – GitHub repo.

Option C — Wallet-Based PODs

Summary
Beyond Zupass credentials, Devconnect and Devcon issuers could optionally support wallet-bound PODs (e.g. EIP-712 attestations) allowing Web3 users to collect and present credentials directly from their Ethereum wallets.

Implementation

  • Issuers: add a wallet-address issuance route alongside Zupass (no change to existing flows).

  • Verifiers: accept PODs from multiple trusted issuers/sources (Zupass and wallet-bound). The Meerkat team have confirmed they can accept PODs from other sources, so this can be explored collaboratively (GitHub Issue #15).

  • Long-term: enables users to collect future credentials (talk badges, attendee PODs) directly in their wallet, improving portability across events.

Next Steps

  • Option A → Devconnect team to expose an /issue/forum-attestation endpoint.

  • Option B → one-time upload of Devcon 7 ticket PODs to Swarm + simple OTP API.

  • Option C → joint discussion with issuer teams on adding wallet-bound issuance.