DIP | Title | Status | Themes | Instances | Tags | Authors | Resources Required | Discussion | Created |
---|---|---|---|---|---|---|---|---|---|
31 |
PCD-based ticketing for Co-working space and other events at Devconnect |
Accepted |
Ticketing, Social, Purchases & ID, Community Involvement, |
DevconnectIST |
Event Production, Software |
ivan@0xparc.org |
Operations support |
2023-08-08 |
We propose to issue Devconnect co-working space tickets as PCDs, which would enable attendees to plug into a a structured network of ZKP-friendly data. If tickets are issued as proof-carrying data, Devconnect builders and community members will be generate cryptographic proofs about their activity at Devconnect that can be ported across other community platforms—event host websites, Telegram channels, and more.
Currently, tickets are sold, distributed, and checked at the door using Pretix. We propose modifying the ticket distribution and checkin part of the process to make use of Zupass rather than Pretix. Zupass is a flexible, open-source, E2E encrypted storage mechanism for ZK-friendly data (PCDs)—data that you can make cryptographic proofs about. After purchasing a co-working space ticket via Pretix, an attendee would be able to access their cryptographic 'PCD' ticket via Zupass, and event staff would be able to check attendees in at the door via Zupass. By issuing tickets as PCDs, event attendees would be empowered to use their tickets later on to access additional services, and builders at events would be able to build applications or community infrastructure gated to event attendees.
Zupass is a cryptographic secret manager that lets users store, generate, verify, and share PCDs, currently implemented as a web application hosted on zupass.org.
PCD stands for 'proof carrying data', and refers to a category of data that is 'proof-carrying', or 'self-evident'. The core idea of PCD is that it is information that does not need any external context to be able to be verified by anybody to be true. The way PCDs can be independently verified to be true is by using cryptography, typically either a digital signature or zero knowledge proof. One example of a PCD is an ECDSA-signed Ethereum transaction. Another example of a PCD - and this is what we are proposing to implement - would be a cryptographic signature of some data representing a ticket to the co-working space of Devconnect. A 'ticket PCD'.
Zupass is a user's window into a world of applications and experiences that produce and consume PCDs. One way to 'consume' a Devconnect co-working space ticket PCD is to get 'checked into' an event (like the co-working space) by event staff. Once checked in, attendees wouldn't lose access to their PCD - it remains in their Zupass, ready to be 'consumed' in other ways. As a result, Devconnect co-working space attendees would be empowered to use their ticket later on however they want.
Another way to 'consume' a co-working space ticket PCD to gate access to unofficial websites to just Devconnect attendees. Another thing someone could do is develop their own event check-in flow, which could be used at another in-person event restricted to just attendees of Devconnect. Someone else could develop an on-chain smart contract that consumes these Devconnect ticket PCDs and issues commemorative NFTs to event attendees.
We distilled the concept of PCD from our experience building and supporting the development of many different cryptography primitives and cryptography-enabled applications. The R&D process made it clear that we are missing many abstractions and infrastructure that would be necessary to bring our cryptography applications to production.
Although Zupass doesn't (yet) make use of blockchain, it is nevertheless a 'crypto' project.
At the most basic level, it is uniquely enabled by modern cryptography in the same way that blockchain is enabled by modern cryptography.
At a more abstract level, the reason blockchain resonates with people in the crypto community isn't specifically the particular implementation details of 'the blockchain', but rather the philosophy and values that blockchain propagates. In particular, we believe that the values of open-source, decentralization, self-sovereignty, and permissionlessness (among many others) are at the heart of the crypto community.
Zupass aims to uphold these values by being an open-source project that gives people ownership over their data so that they can use the data in precisely the ways they want. Furthermore, the PCD Team is developing not just Zupass and other software abstractions, but also an ecosystem of developers who build applications that plug into the PCD abstraction. These applications, by virtue of being developed on top of the PCD abstraction, further propagate these values by empowering users in a way that respects their sovereignty and privacy.
- Has any part of this proposal been implemented at other events? If so, please describe how it went.
We have deployed Zupass at Zuzalu. At Zuzalu, Zupass was the primary method of digital and physical authentication. It was used daily to access gated physical event spaces and venues via a QR code and also to authenticate into online digital experiences via an OAuth-like integration flow. For example, event participants could login to the official Zuzalu website using their ticket held in their Zupass, much like one is able to login to the Devcon forum using their Google account. Once logged in, participants were granted access to a private portion of the website - the Zuzalu schedule, where they could view and edit Zuzalu sub-events. 100% of all Zuzalu residents (~200 users) and Zuzalu visitors (~600 users) onboarded onto Zupass, and used it daily for ZK-based digital and physical authentication over the course of two months.
We designed Zupass with ecosystem development in mind, and seeded/facilitated other identity and community experiments on top of the infrastructure that we built. Here’s a list of some of the projects that emerged on top of/alongside Zupass:
- Zupoll (https://zupoll.org/ 4) - an anonymous voting platform restricted to just Zuzalu participants, where residents could create straw polls, and organizers could create referendums. One notable use-case for these polls was as a way to measure the community’s sentiment towards Zuzalu and its programming during weekly in-person “town halls.” These official community referendums regularly drew 30%+ voter turnout across all Zuzalu residents.
- Zucast (https://zuca.st/ 2) - an anonymous farcaster-like forum. This was built in a week during Zuzalu by a community member that wanted to experiment with the affordances of anonymous social media. Zuzalu community members made nearly 700 posts over 3 weeks.
- Rubber Ducky - a telegram bot built and maintained by a community member that used GPT-4 to answer questions about Zuzalu. It used Zupass anonymous login to restrict its usage to just Zuzalu participants.
- PCD Stamps - a NFC-based PCD distribution mechanism that allowed community members to distribute POAP-type attestations to attendees of Zuzalu.
- Do you require feedback or data from attendees post-event?
Yes. We can collect additional feedback using the Zupass web application as well.
- What actions are required to implement the proposal at Devcon?
- Develop an integration between Pretix and Zupass so that tickets purchased on Pretix can be issued as PCDs via Zupass.
- Develop a ticket checkin flow so that event staff can check people in on-site.
- Test the end-to-end ticketing flow, from purchase to issuance to check-in to ensure it meets the standards of Devconnect event organizers.
- Who will be responsible for the proposal to be implemented effectively? (i.e. working on Day 0)
The PCD Team of 0xPARC is responsible for developing, testing, and deploying this project. The Devconnect organizing team is responsible for implementing the operational changes both at event-sale time and on-site at the event to make use of Zupass.
- What other projects could this proposal be integrated with? (Bonus points for collaboration across teams :))
We include a technical specification of the design of our ticketing system.
In order to understand how Zupass integrates with Pretix, it is important to understand the Pretix data model. Under the hood, Zupass reads event and ticketing information from Pretix, and converts that information into PCD-based tickets.
The data model of Pretix is as follows:
Instance
: Pretix can be self-hosted, or you can use it as a SASS. “Instance” refers to the entire Pretix application stack - web server, database, etc. required to run Pretix, whether it is run by the event host, or by Pretix itself.Organizer
: An organizer is effectively the ‘account’ on Pretix which an event host is able to configure to suit their particular event ticketing needs.Event
: anOrganizer
can have many events.Event
s have a start date, end date, location, etc.Product
: eachEvent
has its own set ofProduct
s that it can offer.Product
refers to an individual purchasable item in the context of that particularEvent
.Product
s are highly configurable. They can have quotas, questions that must be answered at purchase-time, etc.- Examples of
Product
s would be: a GA ticket to the event, a Student ticket to the event, a ‘t-shirt’, a piece of memorabilia like a commemorative booklet.
Question
: eachProduct
can have multipleQuestion
s that can be answered by purchasers.Question
s can be required or optional. Two important questions are the purchaser’s name and email.Shop
: EachEvent
has a web-interface through which prospective event attendees can purchase one or moreProducts
via a web interface. Attendees can pay at theShop
, as Pretix offers a Stripe integration. TheShop
enforcesEvent
configuration, such as quotas. It also ensures that attendees answers the requiredQuestion
s for eachProduct
sold in theShop
, and gives attendees the opportunity to answer optionalQuestion
s as well.Order
: Each time a person purchases one or moreProduct
s via the PretixShop
for a particularEvent
, their entire purchase is represented by anOrder
. AnOrder
can have multiple purchasedProduct
s.Position
: A purchasedProduct
within anOrder
is represented by aPosition
, which can be thought of as an ‘instance of anProduct
’.
In order to offer tickets to events, a host must set up their Organizer
, Event
s and Product
s for each event they want to sell tickets to. Pretix is quite flexible, and there are may correct ways to set up a Pretix Organizer
.
However, in order for Zupass to be able to issue PCD-based tickets to event attendees, there are a few specific configuration options that must be set up correctly.
The following configuration options must be set up for each Event
and Product
that an event host wants Zupass to be able to issue PCD-based tickets for:
-
Event
configuration options:-
Under ‘General’, in ‘Customer and attendee data’ section, in the ‘Attendee Data (once per personalized ticket)’ subsection, the ‘Ask for email addresses per ticket’ option must be set to ‘Ask and require input’. This is very important!
-
Under ‘Tickets’, in the ‘Ticket Download’ section, in the ‘Download settings’ subsection, the ‘Allow users to download tickets’ checkbox must be unchecked. This is important, as in the case that it is unchecked, attendees would be able to have two different tickets - a Pretix-implemented ticket, and a PCDpass ticket, which would cause confusion for attendees.
-
-
Product
configuration options:- Under ‘General’, the ‘Personalization’ option must be set to ‘Personalized Ticket’. This is important because it enforces that each
Position
has a corresponding email address, which is how PCDpass distinguishes between tickets internally.
- Under ‘General’, the ‘Personalization’ option must be set to ‘Personalized Ticket’. This is important because it enforces that each
If Pretix is not set up with the above configuration options, Zupass will not sync ticket information, and not issue PCD-based tickets to attendees of those events.
In order for Zupass to sync event and ticket information from Pretix, we need to collect some configuration information for each Organizer
(which can have many Event
s and Product
s).
Zupass does not issue PCD-based tickets to attendees for Event
s and Product
s that have not been explicitly configured with the PCD Team.
organizer_url
- a unique identifier that refers to a collection ofEvents
and configuration options controlled by the event host.organizer_token
- an API key (maintained by Pretix per-organizer) that gives web API to Zupass, enabling it to send web requests to Pretix to download information aboutOrganizer
s,Event
s,Products
s,Order
s andPosition
s.- You can find instructions for how to get a token here: https://docs.pretix.eu/en/latest/api/tokenauth.html#rest-tokenauth
- In order to sync properly, an event organizer (human) must inform us of the
Events
andProducts
that Zupass should be aware of. For each event, we need to know:- its
event_id
- its
Product
s that Zupass should interpret to be tickets. Under the hood, aProduct
can also be referred to as an ‘Item’, and eachProduct
has a uniqueitem_id
. Thus, in order for Zupass to sync the correct tickets, for each event, we need to know the list of item ids (active_item_ids
) - ids ofProduct
s that should be interpreted as tickets.
- its
- In order to allow users to be checked in, some Zupass users need to be identified as
Superuser
s, which would grant them permission to check people in. At the time that anEvent
is being onboarded to the Zupass product, we would ask the event host to provide a list ofProduct
s that should be grantedSuperuser
permissions. This means that allSuperuser
s have a ticket to the event on their Zupass, and must be logged into the email address to which thisSuperuser
ticket was issued in order to check in attendees to that event.
In order to be able to issue PCD-based tickets to event attendees, Zupass needs to be aware of the Organizer
, Event
s, and Product
s that live in Pretix. Thus, we have developed a syncing mechanism that downloads state from Pretix and saves it to our own database in our own data format.
Internally, we refer to an individual ticket to an event as a Pretix Ticket
. A more explicit definition of Pretix Ticket
can be found in the description of the algorithm by which we sync an Organizer
into Zupass.
- A ticket can either be
Soft Deleted
or not.
The sync algorithm is as follows:
- For each
Organizer
that has been configured, and for eachEvent
that has been specified as relevant, we download theEvent
metadata.- For each
Event
, we download its name, which I will refer to as itsevent_name
. - For each
Product
within eachEvent
that Zupass understands to be a ticketProduct
, as identified by thatEvent
'sactive_item_ids
, we sync thatProduct
's name, which I will refer to as itsitem_name
.
- For each
- For each
Event
, we download all theOrder
s. - For each
Order
, we extract thePosition
s. - We record each
Position
as aPretix Ticket
in our system. - The sync algorithm is robust to
Order
s andPosition
s changing.- In the case that an
Order
containing thePosition
that caused us to record aPretix Ticket
is cancelled or deleted, we record thePretix Ticket
asSoft Deleted
. - In the case that the
Position
that caused us to record aPretix Ticket
is cancelled or deleted, we record thePretix Ticket
asSoft Deleted
. - In the case that we encounter one or more
Position
s that translated to aPretix Ticket
that isSoft Deleted
, we make thatPretix Ticket
notSoft Deleted
.
- In the case that an
- The sync algorithm is robust to to
Event
s andProduct
s being renamed. - The sync algorithm is robust to
Event
s andProduct
s being deleted.- In the case that an
Event
orProduct
no longer exists, we cancel the sync so that existingPretix Ticket
s are not changed. Fixing this state requires manual intervention by the PCD Team.
- In the case that an
- Each ticket's check-in status is synced between Zupass and Pretix, such that the latest state is in sync between the two systems of record.
- Once a user logs into Zupass using their email, their Zupass makes a web request to the Zupass server (which is responsible for syncing ticket information from Pretix, and issuing PCD-based tickets), to ask for the PCD-based tickets that they have purchased. The server responds with a list of
Ticket PCD
s that are then added to the user’s Zupass. - A
Ticket PCD
is represented by anEdDSATicketPCD
- which is a PCD that contains the information in its correspondingPretix Ticket
, signed by the Zupass server’s RSA private key.- The reason we use
EdDSA
is that it is a SNARK-friendly signature algorithm, which enables users to performantly compute zero-knowledge statements about theirTicket PCD
s.
- The reason we use
- Each
Ticket PCD
contains the following information:email
- which corresponds to the answer to the ‘attendee email’ question entered by the attendee at purchase-time on the PretixShop
.event_name
- corresponds to the name of theEvent
in Pretix.ticket_name
- corresponds to the name of theProduct
that was purchased (and thus added as aPosition
within someOrder
in Pretix) by the attendee.timestamp
- the timestamp at which theTicket PCD
was signed and issued by the Zupass server to the user.ticket_id
- the unique identifier internal to Zupass corresponding to thePretix Ticket
from which theTicket PCD
was generated.
- Given that
Order
s andPosition
s can be updated by event hosts in Pretix manually, which causes our internal representation ofPretix Ticket
s to be updated, the information in aTicket PCD
can become out of date. Thus, the Zupass client will periodically re-download theTicket PCD
s that have been issued to its user’s email address, in order to keep them up to date with the state in Pretix. This means that:- Whenever an event host changes an
Event
name that Zupass is tracking via the Pretix web interface or API, the information in the user’sTicket PCD
will eventually reflect the correctEvent
name. - Similarly, whenever the name of a
Product
changes, it will eventually end up being reflected in the user’sTicket PCD
.
- Whenever an event host changes an
To check into an event, a Zupass user will need to have logged into Zupass with the email they used to purchase their tickets, or the email that was entered on their behalf by someone else who purchased a ticket for them.
After logging in, as mentioned earlier, the Zupass user will have access to all of their Ticket PCD
s.
To checkin to an Event
, the Zupass user would have to navigate to the Ticket PCD
in their Zupass that corresponds to a ticket for that Event
, and show that Ticket PCD
's QR code to the Superuser
in charge of checking people into the event.
To start checking attendees into the Event
, the Superuser
must have signed into Zupass using the email address to which a ticket with Superuser
permissions was issued..
To check in an attendee, the Superuser
would scan the attendee’s Ticket PCD
QR code (which contains the Ticket PCD
) using their logged-in Zupass. This action sends a request to the Zupass server to determine whether the Ticket PCD
was actually issued, whether it was revoked, and whether it has already been used to check in.
Each Ticket PCD
can only be used once to checkin to an Event
.
To revoke a ticket within Zupass, an event host has several options:
- Mark the
Order
that contains thePosition
which that corresponds to theTicket PCD
that the event host wants to cancel asCancelled
. This option is not ideal because this would would also revoke all the otherTicket PCD
s corresponding to the rest of thePosition
s in that order.- Another option is to delete the
Order
.
- Another option is to delete the
- Mark the
Position
corresponding to theTicket PCD
that the event host wants to cancel asCancelled
.- Another option is to delete the
Position
from the order
- Another option is to delete the
All of the above options cause an existing Pretix Ticket
in the Zupass system to end up in the Soft Deleted
state, which effectively revokes the ticket, and prevents it from being used to check in to physical events.