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.

:bullseye: 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.

5

DIP Update: Devcon 2026 — Decentralised Ticketing & Web3 Access Path

January 2026 Update

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

Summary

This update expands our original proposal with two additional offerings for Devcon November 2026:

  1. Decentralised Ticketing Infrastructure — Host ticket sales on Swarm, eliminating typical platform booking fees and removing reliance on centralised ticketing platforms.

  2. Alternative App Access Routes — Support three user types: Guest/Local (maximum privacy, upload ticket POD), Para wallet (email-based), and Web3 wallet (address-based). Each route retrieves the user’s ticket POD appropriately.

Both integrate with our existing profiles and forums proposal, using PODs as the verification layer. A working prototype demonstrating these capabilities is live at woco-net.com with source code available on GitHub.

Part 1: Decentralised Ticketing

The Problem

Centralised ticketing platforms typically charge booking fees (often $5-15 per ticket) and require email addresses, creating friction for privacy-conscious attendees and extracting value from the community.

Our Proposal

Replace the existing ticketing backend with a Swarm-hosted solution where:

  • Tickets are PODs — Each ticket is a cryptographically signed POD stored on Swarm
  • Non-extractive fee model — Cost-recovery fees only, with checkout infrastructure hosted on Swarm and no centralised intermediary
  • Privacy options — Users choose their identifier:
    • Email (traditional flow, ticket sent via email)
    • Web3 wallet address (ticket retrievable via deterministic Swarm feed)
    • Local download (for maximum privacy — user stores ticket themselves)

User Flow

Purchase:

  1. User selects ticket type and completes payment (crypto or card)
  2. User chooses identifier: email OR wallet address OR local download
  3. Ticket POD is created, signed by Devcon, and stored on Swarm
  4. For email users: link sent to retrieve ticket
  5. For wallet users: retrieved via the Devcon app (Feed: wallet address = topic)
  6. For local users: direct download of ticket POD

Event Entry:

  • QR code generated from ticket POD (works offline)
  • Staff scan QR → verify POD signature → admit attendee
  • Same UX as traditional ticketing, but decentralised backend

Part 2: Alternative Access Routes

The Problem

Currently, the Devcon app requires Para wallet login (email-based). This excludes:

  • Web3-native users who prefer wallet-only interaction
  • Privacy-conscious users who don’t want to provide any identifying information upfront

Our Proposal

Support three distinct user groups, each with appropriate access:

1. Guest / Local Account (Maximum Privacy)

  • User accesses app without logging in
  • A local browser account is created automatically (keypair stored in IndexedDB)
  • User can view public content
  • User can upload their locally-stored ticket POD to verify attendance and unlock full access
  • Ideal for privacy-conscious users who downloaded their ticket at purchase

2. Para Wallet User (Email-based)

  • User logs in with email via Para wallet
  • Email is used as the unique identifier to retrieve their ticket POD from Swarm
  • Full app access once ticket POD is loaded

3. Web3 Wallet User

  • User connects their Web3 wallet (MetaMask, etc.)
  • Wallet public address is used to retrieve their ticket POD from Swarm
  • Full app access once ticket POD is loaded

At checkout, users select their preferred app login method (email, wallet, or local download). This determines how their ticket POD is stored and retrieved. Para users must use email because we don’t know their Para wallet address at purchase time.

Account Capabilities

User Type Login Method Ticket Retrieval Capabilities
Guest/Local None (auto-created) Upload POD file View public content; full access after POD upload (single device)
Para Email Auto-loaded from Swarm Full access (cross-device via Para)
Web3 Wallet connect Auto-loaded from Swarm Full access (cross-device via wallet)

Technical Architecture

Key Derivation

All three user types follow the same pattern: ticket POD verification is the gateway to full app access. Only after verification can users create profiles, post to forums, and claim/create PODs.

Local/Guest Users:

Browser-generated Ethereum keypair (stored in IndexedDB)
    │
    ├─► Ticket POD uploaded manually by user
    │       └─► Verified? ─► Unlocks full access ↓
    │
    ├─► Profile Feed Topic ─► Deterministic Swarm feed for profile data
    │                         (avatar, nickname stored here)
    │
    ├─► EIP-712 Signature (fixed nonce) ─► Ed25519 POD Identity
    │                                       └─► Signs/claims PODs
    │
    └─► EIP-712 Signature (random nonce) ─► Forum Signing Key
                                            └─► Signs forum posts (privacy layer)

Para Users:

Para Wallet (email-based login)
    │
    ├─► Email ─► Deterministic Swarm topic ─► Ticket POD retrieval
    │                                          └─► Verified? ─► Unlocks full access ↓
    │
    ├─► Para public address ─► Profile Feed Topic
    │                          (avatar, nickname stored here)
    │
    ├─► EIP-712 Signature (fixed nonce) ─► Ed25519 POD Identity
    │                                       └─► Signs/claims PODs
    │
    └─► EIP-712 Signature (random nonce) ─► Forum Signing Key
                                            └─► Signs forum posts (privacy layer)

Web3 Users:

Ethereum Wallet (parent account)
    │
    ├─► Public address ─► Deterministic Swarm topic ─► Ticket POD retrieval
    │                                                   └─► Verified? ─► Unlocks full access ↓
    │
    ├─► Profile Feed Topic ─► Deterministic Swarm feed for profile data
    │                         (avatar, nickname stored here)
    │
    ├─► EIP-712 Signature (fixed nonce) ─► Ed25519 POD Identity
    │                                       └─► Signs/claims PODs
    │
    └─► EIP-712 Signature (random nonce) ─► Forum Signing Key
                                            └─► Signs forum posts (privacy layer)

Client-side identity derivation:
The deterministic Ed25519 POD identity is derived and used strictly client-side. The fixed-nonce EIP-712 signature used for derivation is never transmitted, stored, or shared with any backend. Only short-lived, random-nonce signatures are shared with the backend when required for session or capability issuance.

This separation ensures:

  • Profile is tied to parent account (deterministic feed retrieval)
  • POD identity is deterministic (same parent account = same Ed25519 key across devices)
  • Forum posts use a separate signing key (doesn’t expose parent account)
  • No private keys stored server-side
  • Local users have full functionality but lose cross-device access if they clear browser storage

What We’ve Built

Our prototype demonstrates:

  • Three login routes: Guest/Local, Para (email), and Web3 wallet
  • Ticket POD upload and verification for local users
  • Swarm-hosted profiles with avatar upload
  • Decentralised forum with board/thread structure
  • POD collectibles (create, claim, view collection)
  • Deterministic Ed25519 derivation via EIP-712
  • Separate forum signing key, cryptographically bound to the parent account

Live Demo: gateway.woco-net.com/bzz/…

Source Code: github.com/yea-80y/DevConnect-Profile-Forum-Sandbox

Integration Path

For Devcon Team

Ticketing:

  • Confirm required user data at purchase time (e.g. email, wallet address, or none for local download) and any regulatory or operational constraints
  • Provide ticket schema requirements
  • Coordinate payment integration (existing crypto AND fiat/card payment infrastructure can be reused)
  • Define check-in verification requirements

App Integration:

  • Add “Connect Wallet” option alongside Para login
  • Add Guest/Local mode with POD upload UI
  • Integrate lightweight npm modules for Swarm profile/forum fetching
  • Endpoint for ticket POD issuance (we provide tooling)

Relationship to October Update

This update builds on Options A, B, and C from our October post:

  • Option A (ForumKey Attestation) described how forum posts are signed and verified — this remains the foundation for our forum implementation
  • Option B (POD Vault) proposed Swarm storage for ticket PODs with email OTP access — the ticketing proposal extends this to the full purchase flow
  • Option C (Wallet-based PODs) proposed wallet-bound credentials — this update provides the full wallet login path we outlined there

Current Limitations

To be transparent about remaining work:

  • Gateway dependency — Until Swarm light clients ship, we rely on gateway infrastructure for uploads/downloads
  • Backend API — Some claim logic requires server-side coordination (working to decentralise). Where backend coordination is used, it is limited to challenge-response authorisation and does not custody user keys or identity material.
  • No GPC proofs yet — PODs are verified by signature, not ZK proofs (compatible for future upgrade)
  • Zupass integration incomplete — We have Parcnet connection code but need clarification from the Zupass team on iframe/popup behaviour and POD query patterns

Optional Enhancements

These ideas could add value but are not core to the proposal. We include them for discussion:

Attendee-Created POD Contact Cards
Attendees could create their own PODs as digital contact cards that others can claim. This forms a collection of networked individuals — essentially the start of a decentralised contacts list built during the event. Demonstrates user-created PODs beyond platform-issued tickets.

Fee Savings Redirect
Any savings from eliminating platform fees could be:

  • Returned to attendees as event crypto (spendable at local vendors)
  • Used for community quests and challenges
  • Routed directly into the local community

Meerkat Q&A Integration
Ticket PODs stored on Swarm could potentially be used as input to Meerkat’s GPC proof flow, enabling Web3-only users to participate in Q&A without email authentication. We’ve opened GitHub Issue #15 to explore this with the Meerkat team.

Zupass Import
Allow users to import existing PODs from Zupass into their WoCo account and store them on Swarm. This provides backup/portability for POD collections.

Next Steps

We’re seeking:

  1. Technical review of our prototype by the Devcon team
  2. Feedback on ticketing requirements and constraints
  3. Collaboration on integration timeline for November 2026

Links

1 Like
6

WoCo - Devcon DIP Update (March 2026)

As with previous updates, everything described here is designed to sit alongside existing Devcon infrastructure - Zupass, Meerkat, and the Devcon app itself, not to replace any of it. This update focuses on where the WoCo platform stands today and how a practical Devcon integration could work.

For organisers using the WoCo app directly (woco.eth.limo)

Organisers can create free events on the WoCo platform today. Attendees can claim tickets using a web3 wallet (including Para, which requires only an email address and no browser extension), passkey, or via traditional email - rate-limited and relayed through the organiser’s own chosen email delivery service via outbound webhooks configured in the dashboard. The organiser selects which claim methods to enable per event, along with any required or optional attendee information to capture at claim time.

Events can be gated: the organiser can require manual approval of each attendee through the dashboard before a ticket is issued. Created events can also be embedded into any web page using a provided snippet (<woco-tickets>), enabling wallet and email claims inline - without attendees needing to visit the WoCo app directly.

For organisers who want a standalone event site

Alongside events hosted on WoCo, organisers can build and deploy their own event page - either using WoCo’s backend (feed signer + Swarm storage batch) or by deploying the open-source backend on their own infrastructure. The WoCo app provides a five-step guided setup: the organiser inputs their backend API URL, the app verifies the connection (checks Bee node health, postage batch validity, signer config), creates the event on their server, generates the required environment config, and produces a ready-to-deploy frontend build. They can customise attendee questions and integrate their existing payment system by embedding a payment redirect URL per ticket tier. As part of the build configuration, the organiser specifies a Swarm gateway URL which is baked into the frontend - currently a necessary step while Swarm light clients are still in development. Organisers can use their own gateway if they have one, or use any publicly available gateway. The final step uploads the built site to Swarm and returns the content hash, which the organiser uses to update their ENS record and serve the site at their own domain (e.g. event.devcon.eth.limo).

Proposed Devcon integration

For Devcon, we propose the team deploy the event as a static frontend on Swarm (integrated with their existing payment infrastructure) enabling attendees to associate their web3 wallet or Para account with their ticket rather than relying solely on email. Tickets are issued as PODs, signed by the team’s ed25519 account key, consistent with how previous Devcon credentials have been managed. Attendee information is encrypted client-side using the organiser’s ed25519 public key (ECIES: X25519 + AES-256-GCM) before being written to Swarm, meaning only the Devcon team can decrypt order data - no third party has access. Working together with the team, we can accommodate specific UX requirements, such as issuing tickets immediately at checkout or at a later date in a separate phase.

A full architecture diagram for the platform is available here: WoCo Events Architecture (PDF)

Towards a registry of trusted event frontends

One conversation we would like to start with the EF and Devcon team is around establishing an open registry of trusted event frontends. The problem it solves is real: as frontends move to decentralised hosting, there is no standard way for users to verify that the frontend they are interacting with is the genuine published one. A registry - whether on-chain, on Swarm, or some combination, would allow any frontend to be independently verified against a signed record, protecting attendees from phishing clones. We see Devcon as the natural place to start this conversation and potentially establish the first entries in such a registry. The implementation details, governance model, and who maintains it are all open questions - but we believe working through these with the EF would be a genuinely valuable contribution to the broader ecosystem, well beyond WoCo itself.

Try it now

The app is live at woco.eth.limo. If you’d like to test the event site builder without setting up your own backend server, you can use WoCo’s API URL: https://events-api.woco-net.com - at step 2 of the setup wizard. We welcome any feedback.