A few weeks ago, Icebreaker partnered with the organizers at FarCon to power a first-of-its-kind verifiable ticketing, registration, and networking experience over 4 days.

Each of the 500 summit pass attendees received individualized physical icebreaker badges with their Farcaster names and profile pictures, which functioned both as their nametags and their networking badges throughout the conference.

Example of final output on Summit Flagship day:

j4ck 🥶↑ icebreaker on Warpcast

it was really fun to be on stage for a moment today alongside @ted @julien51.eth @web3pm! big thanks to @ted for trusting us with the opportunity to build a one-of-a-kind dynamic NFT checkin flow fully onchain on /base thanks to /unlock-protocol and integrated with /icebreaker x /farcaster networking 🙌 https://imagedelivery.net/BXluQx4ige9GuW0Ia56BHw/07febfbc-4b4d-4662-d118-02750b3e3400/original https://imagedelivery.net/BXluQx4ige9GuW0Ia56BHw/34fd9f2a-d2c5-4ed7-d595-8ca5afe1a200/original

Farcaster

Prior to the event, we had never done personalization at-scale before, but thought it would be a great excuse to try since we like launching stuff at FarCon (the original icebreaker pre-alpha launched at the first FarCon) and more importantly, we thought that doing so could make the conference experience richer.

The conference overall was a smashing success (credit to @ted, @mcbain, @heavygweit, @dylsteck.eth and the other organizers), and Icebreaker was able to power the smoothest experience to date, with 94% attendees using their badges, >10 self-sovereign connections per person, and dozens of people telling us how much fun they had.

While the experience felt simple, the tech to make it happen was not.

This post is a reflection on what what we did, the lessons we learned, and some thoughts on what this means for the future of applications built around decentralized identity*.

*For this post, when we say decentralized identity, we mean public identifiers, often crypto wallet addresses, that represent people or social media handles, that any application can reference.

Background: How Icebreaker works

Icebreaker is a digital networking tool that allows you to make verifiable connections with anyone else in-person or remotely using a simple web app (or PWA).

Each user can have multiple profiles- like digital business cards, each of which displays a different subset of verifiable accounts and info. For example, here is my Web3 profile, here is my Web2 profile, and here is my personal card.

Although it's not required to use Icebreaker, there is something magical about blending the digital and physical, so Icebreaker supports physical NFC cards and tokens for making IRL connections by tapping with each other. Each physical card can be mapped to a specific person or one of their sub-profiles.

For FarCon, we wanted "it just works" for every attendee. The happy path. I.e., simply show up, scan your emailed ticket QR code for checkin, and then receive your personalized Icebreaker badge, ready to tap and use.

What we did (decentralized identity + elbow grease)

In order for the "happy path" to work for every attendee, we needed to do the following:

1. For every ticket holder (based on wallet address), get the corresponding Farcaster account

2. Every badge is printed with the Farcaster account's corresponding Farcaster name and pfp

3. Every badge is NFC encoded with a unique tokenID which is mapped to the correct Farcaster user on Icebreaker

4. All Unlock ticket NFTs redirect to Icebreaker for realtime dynamic metadata

5. All attendees had self-sovereign attestations with their badge type displayed on their digital profiles

6. Summit and side event checkins (based on wallet activity) automatically reflect on users's dynamic ticket NFT

7. Every ticket holder exists on icebreaker and is able to instantly log in as themselves, whether they use SIWF or Web3 sign-in

1: Ticket holder data. Difficulty:

We used a combination of Neynar and Airstack APIs, calling them as custom functions in a Google sheet. Both tools are great, but we still ran into some limits with API ergonomics and data freshness that required manual review of the results before we could print the badges with high accuracy.

2: Badge printing. Difficulty:

We'd never done automated personalized badge printing before but Emma, our rockstar Operations lead, figured it out and remapped our process to support it.

3: NFC encoding. Difficulty:

We have developed systems to do NFC encoding in bulk for tens of thousands of devices if needed, using either 2xx or 4xx generation chips. We are happy to consult for anyone looking to do this on their own devices since we believe NFC is one of 3 promising non-biometric approaches to sibyl resistance.

4: Unlock tickets directing to Icebreaker metadata. Difficulty:

Credit to the Unlock team for the heavy lifting on this one. On the Icebreaker side, we already had the capability to operate a deterministic metadata route for a given event / drop / wallet address combination. Unlock was able to make an onchain redirect for each tokenId to point to the correct Icebreaker metadata url on their side. Unfortunately none of the NFT platforms do a great job visualizing dynamic metadata rerouted using this approach, though they generally work using regular dynamic offchain metadata.

5: Badge attestations on all users. Difficulty:

We wanted to display each attendee's badge status on their Icebreaker profile if they had a ticket. Unfortunately there were 4 NFT contracts to read from, and we didn't want attendees to have to manually add each credential to their profile. So we batch issued offchain attestations using our Memberships schema, which were automatically pinned on each attendee's main profile. We could spend another post on why we like self-sovereign attestations but we could have done a million of these with omnichain verifiability for $0.01 through our integration with Witness.

6: Decentralized checkins posted to Icebreaker dynamic NFT. Difficulty:

What could be better than a dynamic event passport that upgrades with your behavior? One that upgrades based on many behaviors.

For FarCon, we had 3 sources of incoming live data- Unlock, Events.xyz, and CheckIn Caster.

We created a new API route where any event can have multiple "tokens" that increment arbitrary counters on icebreaker in the context of that event and without sharing any data aside from wallet address. Unlock QR code checkins pinged Icebreaker with one token, which marked the user as "Attended" for the main event. Events.xyz checkins pinged Icebreaker with a different token, which incremented the user's side events counter. And CheckIn Caster checkins pinged Icebreaker with a 3rd token, which incremented the user's "Checkin badges" counter. Each token can have its own customizable refresh logic and behavior. This allows Icebreaker to easily "wrap" events that can have incoming engagement and data from an unlimited number of sources, onchain and offchain.

We also added native POAP support post-FarCon, so the experience at future conferences where many POAPs are in use will be much richer.

7: Identity deduping across Icebreaker and Privy. Difficulty: 🔴 💀 🔴

This is where it started getting really tricky. Because we wanted "it just works" for both Farcaster addresses and self-custody wallet addresses, and we didn't know beforehand which address each person would sign in with, we had to ensure that either login would go to the same user.

Icebreaker uses Privy for managing logins and defaults to Email (for web2 natives) and Farcaster (for web3 natives), since we've found that SIWF offers the simplest web3-native sign in experience on mobile after obsessive testing over the past year. But, there are always some web3 natives that insist on signing in with an external self-custody address (like my wallet that controls web3pm.eth) from the "More options" section in our login module. The solution (at least until sign-in providers offer this as a default), is to create each user with both Farcaster and external self-custody web3 addresses as linked accounts.

If this were Icebreaker's first conference, then we could have simply pre-created all accounts with the perfect details and all accounts linked in Privy. But over 70% of attendees had used Icebreaker before, just with different logins. And for security reasons which are very reasonable in the context of other apps that manage funds or valuable tokens, once an account has been created in Privy, we are unable to link any additional accounts programmatically in Privy. This worried us, however, that a user would show up, log in with the "wrong" address, and a new doppelganger user would be created in Icebreaker and Privy. Their connections would then be a mess because tapping their phone to someone's badge would connect with the "wrong" address (i.e., the one they just logged in with on their phone), while tapping their badge to someone's phone would connect with the "right" address. And this would be complicated further if the user they're connecting with is also in this state.

So we had to map every user to one of 4 scenarios-

• A. User has one linked account but not the other.

  • Solution: Delete and recreate with both accounts on the same user in Privy. Add missing accounts in Icebreaker and synchronize user ID with Privy.

• B. User has both accounts linked but they're linked to separate Privy and Icebreaker accounts.

  • Solution: Delete both users in Privy and create a new one with both accounts on the same user. Merge both users on Icebreaker and choose the best one for the merge, making sure external self-custody web3 address is the primary wallet for checkins.

• C. User has both accounts linked and they're linked to the same user on Privy and Icebreaker.

  • Solution: No action required. 🦄 🎉

• D. User has neither accounts linked in Privy or Icebreaker

  • Solution: Create user with both accounts in Privy and Icebreaker. Do some manual searching in case this user exists but with a different login.

Why identity deduping was hard

Neither Icebreaker nor Privy had previously found an elegant way to resolve mismatched user states, particularly in scenarios A and B. Handling these required synchronized operations on both privy and icebreaker sides, and the scale was too large to do manually - we both had to create new admin tools and scripts to handle these account merge use cases.

To make this harder, we continued to receive new batches of ticket holders leading up to the event which required rerunning these operations and recategorizing users into scenarios, all while users were logging into icebreaker leading up to FarCon to perfect their profiles, and in doing so, altering their account states.

(Also a huge thanks to the Privy team for working closely with us, including after hours and over weekends to help achieve the "happy path"!)

Outcomes and learnings

Product outcomes

To proactively resolve the mismatched user accounts, we ended up building an account merge tool and a bulk account creation tool, and gained a lot of practice handling merging across account types in various states- which had been increasingly cropping up as we’d added new sign in options over time. This was essentially accumulated "identity debt".

We also changed the product in two ways to reduce the number of future users who get into this state:

1. We are reducing the number of sign in methods, particularly for new account creation, to be the absolute minimum required.

2. When a user does sign in with a web3 address, we now pull their linked addresses and programmatically create the user in Privy with all known linked accounts, so it's harder to accidentally create a duplicate account later.

What we learned

A pitfall of multi sign-in is identity fragmentation. Merging users has a ton of edge cases that need to be thought through (which is a reason why so few apps offer multi-account support). And even if we can merge users, it's still frustrating from a user's perspective to ever get into that state.

We deepened our relationship with Privy as a result and have a very good idea of where the existing tools are great for decentralized identity today, and where there are still limitations.

Final thoughts

The future has never been brighter for applications building around decentralized identity.

Aside from 2-3 misprinted (but digitally correct) badges, nearly every badged summit attendee reported they experienced the “happy path”.

It just worked!

For existing Icebreaker users, it was magical seeing their ambient activity on other platforms automatically reflected on Icebreaker.

For new Icebreaker users, they were able to show up at a conference and experience a sophisticated physical and digital networking experience with zero onboarding beforehand.

This experience would not have been possible without decentralized identity.

Though the process, particularly the identity deduping we undertook to ensure the smoothest experience possible, was laborious, it was well worth it.

We are now 100x wiser and look forward to the day that interoperable identity protocols provide a smooth and self-sovereign networking experience at every event and conference in the world.

-Dan, co-founder at Icebreaker