# Jubmojis @ Zu/Devconnect

At Devconnect Instanbul, the Privacy & Scaling Explorations team launched [Jubmojis](https://jubmoji.quest), a way for humans to connect with each other and the world around them by tapping NFC cards. Cards would give digital signatures (Jubmojis) upon being tapped on, and users could collect these signatures in a self-sovereign manner and generate privacy preserving proofs about the Jubmojis they've gathered. Here are some reflections on the Jubmojis project from start (I'm going to ignore previous iterations in this retro i.e. Sigmojis) to Devconnect activation, mainly centered around 1) the technological development process 2) the operational aspects of the activation itself 3) the general theses around giving people a UX friendly way to experience data ownership and enriching the physical world with verifiable attestations of people, places, and interactions.

## High Level Reflections
Some context on the project - the first commit to the jubmoji.quest [repo](https://github.com/jubmoji/jubmoji.quest) occurred on October 4, 2023. Zuconnect began on October 29, and Devconnect on November 13. Given these time constraints, I would say this project was a great success. We pushed out a functional, well-designed app and managed to organize an activation that received >1000 interactions. We put ourselves in a great position to accrue learnings from the activation and all the other user testing that happened throughout the events. Many processes (or lack thereof) were not very well thoughout, and we frequently scrambled things together last minute, but this is acceptable given the time frame. At a high level, I think we validated one of our hypotheses, which is that it is possible for users to experience self-sovereign data ownership with marginal UX overhead. In fact, in many cases most users did not even realize their Jubmojis were stored entirely client-side. On the flipside, one major hypothesis which remains a question mark is why users would want to own Jubmojis in the first place. I'm not going to beat around the bush since this is the biggest question and it's very important to be honest here, but we haven't found a sticky use case for Jubmojis outside of per-event activations. Plus, even if Jubmojis were useful, the fact that most people didn't realize they were self-custodied and most data was held private means users would probably have had the same experience if we just did everything server side. So how can we reflect data ownership and privacy preserving technology in a user experience? This is ok, these questions should be hard to answer.

## Tech Process
Overall the tech process was good, we had a few hiccups here and there but the technology accomplished its main goals:
1) provide a functional, smooth app where users could have meaningful thoughts about the product
2) be flexible enough to rapidly iterate on user feedback and make improvements/build new features for testing
3) demonstrate that the technology actually works, mainly babyjubjub-ecdsa signature generation on a NFC smartcard and zero knowledge proving on a mobile browser

Here is what I think we did right:
- **human driven technology process** - we had a design-first mentality, meaning we would ask users for their opinions and feelings **before** building anything. We had our own opinions and direction of course, but we were guided by user feedback, which made it a lot easier to build something that people genuinely wanted to use
- **build the hard stuff first** - i think the one thing that could have completely blown up on the tech side was if zk proving just did not work for whatever reason (or if the nfc cards didn't work, but I have less context on that front). we weren't doing anything crazy, but it still was new, namely verifying babyjubjub *ECDSA* in a zero knowledge proof. the thing we did right was to spend a good amount of time implementing and testing [babyjubjub-ecdsa](https://github.com/jubmoji/babyjubjub-ecdsa/tree/main) before building jubmoji.quest. it was a huge relief to just be able to use zero knowledge proving and verification out of the box and have it just work
- **build the minimum set of features necessary to test a hypothesis** - a short bit of context: cardholders were the people who actually held NFC cards. they were mostly selected as friends/people who were interested in this project. cardholders could create quests, which were challenges that asked users to collect Jubmojis from certain cards to get rewards, unlock access to an event, etc. crucially, we did not open up a programmatic endpoint for cardholders to create their own quests, but rather when a cardholder wanted to create a quest they just came and talked to us. i think this was absolutely the right thing to do given our constraints - creating a quest is not a simple operation, you have to configure which cards you want in the quest, what type of proofs users need to make about the cards, etc. in fact, we didn't even know if quests was the right abstraction to begin with, we just wanted to test if cardholders would care about creating their own challenges for users to collect Jubmojis from the cards. we saved a good chunk of our limited time by not exposing this endpoint and instead just talking to our cardholders about quest creation, which tested our hypothesis just as effectively. in addition, we actually gain from not exposing an endpoint because this gave us an excuse to have persistent conversations with our most avid cardholders, and through these we learned a lot more about their experience with the cards than we would have otherwise
- **build for flexibility, not for abstractions** - one of the greatest strengths we had on the technology front was our ability to take user feedback, come up with a meaningful hypothesis to test, and implement it in production in a very short timeframe. the best example of this is replacing powers with a cardholder page - powers were an abstraction we had for "the things you could do with your proofs", i.e. by completing quests you would gain access to powers such as the ability to attend an event or enter a secret chatroom. in between Zuconnect and Devconnect, we realized that powers were to complex for most users to understand, and that we should just attach quest rewards to the quests themselves. simultaneously, we also realized that the true value of our project was to cardholders, and specifically their ability to take their cards and have it mean whatever they wanted it to mean. cardholders drove the meaningful functionality of the app, and so in the span of a few days, we deleted the powers view and added a view where anyone who possessed an NFC card could update the meaning of the card and create social groups from people who tapped their card. this ended up being a much better hypothesis to test, and i think we got many more meaningful learnings from this than if we just stuck with powers. what was key on the technology front here was that we didn't build the most fully designed, well-abstracted application possible, but rather we left some room for error and gave ourselves the ability to iterate very quickly. crucially, we made the right abstractions, namely having the babyjubjub-ecdsa repo to be able to use zk proving out of the box, which also helped iteration speed greatly

And the things I think we did wrong:
- **single points of failure** - because of the speed we were building at, there was so much knowledge that was just stuck in one of our heads, and in the likely case that one of us was sick (which did happen) or busy with other matters, we simply would have lost a lot of time. one main example comes to mind - all quest/power creation was done through a poorly designed developer console that pretty much only i knew how to use for the first two weeks. it had just enough inputs to do everything you needed to do, but the inputs had no documentation, no validation checks, nothing to tell you how to use it. only prior to Devconnect did i sit down with Vivek and help him learn how to create quests/powers, otherwise we would have been slowed down significantly if i was ever unavailable
- **documentation/knowledge sharing** - we had pretty much zero documentation or public writing about how our system actually worked, and this is largely why we had single points of failure. i think because our project is in such early stages this is usually a tradeoff i would be ok with making, but it definitely burned us when we tried to get developers to work with Jubmojis. we allowed developers to build on top of our platform so that a user could generate a proof about their Jubmojis and submit it to an external app for verification, but we had pretty much no documentation about how to integrate this. in fact, i just wrote a verification script which we told people to copy paste, and anyone who had issues just came to me directly to troubleshoot. probably ok given the scale of our activation, but definitely could be improved for larger releases
- **shared team understanding of technology** - when it comes to these hectic conferences, it is incredibly useful for every member of the team to know a little about each part of the system, just to field questions and have discussions with different types of people. i think the engineering folk did not do a good enough job of sharing how the system worked from a technical perspective to others. besides this [one-pager](https://www.notion.so/pse-team/Jubmoji-Quest-Engineering-Overview-0f4ccbc311764048a92e355e448c7ef2), there were few other resources to understand what was going on. this also would've aided design in balancing the engineering load of new features. i think a whiteboard session where the entire tech stack is explained at a high level to the rest of the team would've been useful
- **communication of technological achievements** - this isn't primarily a technology challenge, but it is good to keep in mind as a builder - despite all the work that was put into many crucial parts of the system (proving signatures in zero knowledge, storing data client-side), most users simply didn't notice the difference between our app and one which just processed everything server-side. perhaps you can argue that self-custody is just not important to a lot of people, but we were testing with the exact crowd which would find these benefits meaningful. i think the fact that these attributes of ownership and self-sovereignty were not felt is due to product design but moreso communication with users

## Operations Process
We ended up with two main activations, namely: 1) a 100 person scavenger hunt at Zuconnect where players joined teams and solved riddles to collect Jubmojis and reach the top of the leaderboard 2) a set of art displays at ProgCrypto where attendees could learn more about Jubmojis and try tapping a few cards, along with a coordinate effort for 200 cardholders to wear their cards around the conference. I think the logistical organization of our activations was probably the thing we were weakest at, primarily but not solely due to the fact that it was the thing we spent the least time on. We came to Istanbul with only the scavenger hunt in mind, and suddenly realized we should plan something for Devconnect. Credit to us we made something happen, but it was clearly not planned out in advance. In addition, we didn't select our activations with a strong enough emphasis on creating long-term, sustainable value with the product we've built. The activations were centered around testing the technology and getting general user sentiment about the app, but we didn't do enough to answer the question of why someone would use Jubmojis beyond an event.

Things that went well:
- **saving a bad situation** - despite the fact that we did not plan in advance for Devconnect at all, we were still able to put out heads up and create a meaningful activation, namely setting up Jubmoji art displays at the Devconnect coworking space and ProgCrypto, and ensuring that people knew about them. in this case, doing something was way better than the alternative, and in fact, with the art displays we did choose an activation which was just small enough to make it seem curated and well thought-out
- **leveraging relationships with event organizers** - we were able to make some last second activations happen because we had good relationships with the organizers. it's key for us to maintain these relationships and more importantly have active dialogues with event organizers to collaborate on how we can help them
- **giving the project and team members a voice with talks** - we spent a lot of time preparing for our talks ([here](https://app.streameth.org/devconnect/progcrypto/session/qualitative_cryptography__investigating_the_role_of_qualitative_research_for_cryptographic_builders), [here](https://app.streameth.org/devconnect/progcrypto/session/unlocking_meaningful_zk_through_jubmojis), and [here](https://app.streameth.org/devconnect/progcrypto/session/onboarding_your_grandma_with_nfc_secure_element_and_zk)). these were especially important because they left digital artifacts on our project and the theses we were operating under, and we had no other stable public artifacts such as a website. in addition, preparing for the talks was very useful because they helped drive individual conversations forward and make the points we wanted to convey more clear. i think in the future talks are a great opportunity to make people more aware of the sector that we work in and encourage others to work on these problems and even collaborate
- **conversations with builders, users, and evangelists** - probably the most successful aspect of the three weeks in Istanbul were the myriad of conversations we had with people. not even counting the ones with potential users or evangelists, just making friends and learning more about what is going on in the larger space helps give a lot of context and ground the specific area that we are working in. in addition, this opens up the door to future collaborations that we might not have thought about otherwise. also just very useful for mental clarity and staying outside of a small bubble. in terms of talking to actual users and builders, we learned so much about what clicks for people about our product and what doesn't. just having people go through basic flows on the app without priming them led to so many UX insights and improvements

Things that could be improved:
- **planning collaborations in advance** - we could have done a much better job of reach out to event organizers and potential collaborators and planning out activations earlier in the timeline. by the time the event is nearing, organizers are way to busy and more intricate collaborations are off the table. this requires us to have a much clearer idea of what types of activations we want to do earlier in the lifecycle
- **public communications** - our main communication channel was through word of mouth. we were able to post on twitter via the PSE and Devconnect accounts, which racked up 20k impressions total, but this was a one-time thing and most people probably forgot about us. it takes a lot of time and thought to build an impressionable brand, but this should be a target for future activations. we need more of a permanent digital presence in general where people can find us, learn more about what we do, and reach out, whether this is a website, twitter, or other. it would be great to have a person dedicated to this project working full time on comms and partnerships
- **clear organization of logistical responsibilities** - one of the largest sources of organizational chaos throught the activations was that we didn't have clear places to go to find the information we needed. card management is the primary example here, we basically passed cards around in personal interactions, and it would often take multiple queries to figure out who actually possessed a card, or if the card was given away. now that we have a better sense of the scope of logistical responsibilities, there should be one person who is ultimately responsibile for each thing, and they should always be the point of contact for that thing, with another person serving as backup. in addition, we should coordinate who needs to be where and when. concrete responsbilities that should have been delegated: card/inventory management, collaborations, communications, developer relations, engineering fixes, design fixes
- **choosing activations that produce meaningful insights** - i don't think we did anything too poorly given the circumstances here, but in the future we should be cognizant of choosing the right activations. each activation should be aimed at learning something new compared to the previous ones, and we should make sure that activations can be done with full effort and support. one of the biggest flops was organizing a second scavenger hunt at the Zuconnect hackathon. pretty much nobody participated and i think this was due to a lack of foresight and preparation - we did not understand the hackathon atmosphere and came up with the idea last minute. in addition, i think even if the scavenger hunt went well, there wasn't a lot to learn as scavenger hunts are not a great application of our product in the first place
- **overall team organization and capability planning** - in an ideal world, we do not have to create new features or redesigns during the actual activations, but instead dedicate our full energy and time into bug fixes, support, and conversations. one of the biggest challenges during these three weeks was overcome all-nighters to build new features and designs and being constantly overloaded with tasks to do. this is inevitable for any activation, but we can do better to minimize the work that needs to be done on premises. during an activation, we should aim to all be focused on tech support, logistical support, and socializing. in addition, we should actually remember to eat, sleep, and drink water, especially for longer activations because it does make a difference
- **preparation for contributors/collaborators** - one thing we did not think of until the beginning of Devconnect was the possibility of developers building on our platform, people who wanted to collaborate, or potential contributors. this is easily something we could have planned for ahead of time, and set up logistical support for. i think the bigger issue here was that we didn't even know what types of collaborations/support we wanted or could support. this is also tied to good communications, in that people should know where to go for varying levels of involvement with our project. this is low hanging fruit and saves a lot of hassle during the event
- **answer the big questions ahead of time** - one of the reasons why it was so hard to come up with activations was that we didn't even fully discuss what types of experiments we wanted to run or hypotheses we wanted to test until the week of Devconnect. in fact, this is probably something we should be doing at the beginning of the product lifecycle, not at the very end. being on the same page about the big questions - why are we doing this, what are we looking to learn, who do we want to get this in the hands of - makes everything else so much smoother. of course, we didn't know the answers to a lot of these questions (that was the whole point of the activations), but we could have begun to take guesses and establish some shared language

## Hypotheses and the Big Picture

We had a few major hypotheses coming into this experiment:
1) Self-sovereign data ownership does not necessitate bad UX
2) Allowing people to collect cryptographic artifacts from physical interactions can create meaningful experiences
3) People care about owning their own data and being able to use it in a privacy-preserving manner

And my opinions on these hypotheses now:
1) This is pretty much true. There are so many tools we have at our disposal to build self-sovereign technology while ensuring intuitive if not easier UX patterns. It turns out that most secure technology which uses modalities such as NFC (smart cards) already come with the cryptographic tools needed to build ownership infrastructure. In addition, UX is just consistently getting better, with the adoption of passkeys and Webauthn leading the charge. Especially with the Webauthn PRF extension, we can now allow users to create dynamic accounts that store secrets based on biometrics alone, and this really levels the playing field for UX. At this point, the only real drawback of using privacy preserving technology from a UX standpoint is simply compute time - the time needed to generate client-side zero knowledge proofs about your data.
2) I think this is true, but am not sure. On the one hand, physical interactions are extremely rich. After all, we are humans living in the physical world that crave social interaction. Being able to have these interactions represented by cryptographic artifacts is extremely powerful. You can use this phyiscal history to build digital trust, whether that means reputation, loyalty, proof of humanity, or some other meaningful qualitative attribute. But perhaps humans want separation between the physical and digital worlds. The digital world is so loud, consuming, oppressive that people just want to be in the physical world to live, be a human, socialize, do normal things. They don't want their physical interactions burdened by cryptography, they just want to do human stuff. But movements like Pokemon GO give me hope. They demonstrate that the digital world can aid the physical world and make more rich, rather than taking away from its humanity. Jubmojis in particular shared this magic quality of being able to bring people together through the tap interaction.
3) I am a little more pessimistic about this. I think people care more about the feeling of ownership rather than whether or not they actually own something. Privacy always takes a back seat to capabilities. But at the same time, people feel bad when they don't have privacy, or when their lack of ownership means they lose something they care about. The most telling thing to me was that many people I talked to seemed not to care at all when I told them their Jubmojis were entirely stored client-side and self custodied. What attracted them to the product was the seamless UX of being able to tap a card and collect a digital artifact. I think in order for a product that allows self-sovereignty and true data ownership to get mass adoption, it must find a way to turn ownership at the protocol level into a feeling of ownership that users get when using the product. The key question is: what can users only do because they truly own their data? Secondly, I think marketing and communications will play a key role in shifting the public sentiment towards products that encourage ownership. Users must feel outraged that they don't have true ownership on existing platforms in order to switch.