The problem SWIRL solves

How memorable your IRls are?

The development of SWIRL originated from the phenomenon of ineffective networking encountered in several IRL events. Many people easily meet and exchange information about each other at meetups, after parties, and web3 conferences. However, often these relationships don't lead to sustainable and substantial connections, which feel very instant and useless.

If we recall recent meet-up experiences within Korea, exchanging business cards is common, but when it comes to networking, the number of people that are remembered is often small compared to the dozens of business cards received. This is where the idea of a fun and easy application like SWIRL came into play, which aims to ensure that Nametags(unique profiles of individuals met in real life (IRL)) are continuously remembered, and the persistence of relationships is maintained.

SWIRL's features, including significant custom areas and the incorporation of Web3 elements, allow users to embed their own personality into setting a distinctive 'Nametag.' The goal was to innovate the mundane and uniform business cards. The application also enables users to add a selfie or other customizations to established connections, making the nature of relationships with individuals custom as well, thus adding to its charm as a product.

In order to make this process even more fun and memorable, we tried to integrate various sophisticated techs to achieve simple UX(we tried to develop namedrop API for ourselves as there was no open API that enables namedrop at the moment)

Swirl's user-centered design is inspired by the principles of problem-solving UX design and employs common UX design patterns to tackle usability issues. Our goal is not just to build another app, but to create a tool that resonates with the users and adapts to their needs and behavior. We recognize the importance of simplicity

Challenges we ran into

Poor Support for iOS Mobile SDK (Swift): The only available Flow SDKs for Swift are fragmented third-party implementations, such as Blocto’s and Outblock’s. This led For example when trying to use Secure Enclave (HSM) and biometric auth to sign transactions, we’ve struggled to find SDK that supports implementing signer as async-await (

Outblock/flow-swift-sdk

was the answer!), and match the signature format due to the lack of relevant example/documentations. We were able to make it by debugging it at the SDK source level.

Limitations in the Cadence Language Itself: In order to verify a proof-of-meeting, GPS coordinates need to be compared on-chain. We wanted to calculate haversine distance but this was almost impossible due to the absence of basic math-related functions in Cadence (e.g., abs, log, pow, sin, cos…). So we approximated the distance instead.

Also, there was a significant need for string processing on Cadence for dynamic NFT implementation. but since the language lacks intrinsic functions, and there were no third-party libraries available, we spent lots of time for writing a bunch of for-loops and

.concat()

s…

• p.s. Flow Forum and Discord saved us a lot of time 😘