Inspiration
A member decided to share their experience of constantly getting ghosted on dating apps, which eventually led to them losing trust in such apps. Through this experience, we thought that maybe we could create something that helps with this situation using the XRP core features, eventually leading to us finalising on using this idea for the project.
What it does
A blockchain-powered dating app on the XRPL where connections are taken offline with real stakes. Users agree to place an equal stake, a deadline and a restaurant for their date. When they arrive on time, the staff gives them a unique fulfilment code that triggers an escrow transaction from their match. If they don’t show up on time, they are penalized with the stake, encouraging genuine connections and accountability.
How we built it
For frontend, we used flutter as majority of our group has experience with flutter. For backend, we used python as majority of our group has experience with python and there are functions in python to call the XRPL blockchain. For database, we used MongoDB as it is a NoSQL database, which allows for easier prototyping of the database schemas. For cloud services, we use Render to deploy the backend.
Challenges we ran into
One challenge we face is not anticipating that the frontend would require access to the XRPL server. When we realized that, it was too late as majority of the frontend code has be written in flutter. Hence, we researched online and found a package (xrpl_dart) that allows us to call some functions from XRPL.
Another challenge we faced is integration of frontend with backend code.
Another challenge we faced is being too ambitious at the start. When we were designing the app, we thought of a complete user flow instead of a MVP. There were some features that were not needed for the MVP. We could have more time to polish the app, instead of implementing those features.
Accomplishments that we're proud of
- A better understanding of XRP through this project
- Able to complete most of Frontend side
What we learned
- MVP requires important features that proves it work, we can cut down on features.
- Using react native for frontend may have been a better idea as there is a well maintained xrpl library.
- We should integrate with the frontend earlier.
What's next for Mingle
- Weak fulfilment code (8 digit); security is sacrificed for readability in this MVP, but the has of an 8 digit number is extremely weak. A more sophisticated fulfilment generation algorithm can be considered, with QR codes to share them
- Currently there is no economic incentive for us to host the app, so perhaps a new staking mechanism can be added to pay a small fee to us when a date is successful
- Correct implementation of aforementioned logic natively in Flutter using Dart, as escrow creation and finishing programs must be run locally with the user’s private key. (xrpl_dart is not established at all)
- Anonymity of wallets may be lost as they are tied to each user
- DID credentials can be used to verify that a registered restaurant’s wallet addr is real, so that fulfillments aren't being encrypted by bogus restaurants. Same thing for users to prevent catfishing
- Restaurants does not even need XRP accounts, just a secp256k1 key-pair for encrypting/decrypting fulfilments.
Log in or sign up for Devpost to join the conversation.