dartmouth-cs98 / project-22f-cash-stream

Cash Stream

CashStream

CashStream is a React web application to facilitate real-time crypto payment. It allows the user to open a continuous "stream" from one wallet address to another, where crypto assets will be transferred in real-time.

Our application is built for Goerli Testnet. It works for two Ethereum-based tokens, ETH and fDAI (stablecoin).

It includes a mock subscription service to demo "pay as you go" proof of concept. The service will be available only if the user opens a stream to the designated recipient address (0x45c01ceb87dbe6807ebecb9161408fc5c6acb5d1). (github repo) We also have a proof of concept for livestreaming content, like YouTube Live, Twitch, OBS, etc., which a viewer gains access to by initiating a payment stream. Video Demo and Github.

CashStream uses the Superfluid Protocol. Superfluid is a De-Fi company working to enable money streaming in subscriptions, investment, etc.

Checkout a short video demo of our project!

Read more about our project from our Medium article!

• CashStream: Recurring Payments by the Second
• CashStream Quickstart and Technical Guide

Architecture

Front End: React, HTML, CSS, javascript

Back End:

• Superfluid SDK Core: Superfluid is a smart contract framework on EVM that enables money streaming. It provides a SDK core, a JS/TS wrapper library that enables developers to use Superfluid without prior Solidity experience.
• GraphQL: GraphQL is a data query language we use to interact with blockchain to retrieve data.

Setup

Clone repo with

git clone https://github.com/dartmouth-cs98/project-22f-cash-stream.git

Navigate to repo

cd project-22f-cash-stream 

Install all dependencies for the project

yarn install

Builds the app for production to the build folder

yarn build

Run the app in the development mode

yarn start

Deployment

Working URL

Other

CashStream: Recurring Payments by the Second

CashStream Quickstart and Technical Guide

Landing Page

EtherStream Demo

EtherStream GitHub

Devfolio

Content Livestream Demo

Content Livestream Github

Authors

Tai Wan Kim, Harold Than, Jason Wang, Sunint Bindra

Acknowledgements

Superfluid

Superfluid SDK Core

project-22f-cash-stream's Issues

Mina Tutorial

https://docs.minaprotocol.com/zkapps

Explore tech stack / recurring payment smart contract

Data Models

Superfluid Money Router Example

Follow the tutorial on Superfluid Money Router Project.
https://github.com/superfluid-finance/super-examples/tree/main/projects/money-streaming-intro
https://www.youtube.com/watch?v=1mwbYQ429IU&list=WL&index=25&t=2417s

Winterim

[Services Page] Create Page with Table of Services User Can Subscribe To

Motivations:

• As user persona x, I want to do task y so I can accomplish goal z

Basic Front End Layout

We may pivot later, but we're going with the voting app for now.

Front end layout with two candidates as a choice and a submit button

Uncaught Reference Error Process not defined

Seems to be an error related to react-error-overlay but had to delete a branch because the package config got all weird when I reinstalled it.

[Dashboard] Implement GraphQL to get Stream Info

https://docs.superfluid.finance/superfluid/resources/videos

Fix Wrap Allowance Error

For some reason the allowance gets refreshed when it shouldn't.

Prototype V2

Project Proposal

Interactive Demo for Online Voting

Sunint Bindra, Jason Wang, Harold Than, Tai Wan Kim | CS98 22F

How Might We Question / Problem Statement

What is the problem you are aiming to solve? This is not the solution, that goes later.

In a number of countries, an online election system is making voting accessible for more users (such as people living abroad). However, the encryption/decryption process and other security protocols that take place behind the scenes are far too complicated for a layperson to understand. The voters have no choice but to blindly believe in the system with little understanding of how or why the system is reliable and transparent.

The HMW questions we are trying to address is:

• HMW help people understand the behind-the-scenes workings of existing online voting systems?

Stakeholders

Briefly summarize who are all the stakeholders? These could be users, partners, admins, founders, etc.

• Voters: Voters want to know that their submission is completely anonymous (no one, including the host, should be able to associate a particular submission value to the person who casted it). Furthermore, voters want to know that their votes have been correctly counted without possible intervention/manipulation.
• Host: The host want to establish the reliability and the transparency of its system. At the same time, the host wants to convince the voters that the information they collect are necessary to verify the eligibility of voters and to prevent fraudulent votes.

Proposed Solution

Briefly describe your proposed solution. How does it work and what does it do?

Our project is to create an interactive web demo that explains the workings behind an end-to-end, verifiable online voting system.

While different implementations may take different approaches, online voting typically has the following characteristics:

• Authentification: the host verifies that the eligibility of the voter.
• Privacy: Individual votes remain confidential via some encryption method.
• Verification: The system can verify to the voter that his or her vote has been correctly decrypted and counted.

Our demo will walk through these steps. To the side, we will have a window/console that represents the server side. For instance, as the user casts a vote on a mock election, he or she will see encryption/decryption keys generated by the system and also the encrypted results being displayed on the console.

Prior Work

Briefly recap any particularly relevant sources from your state of the art research.

Here are some open source code that enables an end-to-end, verifiable online voting.

ElectionGuard by Microsoft
zkp-vote by tomoima525

There are also multiple resource on Zero Knowledge Proof technology that makes the result verifiable:

Zero Knowledge Canon by a16zcrypto
STARK101 by STARKWARE

Impact

Explain how a solution to this problem meets a real-world need. Does it have a broad potential impact?

Having a credible election systems is important. Our project can make people trust the system, or at least make an informed decision on whether or not to trust the system. Our project may have broader impact in the future when online voting becomes more widespread.

Success Metrics

What are your ultimate success metrics? This could be changing one person's life for the better, or getting 1k downloads, or some performance threshold.

We can have "did you find this demo helpful?" kind of survey at the end to evaluate our performance.

Minimum Viable Product (MVP)

Briefly describe your MVP features. Don't get bogged down in details, this should be a very terse list. What is the critical thing your product needs to do to be special? Build this from your User Personas.

• A user friendly demo easy to navigate and interact
• Making abstract process visible
• Explaining abstract concepts easy to understand

Validation

Explain how you plan to test/validate your product. Propose a term 1 and a term 2 validation idea. This can be different things depending on your project: user testing, or usage analytics, or performance characteristics. It can be done via surveys or in product analytics, or other performance measurements.

• Term 1 Validation: Our goal for the first term is to have the demo voting system working with ZKP and encryption methods built in. We would be able to tell if the system is doing what it's supposed to be doing.
• Term 2 Validation: Our goal for the second term is to set up an interactive environment. We can have user tests to evaluate our performance.

Implementation Challenges

What development challenges have you thought about so far? Identify any risks and briefly discuss possible workarounds / alternatives.

ZKP and encryption/decryption are theoretically heavy concepts so we are expecting possible difficulties in trying to understand and digest the concepts. However, there seems to be tutorials, online resouces that we can base our work.

Sprint Retrospective Term 1 - Sprint #1

Was there an issue made for this sprint?

Explore existing recurring crypto payment tools

UI/UX

Sprint Retrospective Term 1 - Sprint #2

Sprint Retrospective #2

• members in attendance:

  • Sunint
  • Jason
  • Harold
  • Tai Wan

• what worked well

  • We've been learning zkApps by Mina. zkApps are smart contract powered by zero knowledge. zkApps are written in Typescript, using the snarkyJS library. For now, we think we'll use snarkyJS for our back-end.
  • Here are the list of tutorials/github repos we've been replicating:
    • Hello World
    • snarkyjs workshop
    • sudoku
    • tic tac toe
  • Below is the screenshot from the tic tac toe tutorial. (Player's identity is verified through a public key before making changes on the board)
    

• what didn't

  • We are still trying to figure out how to hook this up to a UI (connect it with a React app)
  • We expect voting to be much difficult than the tic tac toe or sudoku examples.

• self assessment on progress

  • We realize that we're falling behind, but we expect things to be easier once we have the tic tac toe example fully understood and hooked up with an UI (and it can be a helpful side demo to have at the end of term 1).

• lay out each of the following weeks till end of term with brief goals for each

  • current week: We will spend the week trying to play with the tic tac toe tutorial a bit more and connect it to a React app. We're also beginning to think about the design of the voting app (such as the conditions for eligibility).
  • next week: Have at least the basic UI of the voting app.

• briefly summarize any other topics/discussions

  • We might pivot to another smart contract project but we think what we're doing now will still be relevant.

Peronal Goals

Tai Wan Kim | Personal Goals

what does success for this class mean to you?

• Learn blockchain/crypto and web development.
• End product I am proud of.
• Hopefully a creative solution to an interesting problem.

Challenges

what are some challenges you foresee?

• Lack of experience in blockchain and web dev
• Work from other classes
• Lack of resource available for some features we are trying to implement

Transaction Broadcast Progress

-Page loading while transaction is being broadcasted.
-Display message when transaction has been broadcasted.
-Display Etherscan link to the broadcasted transaction.

Research on ZKP

Try to learn the code from these repositories to see if we can ZK working.
https://github.com/tomoima525/zkp-vote
https://github.com/microsoft/electionguard

Metamask connection stuff

1. If the user isn't connected to Metamask, ask to connect (Now, it throws an error because the code tries to fetch user's flow info even when the user is not connected).
2. Let the user disconnect.

Wrap/Unwrap

wrap unwrap tokens

State Of The Art Research

State Of The Art Research

Your Problem Topic

Flowrate Unit

change wei/sec to something more reasonable like fDAIx/day or fDAIx/month.

T2 Project Reflection and Next Steps Worksheet

T2 Project Reflection and Next Steps Worksheet

Original idea

Revisit your original goals (check out your project proposal).

MVP Progress?

What progress did you make towards your original MVP / on your stretch goals?

Our orginal MVP was to create a smart-contract-based web app where users can set up recurrent payment for crypto (such as Netflix subscription or monthly rent). We currently have an app where crypto asset can be transferred from one wallet to another, but the method (as described below) is different from our orginal plans.

How is it different?

How is your project different from what you envisioned?

We soon found out that automated recurrent payment is challenging to implement as each crypto settlement requires an authorization. Our alternative was to instead enable crypto "streaming" using "super token", which is just an extension of regular Etherium-based token with added features.

Still happy with direction?

Most importantly, are you still happy with the direction that your project is headed?

We are generally happy with the direction of our project.

What do you wish went differently?

What do you wish had gone differently / are there features you wish you hadn't made or made differently?

We think we are in good direction, but our app now only has backbone features. Our goal for this term is to flesh things out along with a nice UI.

Feedback

What feedback from last term do you think is relevant and interesting to incorporate. List your feedback broadly and label them with how they stack up for your vision. These may already be in ZenHub but after this discussion they should be.

• [critical 🔥]

  First, we realize that our product wasn't user-friendly or well-designed at the end of term one, and our goal is to have a better UI and make the end product look professional. We also haven't paid much attention to the quality of our code as long as we were getting things done, but now is a good time to revise parts that are inefficient or bad in practice.

  What we also realized from Technigala is that some people weren't convinced by the idea of continuous streaming of money instead of regular lump-sum payments. The lump-sum payment system is designed to favor one side (either the receiver, who might be paid up front, or the payer, who might delay payment), and the argument was that whoever benefits will be unwilling to adopt a new system (especially companies like Netflix would have no incentive).

  While we initially stumbled into the idea of money streaming to circumvent the technical difficulties that involved with lump-sum recurrent payment, we believe the idea could be more than just a proof-of-concept that such thing works. We hope to come up with a clear and concise way to introduce our problem statement and sell our product. This may involve presenting a well-defined use case where streaming money is particularly effective.

  One idea is that while Netflix may be unwilling to give up on the lump-sum payment system altogether, it may benefit from offering an option to pay in real time at higher rates to attract users who do not wish to commit for a full month.

• [stretch goal 🍦]
  As a part of an attempt to convince users, we are hoping to set up some cool demos. For instance, a streaming service like Spotify where users pay in real time only when they are listening to music. We're not expecting to have a fully fleshed streaming app but hopefully we can come up with a good enough demo.

• [rejected ⛔]

Questions

Think about where the project is headed. What are some questions that you/users/me have about direction/features/functionality that could use some validation?

The above answers seem to address this question.

Answers

Think of ways that you might validate these: discussion with your team, advice from me, polling the class, asking users, and/or collecting and analyzing usage data. Write down some ideas here. This isn't how to validate your project as a whole, but about specific feedback/features.

We think we will benefit most from talking to faculty members and other students.

Vision

Refine your vision.

Feedback Analysis

How does the current feedback/user testing/progress change how you think about the direction of the project?

We were a little surprised by the skepticism we recieved, but we don't think we will change the general direction of our project.

Pivot/Adjustment

If you were to consider a pivot or adjustment in what the product is, what would it be?

We're tired of pivoting and hopefully we don't have to. But if we do pivot, we think it will be to tailor our payment method to a particular use case.

Ideal Goal

In an ideal world if you could build out your project to be anything without any constraints of time or skill what would you want to do? Dream big — you can do more than you think. Try to push the limits. This does not commit you to anything, so don't worry about overpromising, this is to get you dream about where you really want your project to go without constraints. Please don't skimp on this part.

• Enable lump sum recurrent payment as well so that users can choose between options.
• Compatible with streaming services like Netflix and Spotify.
• Published on Etherium mainnet, support all Etherium based tokens and maybe even other cryptos like Bitcoin.
• Provide interesting anlaytics.
• Notifications

Mission Statement

Now write a mission statement for your project as you see it after all of this great brain activity. Just a few sentences suffices.

How to get there

Now that you've thought about where your project is headed and where you want it to go write down how might approach getting there.

What are your concrete next steps?

Here are our plans for the coming week.

• UX/UI overhaul (make a new figma prototype)
• Use redux to clean things up.
• Added features for creating a new stream. (Change wei/second flowrate to something more user-friendly)

What are some blockers in your way?

Our lack of experience and skill as crypto/web developer.

TeamWork

Lastly, at the end of last term in the term summary you did a bit of work around teamwork. this is just a reminder for everyone to revisit that and if you have any new or further thoughts after the break feel free to record them here.

Our teamwork can be improved in terms of staying organized and using tools like Zenhub efficiently.

T1 Summary and User Testing

T1 Summary and User Testing

Summary

Feedback ranged substantially given the specificity of our project relative to the range of Technigala attendees. Most user testers seemed interested in the concept but expressed that while they do not use crypto or have wallets set up for that purpose, they could see the product being used by those who do.

Those with crypto backgrounds largely expressed excitement about the possibility of recurring crypto payments or acknowledged its usefulness when they found out that typical recurring payment installments are technically inaccessible in the blockchain ecosystem (since every transaction must be signed, paying each recurring sum that would automatically be transacted in TradFi (traditional finance), would require re-authentication in the crypto ecosystem).

A small subset of testers pushed back against the notion of converting subscriptions or other recurring payments typically paid in installments to a continuous "stream" of payment flow. They raised concerns that whoever the status quo currently favors (either the receiver, who might be paid up front, or the payer, who might delay payment), would be unwilling to adjust to a new payment system that disadvantaged them relatively.

Observations

Something we observed is that we need a clear and concise way to introduce our problem statement. Secondly, we need to develop a similar explanation for our product. I think improving our clarity without getting too bogged down in esoteric crypto details will help us develop a better pitch and a more focused product.

Some notes / catchphrases / ideas stemming from that:

• Real-time settlements
• Subscription by the minute/second
• Check out Diagonal and MeanFi for additional payment functionality
• Normally paying on the first => Netflix can charge $11/month instead of $10 to give you this distributed payment option
• Vice versa if you normally pay on the 30th (say $1000/month for rent) then the landlord would want to use this to minimize risk and headaches at a discounted rate to the tenant (say $975/month)

Analysis

Not sure there is much statistical analysis we can do here - I think the nicheness of our product given the general audience (limited crypto users) was a difficulty in finding enough potential users.

Notes To Future Us

Next steps should include streamlining the user experience, adding additional features (risk analytics, portfolio management), and extensive testing.

TeamWork

In general, our team is working well together. We have had to pivot several times over the course of term 1 and have been able to communicate productively throughout. Everyone is pitching in and we will also be able to delineate our work more into specific features now that we have our MVP functional.

What has been working well?

Meeting every week, being active on Slack

What has not?

Using Zenhub effectively and having a clear plan for the upcoming week.

Steps

As mentioned above, we ran into a couple of dead ends and some of us had limited prior crypto and web dev experience. Now that we have had time to explore, I think we'll be able to better plan out the upcoming steps.

[External Service Page] Mock Spotify

Revisit Past Assignments

Let's try to finalize on what we want to do by the weekend and revisit past assignments like user research.

Delete Stream

Add function to delete an active stream

[Service Page] Mock Netflix Subscription Page

Authentication Features:

• Authenticate Subscription Status Automatically Through Browser's Metamask
• (Extra) Magic QR Log In: User can log in to the site through Scanning QR Code from their phone

Review Roadmap

Sprint Retrospective Term 2 - Sprint #1

T2 Sprint 1 Retrospective:

• members in attendance:
  

  • Sunint
  • Jason
  • Harold
  • Tai Wan

• what worked well

  • did some work over the winterim. looks better than what we had for technigala. Everything merged to main branch of repo.

  • We have a generally good idea of where we want to go and what our next steps are.

    

    

    

• what didn't

  • need a new UI/UX and a better code (organize states with redux etc.)
  • some errors still need to be resolved.

• self assessment on progress

  • where are you in relation to progress towards product and milestones?

    • give an estimate of how far towards your goals you are, do you think you're on track?

      We have our backbone feature working (being able to stream crypto from one wallet to another), but we still think it would take a lot of time to introduce other features and set up a nice UI/UX.

    • lay out each of the following weeks till end of term with brief goals for each

      • Week 2: figma mockup, code review, new features for send stream page, better dashboard
      • Week 3: work on UI/UX based on new prototype.

• briefly summarize any other topics/discussions
  Nothing much to add. We elaborated on the T2 reflection assignment.

Make UI nice for Technigala Demo

The fall-demo branch has a simple application where you can connect to metamask wallet and start a new stream. Make the UI look nice for technigala demo.

Coingate API testing

Test Coingate API. Verify it works and get comfortable with it prior to building out frontend.

External Services

Personal Goals

Sprint Retrospective Term 1-Sprint #4

Sprint Retrospective #4

• members in attendance:

  • Sunint
  • Jason
  • Harold
  • Tai Wan

• what worked well

  • We pivoted our project to a crypto real time payment system.
  • We came across Superfluid, a smart contract framework that enables money streaming. It also provides a wrapper TS/JS wrapper library that we can use without prior solidity experience.
  • We have some code in the fall-demo branch. Now we can connect to Metamask and create new stream.

• what didn't

  • We found Superfluid this week and didn't have much time to explore. The code we have now is mostly integration of code snippets here and there from different tutorials and demos (we've put acknowledgements in the code).

• self assessment on progress

  • Since we only have about a week until technigala, we won't have time to start writing everything from scratch. For now, our plan is to focus on having a demonstrable product. During the winterim, we'll look into the documentation and do some work that we can be on pace at the beginning of the winter term.

• lay out each of the following weeks till end of term with brief goals for each

  • current week:
    • make UI nice
    • make figma mockup again for technigala
    • add dashboard
    • add delete stream function
  • next week: technigala

• briefly summarize any other topics/discussions

Prototype

Figma mockups for new UI

crypto recurring payments UI

Write recurrent payment smart contract

https://gist.github.com/taytwkim/2604e2aefd9321b192353aac6636f0d9

Success/Error popup

Show if stream has been opened without an error. (Currently, we have to look at the console to check the error message)

Group Dynamics Worksheet

Group Dynamics Worksheet

Team Members:

Jason Wang
My leadership style:
Analyst & Architect / Driver / Spontaneous Motivator / Relationship Master

What technical niche would you like to fill?
(2-5 bullets)

• Back-end work
• crypto interfacing (new to crypto)
• PM-type work

What personal niche would you like to fill?
(1-3 bullets)

• Gain experience / familiarity with crypto
• build project from ground up

Harold Than
My leadership style:
Driver

What technical niche would you like to fill?

• UI Design
• Front End Work

What personal niche would you like to fill?

• Gain Experience working with Crypto Integration Payment systems
• Inspire non-crypto folks to learn and want to work in the space.

Tai Wan Kim
My leadership style (bold one):
Analyst & Architect

What technical niche would you like to fill?

• anything really
• interested in learning crypto

What personal niche would you like to fill?

• learn crypto
• build something cool

Sunint
My leadership style (bold one):
Spontaneous Motivator

What technical niche would you like to fill?
(2-5 bullets)

• Design
• Use cases / application focused
• Integrations and partnerships
• Gain crypto specific coding skills and becoming highly competent in zero knowledge from a math and CS perspective

What personal niche would you like to fill?
(1-3 bullets)

• Help serve as a liason and solicit feedback from Dartmouth Blockchain and external crypto organizations
• Be a motivator and visionary to help push the boundaries of people's personal and group expectations
• Continuously iterating on ideas and helping support team members in their "what if?" ideas

I. Communication

You are required to spend at least 10 hours/week outside of class. Outline a general weekly meeting schedule with at least 1 time that everybody can make. That one meeting must include the entire team in the same room, in person. The rest of the 10 hours may be split into several sessions throughout the week. A nice tool for this is when2meet.

Schedule

• CECS/Irving
• Sunday afternoon ~1-3pm at CECS/Irving
• Thursday at noon at CECS/Irving
• Monday mornings as needed at zoom/library

Responsiveness

How often should team members be expected to check and respond on Slack?

• 2x a day
• Tag if time-sensitive / urgent

II. Decision Making

Group

What types of decisions need to be discussed and approved by the entire group?

• Major ones
• Tech stack
• Finalizing deliverables (either in class smaller ones or big picture ones)

Individual

What types of decisions can be made by a single person?

• Implementation details
• Grunt work

III. Conflict Resolution

There are three main types of conflict that tend to occur in group projects:

• Creative differences: disagreement on any decisions related to the product
• Personal differences: friction between people due to manner or words said
• Ghosting: consistent missed deadlines or lack of contribution

Your group should decide on a plan of action to deal with each type of conflict. There can be multiple levels to each plan. Involving the instructors can be part of the plan.

Course of Action

What will your group do in order to resolve each type of conflict? (include the levels of escalation)

• Creative differences: disagreement on any decisions related to the product

• We first create an open forum to voice ideas. If people are unclear on ideas they can ask questions and we can ask for a more formalized plan of action with additional details so individuals can voice their opinion with greater knowledge and understanding.

• If we are stuck and can't come to a consensus we can vote as a group

• If we come to a stalemate we can ask for external input from classmates/peers or adults if at a stalemate

• Personal differences: friction between people due to manner or words said

• Try to remember that everyone has the same goal in mind and we are on the same team

• Step back and take space if things are getting too acutely heated

• Communicate at a later time in a respectful manner what the conflict was about - hurtful words said, issues with the rhetoric, etc - and provide an agreed upon understanding of how they would like things to change in the future

• Have other group members try to step in and be sources of support and mediation as they are comfortable

• Ghosting: consistent missed deadlines or lack of contribution

• Communicate to the team member on multiple channels as needed if they haven't responded - Slack, phone text, GroupMe, email - etc.

• We create the expectation that if someone is going to be unavailable for a solid chunk of time (out of town for sports/competition, personal/health issues, taking an exam, etc) - they aim to communicate this to the group.

• If group members feel another member needs to communicate better they bring it up during a class meeting and provide an opportunity for the individual to explain themselves and also improve moving forward

• If they completely ghost and don't show up (no digital communication, not coming to class, haven't heard at all from them and can't be tracked down) then we can ask for instructor help to reach out and contact the individual
  The End!

bug

First Team Meeting Worksheet

First Team Meeting Worksheet

Team Members Present

• Sunint
• Tai Wan
• Jason
• Harold

I. Identify a Common Vision

• Finance-related (DeFi?) crypto project

Commonalities

• Econ + CS majors/minors
• Finance, OS and latency
• Emerging Technologies

Inspiration

• Helping people
• Impactful technology
• Learning emerging technology (crypto)

Problems of Interest

• Translation of existing infrastructure to crypto / emerging technology
• Potential target demographic: Individuals in developing nations lacking access to traditional financial instruments.
• DeFi tools for institutional investors
• Bloomberg for crypto
• Social media with your crypto trades -> API through Etherscan

Identify

Which of the above is most interesting to all of you?

• All are interesting, we need to increase our familiarity and deep dive in the problem to finalize on one
• As of now we like institutional/business facing analytics tools
• Leaning away from front-facing payment gateways

II. Narrow In

• Same as above
• As of now we like institutional/business facing analytics tools
• Leaning away from front-facing payment gateways

Coolness

• Leveraging emerging technologies
• High potential utility
• Can find a niche that is not served by an existing product

Challenges

• limited experience with said emergent technology
• Possibly limited resources as such

Success

• Create a novel tool that could maybe be useful

Sprint Retrospective Term 1-Sprint #5

• members in attendance:
  
  • Harold
  • Tay
  • Sunint
  • Jason
• what worked well
  • We successfully implemented much of our barebones functionality for creating and deleting flows
  • Successfully familiarized ourselves with some of the idiosyncrasies of the superfluid sdk
  • Implemented wrapping / unwrapping of tokens
• what didn't
  • Several stumbling blocks with the superfluid SDK (e.g. wallet authentication, etc)
• self assessment on progress
  • where are you in relation to progress towards product and milestones?
  • I think we're progressing quite well, especially given our late start due to several pivots! We've made really strong progress over the last week or so and have successfully prepared an MVP for technigala.
  • give an estimate of how far towards your goals you are, do you think you're on track?
  • Yes, I think we're on track through this term despite the previously mentioned delay in getting to this project. We've worked together really well to make progress over the last week and a half since pivoting and am very optimistic for next term!
• lay out each of the following weeks till end of term with brief goals for each
  • current week: hone in on presentation for technigala
  • week 10: Improve user interface & streamline current functionality
• briefly summarize any other topics/discussions

Clean up Zenhub / Github issues

Mockup

https://www.figma.com/file/uE54AG1p4i0KNv0yNrfOxE/Mockup-Sunint-Jason-Harold-Tai-Wan?node-id=58%3A1104

Sprint Retrospective Term 1-Sprint #3

Sprint Retrospective #3

• members in attendance:

  • Sunint
  • Jason
  • Harold
  • Tai Wan

• what worked well

  • We pivoted our project to a smart contract for recurrent payment system.
  • Here's what we have right now: https://gist.github.com/taytwkim/2604e2aefd9321b192353aac6636f0d9
  • We tested the contract on remix IDE and it seemed to be working for the most part.

• what didn't

  • Unfortunately, there seems to be no way to set up an automated recurrent payment system. The sender has to sign each transaction. The existing recurrent smart contract systems merely check if the right value has been transferred at right time.

• self assessment on progress

  • We're beginning to feel a bit nervous.
  • We think we'll make a similar smart contract that lets users withdraw money based on how many hours they have worked. (the contract checks if the address and value are valid)

• lay out each of the following weeks till end of term with brief goals for each

  • current week: make front end (a single page web app for now), set up database (stores user information and work hours), write a smart contract.
  • next week: integrate everything.

• briefly summarize any other topics/discussions

Create Dashboard

The fall-demo branch has a simple application where we can connect to metamask wallet and start a new stream.

The next step would be to have some kind of a dashboard where we can see all outgoing and ingoing streams associated with the connected wallet.

Look here.

[UI/UX] Redesign Front End

Motivations:

• As user persona x, I want to do task y so I can accomplish goal z

User Research

https://www.figma.com/file/0J3XKe8S2cpZ3jPslozUHk/User-Research-(lightning-pay)