higm

It’s hard to find the right people and remember everyone you meet in events. No web2 platform gets it right. We are building a dApp to discover, meet, and maintain connections.

Comment 4

Inspiration

  1. We have attended many web3 conferences: ETH Denver, SXSW, Devconnect, NFT Berlin… and the list goes on! In them, we met so many new people with varied backgrounds, but found it difficult to some with the same interests - and we are so exhausted this is still the case!

  2. After meeting a woman at NFT Berlin who meticulously kept a meet spreadsheet, we realise this project can ease her pain points and bring great value!

What it does

Mobile-first networking dApp where you are empowered to:

  1. Create your very own decentralised identity;
  2. View others’ decentralised identities going to the event;
  3. Stay connected to the people you want after the conference.

How we built it

Inspiration

  • We have attended many web3 conferences: ETH Denver, SXSW, Devconnect, NFT Berlin… and the list goes on! In them, we met so many new people with varied backgrounds, but found it difficult to some with the same interests - and we are so exhausted this is still the case!
  • After meeting a woman at NFT Berlin who meticulously kept a meet spreadsheet, we realise this project can ease her pain points and bring great value!

What it does

Mobile-first networking dApp where you are empowered to:

  1. Create your very own decentralised identity;
  2. View others’ decentralised identities going to the event;
  3. Stay connected to the people you want after the conference.

How we built it

Identity

The Identity.sol contract is an ERC725 contract that is able to hold SBTs, and can contain any information about the identity. We are using the setData function of ERC725 to store some arbitrary bytes that represent the profile information of the identity. This can be an IPFS hash that refers to a JSON file for example. This profile data is stored under the key PROFILE_IDENTIFIER which is set to keccak256("Profile").

Soul

The Soul.sol contract is an Identity that owns an SBT an has minting capability. Upon the initialization of the contract an SBT contract is deployed and th e Soul is set as it's owner.

SBT

Implementation of a soulbound token. Soulbound tokens are non-transferrable, non-financializable tokens proposed by Vitalik Buterin. Our implementation shares most of its functionality with the ERC721 standard, except that the transfer functions are taken out, thereby making the SBTs non-transferrable.

Identity Factory

Contract for deploying identities and souls. It relies on the Clones library from OpenZeppelin to create many instances of the same contract. An important limitation is that only one identity and soul can be created per wallet.

Mobile

  • Swift implementation of WalletConnect to allow access to wallet account
  • We authenticate the wallet account with the event and fetch attendees and profiles.
  • We’ve built an easy-to-use interface which allows users to connect and discover others.

Challenges we ran into

Team and Project Management

  • The hurdle of having a common consensus with people with diverse work and cultural, six backgrounds is high. And, it was difficult to self-manage in a team of 6 people who’d never met each other before! But it’s been brilliant, and we have overcome these issues by communication.

Product Management

  • The process of narrowing down to a simple value position and fixing it was tough in a product that is expected to expand several technical features and product value positions.

Technical

    • We wanted to do native interaction between swift client and blockchainn. But given lack of time constraints and available documentations if was not possible in current timeframe. Still managed to use walletconnect.

  • Soulbound tokens do not have a de facto standard implementation yet, because they are relatively new, so we had to come up with our own standard. We took most of the functionality of ERC721 but removed the transferability of the tokens.

  • Using Swift, To get the native app client to connect to the smart contract.

  • Soulbound tokens do not have a de facto standard implementation yet, because they are relatively new, so we had to come up with our own standard. We took most of the functionality of ERC721 but removed the transferability of the tokens.

Accomplishments that we're proud of

1.Team Building

  • At first, discussions were awkward and the atmosphere was sometimes better, but as time went on, we were able to improve the atmosphere of the team immensely.

2.Integration wallet connect

Resilience - despite many of the issues we encountered, we were able to come together and bring forth solutions, that actually came to fruition!

3.Clean Functional UI

Looking great in Figma and in the swiftApp.

4.Product Design

  • We did not have a designer on our team with a design background. However, we all worked together to create a cool design.

5.Product architecture:

  • Connecting the blockchain infrastructure with the frontend mobile app and the web interface

6.Made a MVP

  • We were able to write code and create MVPs with smart contracts, web, and iOS. Also, everyone on the team, including non-engineers, was able to be involved in this process by leveraging their strengths. Above all, we were able to create a cool product that all of us could relate to the problem we wanted to solve.

What we learned

1.Project Managment

  • It will be easier to proceed with product development smoothly if you meet face-to-face at least once, either online or 1-on-1, before the day before the hackathon starts.

  • It is important to clarify the team's timeline at the outset.

    • We can be more productive if we ask in advance what talks, etc., each of us would like to attend, and if we clearly define a time and place for all of us to meet and focus.

2.Product management

  • Writing down and sketching to have same consensus together easier

    • If we proceeded with the discussion by transcribing the design and words every time we confirm it only verbally, we could have a consensus more easily and spend more time on product development.

  • Clarify development requirements and pre-define minimum and maximum priorities for the hackathon,

3.Technical

  • Technical implementation, SDKs, SBT

4.Presentation

  • Simplicity is the most important thing
    • Factors that might complicate the explanation must be removed as much as possible and simplified to the utmost limit.

5.Crypto Economics

  • You do not necessarily have to have your own tokens. Stablecoin or ETH is fine.
  • If you issue your own tokens, you must clearly define the reason for issuing the tokens.
    • Specifically, the user needs that the product solves, the user actions, and the overall value of the product should be tied together.

What's next for test?

  1. Verification of approval by the mobile app store

Apple's review process is strict, so even though it is a dApp, it must pass the review process.

  1. Test that users who are using existing means of networking at the event are really having issues.

    If they learn about higm and continue to use higm instead of Twitter or Telegram when meeting people at events, this is verified.

  2. Test if there is a need for ETH related event organizers to issue SBT tokens for their events.

Built With

+ 40 more
Share this project:

Updates