Projects
![]()
No projects found
Investors
New
DAO Treasuries
DATs
Lend / Borrow APRs
Chains
Categories
Spaces
HACKING: Upgrading @cooprecsmusic Earnings Page on @base with AI Tools
Recorded: March 31, 2025 Duration: 2:12:09Space Recording
Short Summary
The transcript highlights innovations in blockchain technology, particularly in the music industry, with the implementation of on-chain payments allowing musicians to receive earnings every 30 minutes. The development of a record label on-chain with Base marks a new project launch, reflecting a trend towards blockchain-based music distribution and instant payouts. These advancements indicate growth in the adoption of blockchain solutions, offering musicians faster payments and greater ownership of their art.
Full Transcription
Hey everyone, today I will be live coding updates to Coop Records earning page using
AI tools.
I'll be refactoring the revenue display to show your earnings.
I'll be filtering songs to only include the songs that you are earning from, fixing the
lifetime earnings to reflect your wallet's total, and removing the withdrawal button
because we're paying out automatically every 30 minutes and securing earnings data with wallet connections.
Watch me tackle these improvements step by step. Let's get started. Step one, I'm going to define
these tasks inside of linear. Let's share screen. Bypass, system private, window picker directly, sure.
Let's share screen.
And let's start by making some new tasks.
First one, primary revenue.
I want a new column with your earnings.
So let's go plus P1 primary revenue, your earnings, actual primary revenue.
Let me see what it actually looks like.
cooprecords.xyz forward slash earnings.
This is the production page that I've been building out.
Yeah, I think we just wanted a new column or new column.
Yeah, we said new column. It's just new column. Yeah, we said new column.
It's just new column.
Your earnings.
Primary revenue displays the total amount a song has earned, but we do not show the final amount that the all that have the connected while it has earned primary revenue displays the total amount but
a song is earned but we do not show the final amount that deep our owner of the
connected wallet I don't even the amount that the connected wallet, we can remove the owner
of final amount that the connected wallet has earned. Required add a new column titled your
earnings, which displays the percentage of primary revenue, which was earned by the connected wallet,
based on the percentage ownership the connected wallet has of this song.
Add a new column titled your earnings, which displays the percentage of primary revenue,
which was earned by the connected wallet based on the percentage ownership the connected
wallet has of the sum.
This ticket looks good.
We take the ticket, we throw it into AI, into an LLM.
We take the rest of the required and actual, paste it in here, and then AI gives us
a cleaned up ticket. This is the constant little back and forth we do. We have an idea,
we document the idea, we give the idea to AI to refine, we take that refined idea,
and then we implement it off. New column, your earnings, take this text, paste it, and we now have our first ticket.
Let's keep moving. Next one is P1 filter 0% ownership.
Actual. If I visit the earnings page, I can see every single song regardless of if my ownership percentage
is greater than zero or not any song on the earnings page where the percentage
ownership is zero should be hidden from the list so that I, as an artist, only see the songs which I am earning from.
Okay. If I visit the earnings page, I can see every single song, regardless of my ownership
percentage is greater than zero or not. Any song on the earnings page where the percentage
ownership is zero should be hidden in the list so that I, as an artist, only see the songs which
I am earning from. Looks perfect. Repeat the loop. Take the ticket that I wrote as an artist, only see the songs which I'm learning from. Looks perfect.
Repeat the loop.
Take the ticket that I wrote with my voice using just riffs of my ideas, paste it into
AI so that it can clean it up and make it a little bit more understandable, both to
myself and to my team and to the suite of AI tools that I'll be giving these tickets
And then we move on to the next ticket until tools that I'll be giving these tickets to and
Then we move on to the next ticket until we've completed all of our tickets and then we start implementing
Next ticket. Let's take it 205 next one lifetime earnings
Connected lifetime earnings is showing the total amount of ETH I have earned.
The connected wallet has earned in protocol fees across the songs that they own specifically for the create tour fee.
Specifically for the creator fee.
Okay.
Actual lifetime earnings is showing the total amount of E across the platform earned.
Across the platform required is that lifetime earnings show the specific amount of E and
USD conversion.
The connected wallet is earned in protocol fees across the songs that they own specifically.
Let's keep it a little bit simpler.
Paste.
Paste.
This is ticket three of five.
Getting, we've already done our voice note
implementation of the ticket.
Here's what I'm reading from, by the way.
So in my meetings with my teams, my teams tell me feedback on what they want built.
You can see I write it down, handwritten, stuff like primary revenue, 0% ownership,
withdraw button, what we're working on now of lifetime earnings.
These are like one sentence,
my scribbles saying in the meeting, this is how I'm interpreting it. It's only in text that I
understand. If I gave this to someone else, they might not understand it. What I'm doing now is
I'm taking the simple text that I wrote down during a meeting. I'm formalizing it and adding
it to my backlog. Once it's in the backlog, it then becomes much easier for us to actually build
tickets around it and implement those features in a trackable way.
So I can now take this text that I wrote.
Well that the model wrote based off of my voice notes, based off of my written notes,
create that ticket, move on to the next one with this is P1 with draw button.
Actual.
There's a withdraw button on the page,
even though withdrawals are happening automatically every 30 minutes on base.
Required, colon.
Remove the withdraw button because we are already automatically distributing earnings directly into the artist's wallet every 30 minutes on base.
Okay.
Withdraw button.
Actual, there's a withdraw button on the page,
even though withdraws are happening automatically every 30 minutes on base.
Required is that we remove the withdrawal because we are already
automatically distributing earnings directly to the artist every 30 minutes on base.
This is something I really love about on-chain infra is for the music industry.
In a world where musicians are used to getting paid six months later,
we have built a solution on base, on-chain, where by publishing your music on-chain,
you get paid automatically every 30 minutes. Let's compare those two. Musicians publishing on
traditional infrastructure like Spotify and Apple Music, you get paid once every six months.
Let's hope you don't need that money to pay rent. Compare that to bass where you get paid
automatically every 30 minutes. If you need that money to pay your rent or to feed your family,
great, you'll have it in 30 minutes. If we wanted to make it every minute, we could make it even
faster. 30 minutes is just the cadence that we've set at. The record label, Kuprax, told me to set
it at a day. A day I wasn't really able to monitor it like I wanted to. And so I increased the
cadence to 30 minutes so that artists are getting paid faster. I'm able to track the data more.
And we're just building better systems on chain on base. Let's take this and let's do the next ticket.
I'm yapping a little bit too much,
so I think I'm going to go back to being a little bit more focused
on the tasks I'm doing and less on the audience.
Okay. okay I really don't even read what the AI wrote I just assume that it's doing a good job because
we built that rapport I think this last ticket's already going to be done based off of the first
one because if my wallet's not connected my percentage ownership
should be zero so for now i'm actually not going to write this ticket and let's get started building
these changes i like new tickets to be at the top i think it's easier up our code base so i'll go to my terminal
and from here i'll change directory into the directory where all my projects are
in this case it's inside of a directory i've named coop. And then inside of here, we've got a collection app, which is where the earnings pages open up this app
inside of cursor so I can start playing around. And I see we've got our first comment of the
day. Someone has tuned in. We've got Khalil Mohamed Ayob Sayah, good to see you.
Sorry, where can I find the description of the project you're actively working on?
That's a great question.
Let me throw up a QR code in the top right for Cooprex.
There it is.
So if you check in the top left of this video, you'll see a QR code that is showing the link to the production app that I'm building.
So if you want to see what
i'm building just scan that qr you'll go and you'll see the page that i've already built
and you can see the record label that exists on chain all right so now that we've got our
code base open let's open up my roadmap which is where i save all of my tickets
dynamic ownership percentage based off the connected
wallet i've already completed that ticket 77 double sevens starting off on a good number
this isn't full screen make it full screen we don't need our terminal full screen anymore we
we got what we needed all right let's start copying these tickets into my roadmap
got what we needed all right let's start copying these tickets into my roadmap
open up the first ticket paste the title
paste the description and i'm not well i'm gonna have it get started while i'm still writing so
that it can run unimpeded please prepare your scratch pad for step 77.
prepare your scratch pad for step 77. And now I'll copy the branch. Let's go to my get tab.
To my branch name, we'll create the new branch and publish the branch.
Once we've published, I will pull the latest changes from main. Let's pull from
I will pull the latest changes from main let's pull from origin main.
Let's see how many changes have happened since the last time I pushed,
if it's only two or three, that's probably just me.
Maybe there was one other dev that pushed,
but not a ton of changes other than the changes that I'm making.
And so it's still running ahead and it's building out the changes.
I'm going to keep defining the tasks while it goes through implementing the tasks.
78, paste in the title, copy the description, paste the description, delete the empty line so my formatting works.
Now we move on to 79.
Lifetime earnings, connected wallet.
How long is it going to take me to get the first pull request created looks like it's stopped writing so let me check in with where it's at to unblock it
current task add your earnings column context need add a new column showing specific
to the connected wallet earnings must calculate based on ownership percentage and total revenue, will display alongside the existing columns. Requirements analysis, add new your earnings
column to the earnings table, calculate the earnings based on total revenue of the song,
connected wallets ownership percentage, must handle different scenarios, direct funds wallet
100%, no split contract recipient partial percentage or non-recipient 0%. Implement
changes, UI change, add the new column,
style to match the existing column,
format the currency values consistently.
Data calculation, use existing ownership percentage calculation,
multiply tool revenue by ownership percentage,
can the alleged case of no revenue or undefined percentage.
Integration, let's update the table row component,
ensure reactive updates.
Seems like it's heading in the right direction.
Proceed with implementing this feature.
Just copy that, send it on, let it proceed.
And now I'm going to go back to what I was doing in the roadmap.
Close others.
Move on to our fourth and final task of the day. Oh, and we got a kitty joining us.
If you don't already know, this is my kitty, Solana.
She loves coding.
So anytime she can, she finds a way to get on my desk, and she's my copilot.
In reality, she writes all the code.
You guys think it's me
But usually I'm not showing you my hands. This is actually the coder that codes everything I've ever built
I'm just the yapper. I do all the talking. She does all the coding and that is how we do it
So this is Solana. She's my baby girl
my co-pilot my favorite pair programmer
My co-pilot my favorite pair programmer
you're starting to write let's close this chat comment it looks like we got someone else replying
so let's see if we have any more texts that we want to looks like khalil said thanks no problem
khalil thanks for tuning in on youtube we don't get a lot of YouTube subscribers, so thank you for tuning in.
And if you have any more questions, please let me know.
I'll be taking note of this chat throughout the talk today.
All right.
So it started implementing the changes.
We've added a year earnings tab.
And now let's update the releases table row ownership percentage is using ownership percentage
number is not assignable to type string
i actually think ownership percentage should be a double or a float because a number infers it's a
it's a whole integer I believe but in reality it's not a whole integer it's going to be
fractions percentages
I would like this to be its own component.
Okay.
Please create a new standalone component for your earnings.
I do not want this file to get longer.
We want to follow the single responsibility principle, which states that each component should do exactly one thing.
This component is a row.
And so inside of that row, there are individual cells. And so if
one cell requires work, I would like to create a new component just to represent that cell. So that
the row component just focuses on the row. And the individual cell component can focus on the work
that the cell needs. That keeps our files simple. It keeps all of our components composable and
modular, which keeps our code clean and easier to maintain and build
on moving forward, which allows us to iterate faster, which means that we can continue to
keep our pace high. We want to have a high cadence of release so that way we can get feedback and
implement that feedback in a very quick loop, which allows us to stay on the frontier of publishing on-chain music agents
boom now we're integrating the new cell we've deleted a little bit of code
ownership percentage number is not assignable to type string let's just have chat fix it
please keep it concise.
I love that line concise.
We want all changes to be simple and concise.
We need this fixed before we can push
because if not, the build will fail
because of the TypeScript error.
All right, looking better. Let's push it.
We go to our roadmap, save the changes.
Well, I don't want these zeros.
That was from Solana.
And now we copy the node, paste the node into our commit message, commit the changes, push
the changes.
And let's, I'm going to collapse this because my goal
is not to do any coding locally let's wait for that deploy and start opening up our pull request
in order to do that i will head over to github
for cooprex in the collection app
let's compare and pull i'll now need slack open so let me get that up open create the pull request
And let me do a quick code review.
and let me do a quick code review
See if everything looks okay.
Earnings cell, this is the big new file.
We calculate earnings based off of the revenue and the ownership percentage.
I'm wondering if use ownership percentage could be moved into the component.
I'm surprised. Where's ownership percentage could be moved into the component.
I'm surprised where's ownership percentage revenue,
ah, ownership cell. Is this using that hook? This is using that hook.
So we have two options here.
I don't like that this hook is being called
inside of the row component.
And so we could follow the model of ownership cell and define it inside of
the cell component, which means that we are going to be making more API calls,
which is going to be slightly slower.
Or if possible, we can include this inside of a provider and then use reference to value in both components.
And what that would do is it would allow fewer calls but greater access to that data.
And so I think I've already decided I'm going to use a provider.
Please add this hook to a provider so that it can be accessed by both.
Please add this hook to a provider so that it can be accessed by both
ownership cell and
earnings cell.
Let's see if it can do that.
Can it create the provider, wrap the components in a provider,
and then allow me to consume that provider information and the local components,
thus saving the api calls
keeping our code clean and making our data more accessible across the app creating an ownership
provider we've got a lot of people tuned in we've got 816 people and we're only 22 minutes in
that tells me that the base team probably retweeted us. So shout out base.
They allow us to build this record label on chain and they give us great infrastructure to allow musicians to get paid fast, easy, and for low costs, less than a penny, less
than a second.
We're able to distribute funds on chain.
And that's only because of companies like base.
Get ownership percentage should be imported use
ownership percentage use ownership is now coming from the provider.
Get ownership percentage.
Use ownership.
Get ownership percentage needs a royalty recipient and a chain ID.
This is feeling a little convoluted, the solution. Not super happy with it. So before we commit this, I'm going to make sure to clean it up a bit. We got a provider. We updated the ownership cell.
No changes were made here.
So this one actually wasn't updated.
Earnings cell was updated to use the hook.
Okay.
So the first thing I want to do is go back to the...
Please update this hook to use...
I'm sorry.
To use the existing hook instead of defining it again. And that hook is use ownership percentage.
Yes, we should reuse the existing hook. Let me update the provider.
That's a great idea, Chad.
I'm glad you thought of it.
All right.
This should have deleted a whole bunch of code.
I see another issue.
We can't use hooks inside a callback.
Look at how clean that looks.
Way cleaner than before.
Now let's update to use the restructured provider.
Ownership cell is now using use ownership.
We're wrapping the cell in the provider.
I don't like that.
I would like to wrap the cell in the provider I don't like that I would like to wrap the row in the provider instead of wrapping individual cells with the
provider could you please wrap the entire row with the provider to reduce
the total amount of code
whoops there were some typos instead of wrapping individual cells with the provider.
Could you please wrap the entire row with the provider to reduce the total amount of
code?
Earnings cell, ownership cell, ownership provider releases table row.
Those seem like the correct files being changed.
We just want to optimize this code a little bit before pushing it to production.
So first it's going to update the row.
And there's some code that's not being used here so we can delete that. now we've got an ownership provider
and this should result in fewer props being needed by the individual components because
they can just reference them from the provider.
Look at how short this component is.
All that it does is it's just showing a value from the provider.
This is way simpler than it was before.
There's no props being passed in.
Ownership cells looking good.
Earnings cell should be next. Earnings cell is now being updated. I'm loving how
these changes are feeling now. This feels much cleaner. We're getting rid of a lot of code.
Earnings comes from revenue
times ownership percentage that looks good all right are we all good now let's check file by file
earnings sell i'm happy with ownership sell ownership cell happy with releases table row looking good
we wrapped it in a provider we deleted some code from those
props which are no longer being used and now we have a new provider. This all looks awesome.
I manage ownership percentage for a row in a provider instead of manually
calculating inside of each cell.
I manage ownership percentage for a row in a provider instead of manually
calculating inside of each cell. Let's commit and push. And I'm going to continue with code review while it is deploying
those changes. I'm not going to go into testing yet. So before we had 33 lines added and none
deleted. Let's see how that new change impacted our total net. 33 to 0 goes to 113 to 55. So we're writing way more code.
We're writing way more code. 60 lines of net added code instead of 30. So we've over doubled the
amount of net code added. Observing for now. You can see the cells are now way simpler. The cell, no more parameters,
just takes, just shows the percentage. We've added a new column header
inside of our row component. We're still about the same line of code. We went from 71 to 77 here.
still about the same line of code we went from 71 to 77 here so the existing
I think I'm gonna need to close the door that noise is getting pretty loud
I'm gonna turn on the TV a bit.
Okay.
And we're back.
All right.
We're in code review step.
We have a provider that is wrapped around our row.
That allows everybody in the row to be able to access ownership info ownership provider is the new provider code looks great I'm happy with it let's
post this inside of slack and then let's try to test the changes this morning I
will okay Sid's telling me what he's up to and I'm gonna go to code review. And inside of here, we say hashtag cooprex,
because that's the project I'm building in.
Paste the link for the get pull request.
Go to the ticket.
Go back up to my first ticket.
Copy the title.
Paste the title.
Write the word ticket.
Copy the URL of the ticket, add a hyperlink
for the ticket so that it's easy to reference, and then I share. I verify we don't have any
previews. There's no previews opening up. We're looking good. And now we are in the deployment
step. And so I'll go to inspect.
Close some of the tabs we're not using for now.
And let's check out how these builds are going.
Are they succeeding?
Are they failing?
Looks like we had an error on our latest build.
But I think we might have fixed it.
C is not a function.
That's a very random error.
I'm hoping that doesn't happen again.
Yeah, we've already lasted another minute.
I think this build is gonna be successful.
Created all server, yeah, it's deploying.
Seems like we are on a successful deployment.
And because it's already live,
I can visit it a little bit early
and start seeing how the page looks go to the deployment preview go to forward slash earnings i will take
this and tell my team test here it's going to then probably put in a massive preview
yep there it is let's close out of that
keep our review clean
and here is
so here's the ah okay so here's the table and we can see the collaborators i have not connected my wallet.
And I still don't see the new column being added.
It looks like it just finished deploying.
If we refresh, do we see it?
I now see a your earnings column, and it's showing zero across the board.
Let's see if that changes if I connect my wallet.
I've been using Phantom.
As the wallet to deploy new music on base.
So I'll get my Phantom password, go into my Phantom wallet, make sure it's unlocked,
and that it's in testnet mode because I'm testing on testnet.
We use base-sipolia testnet for testing that allows us to have parity with base mainnet
while also giving me the freedom to create at will without worrying about gas
or just my content showing up that I'm testing with as like a production release. Okay, moment of truth. Are we going to see your earnings now populate?
Looks like I now see for anything that I have 100% on.
for anything that I have 100% on.
I want 100% of zero, 100% of zero, 100%, 100% of zero.
So it looks accurate.
I'm not on any splits.
But it looks accurate to me. Let's take a photo and let's get this shipped
and I'll verify with the team that they're seeing correct numbers later on, but it looks correct.
And so I'm going to just ship it and then get feedback instead of spending extra time trying
to verify if I'm doing it right. It looks, I send the ship emoji before I actually shipped.
it looks I send the ship emoji before I actually shipped silly me let's get this merged now let's
move on to the next pull request take this put it in here and let's get a little ship
and we add a ship emoji to the top level message.
And we're now done with our first pull request.
We go back to roadmap.
We put an X in the box.
Please prepare your scratch pad for step 78.
Tell it to prepare while it's getting started setting up.
We can see that the ticket for ticket one was automatically moved to done because we've linked our tickets to our pull request.
And now let me link this ticket by copying the git branch name in the top right corner.
Come back into my code base.
Check out two.
Paste the name.
Create the branch.
Publish the branch.
Once I do that, I will pull from main.
And then we'll redeploy.
And now let's check out the scratch pad.
Current task, filter out 0% ownership songs, context,
currently showing all songs on the earning page regardless of ownership, need to hide songs where connected while it has 0% ownership, already have ownership percentage calculated via the ownership
provider. Required analysis, filter out songs with 0% ownership from the earnings table.
Must check ownership before rendering the row.
Should maintain existing sorting display
for non-zero ownership songs.
Handle loading states appropriately.
Step one, data filtering.
Use existing hook.
Add filtering logic at the table level.
Consider performance implications of checking
ownership for all songs.
Hi, princess.
How are you, Kalani?
You're good?
Yeah.
I saw you playing with your ball.
You like that ball?
We're in a new house.
Yeah. So Kalani's figuring out what she likes,
where she likes to sleep, what toys she likes to play with.
We're all getting used to the new house.
Okay. So overall looking decent. I'm not sure. I like that it knows that we already have the hook.
You're thinking in the right direction. How can we leverage that new provider that you've built
to help us filter out the rows?
while keeping total files changed to a minimum.
measure twice cut once I give it the initial instructions I see how it's planning on doing
it how it has measured my input if I think it's correct we proceed with the correct measurements
if I think his measurements their measurements might be off a little bit we tell it to reflect and keep going table row wrapper this is what i want
whoa whoa whoa whoa whoa row yeah yeah okay now we've got releases table row wrapper
nice this looks great it created the row i don't like that it created it
Nice. This looks great. It created the row. I don't like that it created it.
Please move the wrapper to its own standalone file.
We've got a provider that wraps the row.
The row wrapper then checks if it's zero.
If it's zero, we don't render the row.
Now we've got the wrapper in a standalone component.
I'm going to delete these comments because I don't like comments.
Code should be self-documenting. And then I think we want to update the rows to not have...
We have the provider duplicately imported here, right?
I don't even need correct English as long as I communicate the general direction of the idea.
The LLM, the model, can understand what I want it to do, and it can then update the code for me.
understand what I want it to do, and it can then update the code for me.
Yes.
since we're now handling the ownership context at the wrapper level.
Exactly what I want to happen.
This is doing everything perfect so far.
So now it just starts with the table row.
The row has no context of the, has no awareness of the provider
because that's happening at the provider because that's happening at
the row.
It's happening at the table level.
It's happening at a higher level.
I'm not being very eloquent with my words right now.
We add in the comment.
We stage the changes, commit the changes, push the changes.
And now let's see if it worked.
Successful commit. push the changes and now let's see if it worked successful commit we go over to get and now we are preparing for a review of the code changes go back to
pull requests we get auto prompted to open up the pull request for that new
branch we're pushing compare and pull Open the pull request.
Now we take the pull request.
We go into Slack.
We say hashtag Cooper X because that's the project that I'm building in.
Add in the link to the ticket.
and let's now start getting the testing instructions
okay
we take this link we go to the link we add forward slash earnings to the end
link we add forward slash earnings to the end so that way we can see the earnings tab
and i tell my team test here paste the link it opens up the preview i close the preview
we're not connected so let's connect our, actually, let's wait for the final deployment.
I'm curious to see how this looks if my wallet's not connected.
I would like to see if my wallet's not connected, an empty table, because my ownership percentage is zero, because my wallet's not connected.
So the table should be empty.
Let's see if that's the case.
While we're waiting, let's start reviewing the code changes.
We have updated the table body.
It's now wrapping each row in an ownership provider. And then we have a wrapper here.
We now, the row is simpler.
Instead of wrapping the row in an ownership provider,
it just starts with the table row, a simpler component.
And then we have the wrapper,
which returns null if ownership percentage is zero.
Otherwise, it returns the row row code changes look good to me
very simple total files changed
uh net change 130 lines of code 120 total new lines of code added 25 lines of code 24 lines of code, 120 total new lines of code added, 25 lines of code, 24 lines of code to be specific.
So pretty small full request. Less is more, simple is best, small is beautiful. Keep changes small,
iterate quickly, get feedback as early as possible. I don't need this.
I should be able to refresh this page.
I'm hoping because they all show zero,
we see an empty table now.
I see an empty table now.
And so let's see what happens if I connect my wallet.
If I connect my wallet,
I should see all the drops where ownership percentage is not zero. Well, I guess let me cancel this first and show a wallet not connected show no data no rows in earnings table
and now if we do connect let's try this again the table should update to show me all of the rows where my earnings percentage are greater than zero.
Automatically, before I've even finished signing,
we saw that the table updated to show everywhere
that my earnings percentage are greater than zero, which
it looks like the only time that that happens
is if I have 100% in this case.
So now I'm only seeing, whoops, wrong type of photo.
After I've connected my wallet,
I now see all of the songs
where my ownership percentage is greater than zero.
After I've connected my wallet, I now see all of the songs where my ownership percentage is greater than zero. After I've connected my wallet,
I now see all of the songs
where my ownership percentage is greater than zero.
This is looking good.
I'm gonna go ahead and ship it.
Merge it, confirm the merge.
And we share the status that it's been shipped.
Add a little ship emoji, and that has now been shipped.
Two pull requests in, 46 minutes.
46 divided by 2 is 23, so we're approximately 23 minutes per pull request right now.
Not the fastest cadence I've ever had, but also not the slowest.
Let's start preparing for the next task please prepare your scratch
pad for step 79 let it run let's start make sure that the previous one was
changed to done it was copy my branch name come over to version control tap
three dots check out to paste the branch name check come over to version control, tap three dots, check out two,
paste the branch name, check out a new branch, publish the branch.
Then we pull the latest changes from main.
Pull from origin main.
And then push those changes.
All right.
Scratchpad's ready.
Current task update, lifetime earnings calculation,
currently showing total platforms earnings in need. Need to show specific earnings for the connected wallet. Must calculate based off of ownership percentages. Need to include the USD
conversion requirements analysis. Update the lifetime earnings to show the connected wallet's
earnings. Calculate based on each song's total revenue. Connected wallet's ownership percentage
per song. Sum up all owned songs.
Include USD conversion.
Only include songs where ownership is greater than zero.
Implementation plan.
Data calculation.
Use existing use ownership percentage hook.
Calculate per song earnings.
Total revenue times ownership percentage.
Sum up all the song earnings.
Convert to USD using the current rate.
Component updates. E summary component, reuse the ownership provider pattern.
I'm not sure the provider makes sense here.
Overall, it seems like it understands what I want.
So let's just help proceed with implementing this feature.
using the earnings hook makes sense but i'm not sure i understand how the ownership provider
would be helpful in this context
two pull requests so far why did it just do that use earnings stop how do I Use earnings.
Stop.
How do I get this to stop?
There we go.
Command shift that.
Okay, we roll back.
Why did you create a new hook when we already have.
What was this hook?
Let's expand this and see what it was, but I don't think it was doing anything helpful.
It was trying to use a provider to create a new hook.
I don't understand what it's doing here.
Are you sure you understand the requirements for this step?
Hi, baby.
Seems like you're getting better and better with being here.
You're not hissing anymore.
Misunderstood.
Let's analyze what we actually need.
We need to modify the existing lifetime earnings.
Only sum up earnings from songs where the connected wallet has ownership.
Calculated songs contribution based off of that.
No need for a new hook since we already have the ownership provider.
Let me look at the current earnings summary.
Let's see what it's doing here.
Earnings summary row, what?
Stop. Command shift backspace.
It still seems like you're trying to use the provider, which is not going to work in the context of earnings
aggregated across multiple songs.
You'll need to think through a different solution
in order to get the ownership percentage. Please thank DP and update your scratchpad with your plan
for implementation so that we can review your plan together. If you're just tuning in, we are building out earnings distributions on bass
for musicians that are releasing music in the Coupe Records ecosystem. Right now, when you earn
on Coupe Records, you're getting paid out automatically every
30 minutes on base. And we have a page where you can go and see all those earnings. So that way,
it's easier for you if you're a musician to come in and see how much you're earning across your
songs, which is better accounting, which makes it easier for a musician to look at their art as a
small business. The current step that we're on
is we want to update this lifetime earnings section up here
with the actual amount that me,
the connected wallet has earned.
Currently we're showing the total earnings
across the protocol on basically a test net,
regardless of the wallet that's connected.
And so we wanna update that to only show,
just like the table below is only showing the percentages
of the songs that I have a greater than zero percentage on.
We want to do the same thing up top.
And the big challenge we're running into right now is currently we wrapped each individual
row with a provider that gives us information of how much they own percentage wise.
But up here, we need to aggregate it across all the songs.
And so I'm starting to reconsider whether our current provider architecture is correct
or if we need to think through something else,
which is why I'm going to have it updated scratchpad.
Problem analysis, current issue with my approach,
trying to use ownership provider, which is designed for per row context.
Need to calculate total earnings across multiple songs at once. Need to handle ownership percentages for all songs in a single
calculation. We already have token infos, all songs in their mint data. Use ownership percentage
hook that calculates ownership for a given royalty recipient and mint price constant for revenue
calculation. What we need is a way to batch calculate ownership percentages, sum up the
earnings only for the song we have ownership, calculate total earnings before rendering, create a new hook, use lifetime
earnings. I love that. Use token infos as input for each token, calculate the revenue, get ownership
percentage using existing logic, calculate the earnings, sum up all the earnings, return total
earnings and USD value. This looks great.
This is looking way better.
Let's see how this implementation comes out.
Proceed with implementing the hook.
Sounds perfect because if I can see the hook,
if I can see the hook, I can verify
if the logic looks correct or not.
And if it looks correct, we'll proceed.
And if it doesn't't we'll come back to
the scratch pad maybe Kalani was trying to tell me she wants to go outside because I don't think she was talking before.
And ever since I shut the door, she's now talking.
She likes to spend a lot of time in her bathroom.
All right, we've got the hook.
Contracts and token infos.
Earnings.
Use ownership percentage. That doesn't seem right.
But let's see if it works first.
Yeah, but it's already saying a hook can't be executed more than once.
So I'm thinking
can we create a shared lib Hi, princess.
Hi, baby.
I think you want to go outside.
That's what I'm hearing.
Is that what you're trying to tell me?
Yeah?
Well, I'm not hearing the noise anymore.
So if you want to go outside, I'll open the door.
You just want attention or you trying to talk
I'll take that as you're trying to talk
Let's reopen the door so that Kalani can go back outside all right I don't know if that's what she wanted she's still over
there looking at me she walked outside for a second but now she's still in what
are you saying going what are you trying to tell me she's so funny I'm so blessed
to have those kitties in my life. They're everything. Okay, where were we?
Implemented.
Okay, so the use split metadata
is a hook, which is great.
But it's only good for one. let's go to 0x split stocks
we need to fix this build error.
We can't use a hook in a for loop. two at use ownership percentage is calling the
you split metadata hook in the at splits
hi babe i hear you how can I help you, Mama? What do you need? Yeah? You just talking? You just singing because it's a pretty day? What is it, babe? The little back leg kick makes me think you want to play. Is that what you want? You want to play? You're just chatting and walking in circles.
Does she want to play enough?
Oh, look at how pretty cute you are.
Oh, there's your furs.
Your furs are coming out.
I think she's a happy girl.
Oh look at you baby. You look so flop on the ground look at that fluffy white belly I'm beautiful. Aww.
How can I make your day, buddy?
Do you just want my attention?
I'll give you my attention.
I want you to know how much I love you.
Anytime you want to talk, you just tell me.
And I'll stop so that we can have a chat okay I think she just likes my attention
okay and it looks like we don't have the 0xSplits docs. So let me go back to here and let's try to go to 0xSplits docs.splits.org.
We're just going to call it splits.
And the splits sdk which we will also be unable to iterate over in a loop
let me see if i can find the method i would like instead of having the ui or the ai try to find it
i think i might be able to find it a little bit better let's look at um so the react sdk is what
we're using right now and we're using the use split metadata and it's calling the get split
metadata function data client.
It looks like use split metadata calls get split metadata get split metadata under the hood and now let's paste the links to the get split metadata. Question,
what would it look like to call,
we pasted the same doc twice,
let's go to the get split metadata function and give it context of that,
to call get split metadata, and give it context of that to call get split metadata or is there
another function what's get related splits get all splits related to a current given address maybe
get split earnings get user earnings get earnings by contract
and we can pass in contract addresses
now i'm wondering if we want to use the get user earnings by contract, because what this
would allow us to do is we don't even need to tell it the ownership percentage because
the splits already know it. for get userings by contract seems like it could be perfect for our use case with only required one API call required to get the lifetime earnings for the wallet for
the connected wallet across all splits contracts we would only need to add the earnings for the connected wallet, which do not use
a split 100% ownership.
What would it look like to call get split metadata? 100% ownership.
What would it look like to call get split metadata?
Get user earnings by contract
inside of at use lifetime earnings.
Question. question please update your scratchpad to
think about this question
took me a little bit of time to formulate that the main reason is we have not gotten the answer we
have not gotten an answer i wanted to move forward for the past two iterations.
So I wanted to spend more time really telling the LLM what it is I think the solution should
look like to try to get the LLM back on track.
I remember I was talking with someone in Buenos Aires about how they, it's an artist who was
using AI to build videos.
And she was saying how it's like guiding a baby and the baby as it takes a
step it might start to fall so you just use your hand to kind of keep it on its feet and you just
kind of keep your hands beside it so that it takes its step takes its step it starts to fall you keep
it up and so right now that's what i'm doing i'm keeping my hands beside the baby this llm is a
very raw level of intelligence whenever it starts to go off track, I just use my hand,
spend a little bit of energy, push it back up so that it can get its balance again. And then once it's able to get correct footing, find its balance, come back to its bones,
it's then able to proceed. All right. Current issue, using a hook in a loop which validates
which validates rules, making multiple API calls to get the split metadata for the ownership contract,
rules, making multiple API calls to get the split metadata for the ownership contract,
not efficiently handling non-split contracts. Proposed solutions, use the use earnings by
contract. Ah, it found a hook that I didn't even consider. Let's go back to the hook reacts SDK, use user earnings by contract. It found a hook that I didn't even consider.
This is awesome. Nice. Make a single API call, returns earnings broken down by contract,
includes both withdrawn amounts and active balances. This should be perfect.
Proceed with implementing the solution. I'm not even
going to check right now. Let's just see what you do. This is cool. Again, I was trying to guide it
and so I gave it specific docs and then it didn't just listen to what I told it. It used its
knowledge of the docs and the information I gave it to propose an even better solution.
the information I gave it to propose an even better solution. Splits provider,
create public client. Splits provider. Do we not already have the splits SDK
provider?
Do we have two splits providers now?
It does look like we have two providers.
All right, so another misstep.
We've created a new splits provider, which was not correct.
Let's roll back those changes.
And now we come into splits provider right here.
Inside of our components, we should have another one.
Components, providers, splits provider. Yeah, we should have another one. Components providers, splits provider.
Yeah, this should not be here.
So we will delete this splits provider.
Paste our original splits provider.
Delete this providers folder inside of components.
We don't want that.
Providers, delete.
And then we should have splits providers being used inside of index right now
it's being imported from components providers we just want it from providers and now that should
be fixed at layout already includes the provider. Looks like we're getting close.
Okay, it's now I'm, object.values, total eth.
I'm going to let it just iterate over this a couple of times.
It's checking the types from the SDK.
Okay.
Balance.raw amount is I think what we want
raw amount format ether, it's no longer trying to do the big int conversions.
This should have made some of those go away.
And then the only one is this,
which should be fixed with a simple enforcement of existence.
There it is.
Looking pretty clean.
Unsafe. unsafe.
Let's see what is going on with that error.
And for the types, we can fix by explicitly typing.
Okay.
If it just doesn't like the types,'s uh well let's see what it did
continue let's see what it does if it does anything more than like a one-line change i'm just gonna ignore this error because it's just a type error and i don't care about it especially
for an error but let's see if it's able to do cleaner code changes than what I would have suggested in my own change.
Let's reject this.
And did it fix here? No, it did not.
Quick fix, disable for this line.
And boom, that was a one line change.
And while we're here, let's delete.
Let's find anywhere where we're hard coding eth at 3K.
And let's set that inside of our constants file.
Can you please find any instance where we are hard coding ETH at $3,000?
And please move that value into a const file so it is easier to maintain across multiple files
that are defining this hard-coded eth value.
Can you please find any instance
where we are hard-coding eth at $3,000
and please move that value into a const file
so it is easier to maintain across multiple files that are finding this hard-coded
value i think that's what i said i don't know where we got italian
We're getting close.
Hi, princess.
Hey, baby.
Hi, baby.
Now it's going to update the use lifetime earnings hook to use that.
And then I also would love it to fix it any other place. Stake, fetch token, hi baby.
Is this the only place where you hard-coded it?
Okay.
Yeah. only place where you hard-coded it okay yeah that sounds correct is this hook already being used to display the lifetime earnings for the connected
wallet on the webpage page And then I think everything inside of this use memo can get defined inside of a standalone
lib. Yeah, I don't think it's being used anywhere. Do we not already have a lifetime earnings component?
Okay. Do we not already have a lifetime earnings component?
Lifetime earnings and then lifetime earnings.
We didn't already have a folder for these components.
ABI app.
No, there's a high-level components folder.
Earnings page. I'm confused.
Earnings page then renders earnings page.
Where's earnings page already there?
What was changed here?
Earnings summary.
Earnings page was using earnings summary.
Let's reject.
Whoa, where did it go?
Earnings page, we're going to roll back these changes.
Earnings summary.
I guess lifetime earnings does make more sense.
So we've got lifetime earnings.
Please make minimal changes to this page in order to use your new component.
There were a lot of changes in this pull request so far.
Collaborators dropdown has been deleted.
Why are we doing all these changes?
We deleted a ton of files inside of the earnings folder.
undo undo anything that was deleted I'm just gonna add back in it's like why
Undo.
Undo.
did it make so many changes releases table is missing
table is missing. Okay, let's add the changes I want. The page. Sure, that looks fine. Earnings
page. Also fine. Lifetime earnings is a new component.'s add that and then i think the rest use
lifetime earnings hook price is constant file providers is now wrapping the splits provider
from a new location splits provider was moved to providers and we removed it from the components file
and we removed it from the components file.
Split button.
split button
The rest of these we wanna discard.
All right, and instead of lifetime earnings,
are we using lifetime earnings?
For contracts and token infos.
We're using the account.
And now I would like all this to be a standalone lib.
Is it possible to move the selected code into a standalone library file?
That way we don't need to wrap it in a use memo hook.
Would that actually allow us to remove it from a use memo?
The single responsibility principle more closely.
Yes, we can extract the earnings calculation logic
into a separate library file.
This will improve code organization
and make the hook focus solely on managing state
and data fetching.
Calculate lifetime earnings.
Where is this being added?
It's being added inside of.
There's a lib with earnings.
This file just got way shorter.
But calculate lifetime earnings seems like it has errors please fix the errors
in this file in a concise manner making the minimum amount of changes and
leveraging existing type from the 0x Attempt number one.
Attempt number one.
Does this have any types? E aí Starting to wonder if I made a mistake by trying to move this into a hook.
into a hook. Use lifetime earnings. Let's try going right into the hook. What is being returned inside of the use earnings by contract?
I'm not seeing the return type.
Let's try to dig into what we're using because it returns formatted user earnings by contract.
So then inside of calculate lifetime earnings, user earnings should be formatted user earnings
by contract. Can we import this?
Import. Boom. No, it's not exported.
No, it's not exported.
Well, let's users' earnings by contract is returning this.
It says export type.
But I guess it's not exported where we need it.
Is format earnings by contract.
Hmm. where we need it is format earnings by contract
types
how do we get the types?
It's defined right here.
Let's try using that right here.
No, not there.
Inside of here.
And so if we do it here, is that going to work?
Hmm.
Cannot find.
I'm fine with that.
Let's see if we can install it.
Let's open up with command J, our terminal.
And now we can say pmpmi, paste in the package name we're working through type errors using the 0x splits SDK we've so far figured
the hook that we want to use I have done zero testing for this looks like we've so far figured the hook that we want to use, I've done zero testing for this.
Looks like we've just added it, but I'm still seeing the error.
So I'm going to, oops, that was hot.
Comment it out, wait till the red line goes away, comment it back in, save.
Still, still saying you can't find it.
So let me try finding the package.json.
We should see the package.
Hmm, types.
What's the correct way to install this package.
It seems weird to me that named the package types instead of the actual package name. We already have, which should include the necessary types.
Yeah.
Let me check out NPM with that package.
Whoops.
I want this package. Whoops. I want this package. It looks like it should be inside of splits 0x splits.
Ah, we only have splits SDK React.
So let's try pnpmi, and then just get rid of the word types at the end.
And now we're going to install the actual SDK.
Yeah, let's definitely accept if it's making that change.
And now it should add the correct
path from the React package?
No, it does not.
Reject.
Now we should be good.
Now we're good.
This is not being used. Okay.
Contract earnings then is not being used,
which means that token balance is also not being used.
So what are we not liking?
User earnings on an error typed value what let's see what this
takes us to earnings by contract should be a value on it stop Be sure to reference the source types.
And the source types will be right here.
Let's close all the other files.
How many files have we changed?
Package.json, we installed those new files.
The hook is still being made changes on our lib as well.
Splits provider is being updated.
I think it's just being moved to a new location. E aí on an error typed value user earnings is being defined as formatted user earnings so it should
have earnings by contract earnings by contract confused is valid why are we still getting
these earnings formatted earnings by contract
we need to use the exact type structure.
What?
No. Confused.
Reject.
How can I fix this also undo this change
keep going back E aí on an error type value. Let's check out what this type is a little bit closer. Formatted user
earnings, withdraw, active balances. Formatted user earnings by contract has
formatted user earnings and earnings by contract. Formatted use earnings by contract. Should have earnings by contract.
What happens if I say that?
Or if I say that?
I don't know what's going on right now.
We're hitting type errors and I really don't care for type errors so let me just try to mute disable for this line
but we're still going to see it on everything else
for each contract earnings What is earnings by contract, formatted earnings by contract. Let's import it.
I've already told you.
Stop. stop. Okay, this wasn't throwing any errors before we had it inside of the hook. I know
I wanted to keep it simple, but right now it seems like this is actually causing more headache.
So I'm going to go back to the hook, and I'm just going to define it inside of the hook as it was where it was working.
Reject.
Now we've got it all inside of the file, but at least we don't have any more errors.
I would like to also uninstall that new package we added inside of package.json
let's find the change so that i can uninstall that package let's remove this pnpm remove
goal is to keep moving forward i was getting a little bit too pure in what I wanted out of the output.
And so now I'm just going to make it work.
Let's make it work first.
We can make it right later.
All right.
Let's add all these changes.
Fewer overall files changed.
Let's commit it with the roadmap and see if we get a successful deployment.
Let's keep moving forward.
Command shift O, roadmap.
Let's click into a file, command shift O, roadmap.
Let's get the text, lifetime earnings, copy this, it commit it push it add in an X and
let's start opening up the pull request we've got one more after this let's see
how we are looking let's go back to github go back to my pull request we
should have a new pull. Auto being prompted.
Name.
That doesn't make sense.
There we go. I really don't want Rami to ship that password that feels like a weird that feels like a band-aid instead of fixing the symptom I would prefer to fix the root cause
instead of putting a band-aid over the symptom and just adding a password instead
of using on-chain data from base the on-chain data from base skills way more robust with less
maintenance as opposed to adding a manual password protection that you need to maintain
it adds extra headache it centralizes not a fan
but it's not my company.
If they decide that they want to build it like that, best to them.
Often I'm not asked for an opinion, and if I'm not asked for an opinion, I'm not going to give it.
But right now we're on my live stream, and you're an hour and a half in, so if you're tuned in, this is deep into the recesses of my thoughts and i'm building so you get special access to hear how i'm thinking
quick call to action if you are tuning in and you're getting value out of this please click
the like button please retweet it so that more people can see how we're building a record label
in public on chain with base leave us a comment down below of if you're building a record label in public on chain with bass leave us a comment down below of
if you're building a record label any questions you have for how you can be implementing this
if you're an artist wondering how you can be getting instant payouts for your music instead
of waiting six months write down below that you're an artist and let everybody know your story
give us a retweet give us a follow give us a subscribe if you're watching on youtube
any buttons you
click on this video will help more builders see it more artists see it more record labels see it
so we can help the music industry get on chain by building more of the impra that musicians need in
order to build their career in the music industry in a sustainable way where they actually get paid
and can live from their art with fewer middlemen, faster payments, and more ownership
of the art that they're creating.
It seems like our build is going to be successful, so I'm going to start coming over here
and prepare the testing instructions by adding earnings.
instructions by adding earnings test here it's going to give me a preview I'll close the preview
let's close that preview all right just finished deploying I'm going to try refreshing. Hopefully it resets to zero.
Moment of truth.
Application error.
Let's see what the error is. Nothing helpful here. We're seeing error loading earnings, lifetime earnings.
If error.
In the case of an error, instead of showing error loading earnings, please show the normal lifetime earnings component.
there is no connected wallet, we should show instead of the lifetime earnings component,
a connect button to prompt the viewer to connect their wallet in order to see earnings data.
In the case that there is no connected wallet, we should show instead of the lifetime earnings
component, connect button to prompt the viewer to connect their wallet in order to see earnings
data.
I want to fix this before I connect my wallet to verify that the experience is going to be
smooth enough for a musician to come in and use this. Right now, if we send a musician to this
page and all that they see is an error message, they're going to send a screenshot of this to
Coop. And Coop's going to come to me and say, an artist is saying they can't access their earnings.
What do they do? And so I just want
to not allow that to happen. If I'm trying to access the earnings page and I have not connected
my wallet, instead of showing an error, which is scary, this is normal behavior. And we would like
musicians to connect their wallet so that way they can see the earnings for their connected wallet.
wallet so that way they can see the earnings for their connected wallet
lifetime earnings yeah this component is getting longer I'm not super happy but
it did what I asked Joe connect button if while it is not connected in the lifetime earnings component.
In the lifetime earnings component,
close enough, a little bit of grammatic layers,
but I am not a grammar teacher
and these are commit messages.
Let's put in X, we've already done it. The only thing after this is going to be a withdrawal
button. But actually, I think it might have gotten fixed in this pull request.
Because usually there's a withdrawal button over here, which existed in the earnings
component, but we deleted the earnings component. I'm sorry, we deleted the earnings summary
I'm sorry, we deleted the earnings summary component, I believe it was called.
component, I believe it was called. Let's check over here.
Let's check over here.
No, we didn't delete it. It's still in here.
Let's delete it.
We want to find the components.
Earnings.
Earnings summary, this component, I believe, is no longer used.
Find it.
I don't see it being used anywhere.
You're going to get deleted.
Delete you.
Earnings summary, delete unused component.
Make sure to add it, commit it, push it. summary, delete unused component.
Make sure to add it, commit it, push it.
All right, coming back to our code review, we should be prompted to refresh now.
Now we go from seven files to eight,
including the deletion of earnings summary. The page, we just reordered the imports and used relative and absolute imports instead
of relative imports.
We replaced on the earnings page, earnings summary went to lifetime earnings to make it a little bit more clear.
Earnings summary was deleted.
Lifetime earnings was created.
Ooh, why are we using injected here?
What's injected being used for?
I don't like that we have injected there.
This is not correct.
Instead of building a new connect wallet button,
is there an existing component we could leverage
to reduce the amount of
duplicated code? Yes, please search.
I don't like that we're manually using the injected lib.
Let's give ourselves a little bit more space. Login button we can use.
Art uses Privy for authentication, has proper styling.
Sounds like you figured it out.
What time is my next meeting?
2.45.
Current time, 1.22.
We've now removed that injected.
I'm feeling happy.
Lifetime.. Connect button. Commit and sync.
We could definitely be optimizing this code. Thinking about it now, reflecting,
if we had started with the lifetime earnings
instead of starting with the rows,
we would have gotten the earnings using one single method
at the top highest level.
And we could have then passed all that information
down to the lower level components with fewer API calls needed in the lower level components.
Instead, I started with the individual rows.
And we're making additional calls inside of each row.
We're making a call.
And at the top level, we're doing an aggregate call.
And so there's some redundancy there with the top level call doing one single call
to get all the data.
And then inside of each individual row,
we are making an individual call for that individual row,
which scales by the number of rows that we have
for the number of API calls.
It makes more sense as we scale the record label
to have the one call that gives us all the data
and pass that data to the individual rows
with no calls happening in the individual rows for fewer calls faster page loads and code that's easier to maintain and easier to understand with
data flowing from the top all the way down instead of more queries happening at the lower levels
for now i've already built this i don't want to spend too much time on making it right.
We want to focus on just making it work first.
And as long as people don't complain about the performance,
it's not something that we need to worry about.
Lifetime earning, no comments in there looking good.
I don't like all the comments in here, so let's go to use lifetime earnings.
And delete this.
That's redundant.
Get earnings from split contracts.
Assert address is non-null since we will handle the null case in use memo.
Handle loading and error states,
add earnings from the split contract.
Withdrawn amounts for each token in the contract. Earnings from non-split contracts.
Skip if contract uses splits.
If wallet is direct recipient, add full earnings.
Okay.
Save the changes. save the changes add the changes remove use lifetime earnings Let's resolve.
This is the main change, is this hook.
Added the consts, moved the provider to where it's supposed to be.
Updated the split.
Looking good.
Let's monitor the deployments to see when we can start to test this.
We're building.
What was the last deployment that happened?
Deleted unused component.
Show connect button.
I think we should be good to test.
Let me try to refresh this page. I'm hoping now instead of showing this error, we show the actual login
button. Connect wallet to view earnings. I click the button. I don't like that it's trying to use the injected wallet here.
Let's see what the latest.
Okay, so in this latest deployment, we're going to be using a newer connect button.
You can see here it's trying to manually just use an injected provider, which is not what I want.
I want it to open up Privy, which allows me to log in with whatever wallet I'm using,
whether it's a injected wallet, email wallet,
some other external wallet that's not injected. There's a lot of cases where we don't want to
just use injected. And that's one of the reasons we use Privy, is Privy allows us to have more a
dynamic login and authentication experience. So we want to be leveraging that instead of just using Wagme, which is a more bare bones implementation of authentication on chain.
You boys getting hungry. I would like to wrap this up.
I think this is the last PR I'm going to need to do for the day because we are,
this is also getting rid of the withdraw button over here.
We had a withdraw button before,
as we can see inside of our changes
in the earnings summary section i believe
earnings summary we expand that file
we can see in here we have the withdraw button which we don't even want so it's being deleted
we got two birds one stone and i think the final deployment has finished no it's still in process
no it has finished all right let's try it again refresh i'm hoping these buttons look the same
connect your wallet to view the earnings connect our wallet let's connect the phantom now we're using privy for authentication everything feels much
more robust and high quality than when we were just using wagmi
i need my login because phantom always needs me to enter in a password it's one of the things i
don't like about phantom connect already is loading in everything oh it looks like it had it still had errors
loading the total earnings
it says i should be getting prompted to sign
i'm prompting oh there you are confirm can I read properties of undefined reading ID on success We are connected.
We're no longer loading.
We got to the error state with an error.
Let's add logging console.log.
Right time earnings total earnings USD value is loading an error
Adding dev logging
I add temporary dev blogging
I've just added more dev logging, which is being deployed now.
Here's the current errors I see in the web console.
Please click on the web console. Please hit your scratch pad to consider these errors, which are resulting in a connected wallet seeing. you're going to take a screenshot of the page not including the console let's take this photo
and give it to the chat and let's let the chat start thinking through the errors while i'm
deploying a new change.
Keep me small-brained. All that I did was add in some console logging.
Let it do the deeper thinking. Let it do a build, see if I can get more info.
What happens if I refresh the page? Do we still have that error?
Maximum number of calls is not the error.
Well, it should already be connected.
So I'm surprised it's asking me to connect again, but I guess let's do it. User is already logged in.
Is connected is coming from use account.
We don't want to use use account here we want to be using privy
nope
don't be making any of those changes i just wanted you to investigate lifetime earnings
um i don't remember what i was doing i got distracted
current issues that we're seeing errors we're not seeing the loaded component
and I would like instead of let's go to lifetime earnings
please use the privy sdk instead of use account hook to determine whether to show the connect button.
Please use the previous SDK,
okay, instead of the use account hook
to determine whether to show the connect button.
I think we want the same thing here.
The oath. update both the component and the hook and I'll a reference at privy.
How are we doing on deployments?
Looks like our latest has been deployed. Let's see if we get any better logs.
Inside of my component, i've added logs and so
let me filter by the prefix i have added lifetime earnings this should show me the specific
logs i'm looking for use privy authenticated if not authenticated that looks beautiful
if not authenticated, that looks beautiful.
Okay, I'm still seeing the error,
and I'm also not seeing my logs.
That's concerning.
It's very concerning because I see a component
see a component which should be showing me the logs.
which should be showing me the logs.
Let's try refreshing the page.
And I think we might already have a useWallet hook.
UseWallet. We have a use wallets hook. Use wallet.
We have a use wallet client.
Yeah, we want to use this.
And this is probably good.
This is probably good.
I don't need to overthink this too much.
I don't need to overthink this too much.
Use privy SDK instead of wag me hooks to determine if wallet is connected.
Commit.
Sync.
Very concerning I'm not getting any logs
with a few guts the poison pack that's the remedy the remedy is the experience
I've added the logs I'm not seeing I had temporary devlogging 625 is that where we're at we're at 625 why am I not seeing
the dev logging I've added let's try just clearing the filter What's the issue?
Error loading earnings.
I'm not seeing any of my logs.
Are they inside of logs?
On the server side?
It's found 3,000 logs.
Stake, a whole lot of endpoints.
All right.
The question is why?
Why are we seeing air loading earnings?
Use lifetime earnings.
Use user earnings by contract, chain ID, user address address and then contract addresses and so then we need here Contract.com track to address that already looks better
What happens if I remove that no still showing air
What other options do we have I
Think that's just it. I add array of contract addresses to use user earnings by contract.
it's commit but before I push I would like console dot log user earnings
loading and air use lifetime earnings dev logging commit sync how we doing on latest deployments any big changes over here privy sdk was just finished
and now dev logging for use lifetime earnings let's try refreshing the page delete all the
logs see if we get any logs that are helpful.
Now I'm not seeing the table even. Let me try refreshing.
That's weird.
Let's see what changes I made.
Lifetime earnings was updated.
Use lifetime earnings was updated, but nothing related to the table what about here why is our table now not working is my question oh there there it is
it just needed some time I guess but I'm still not seeing any of the dev logging i've added
very confused as to why i'm not seeing any dev logging
because we're getting to this is error so it should be hitting all these console logs, but it's not. Curious. All right, we're in the deployment step. I'm going to try it on a new page, a new tab.
Let's go to forward slash earnings. E aí Okay, we're still getting the error.
Am I seeing any logs?
I'm not seeing logs.
I might need to debug this locally.
Wrapped error retries exceeded.
Uh-oh, my mouse is stuck.
I think I can... so
so E aí major lag between and it appearing on my terminal sentence after I typed in pmdev and now it is finally it's a big I'm not hearing my all which is weirdly when I'm live streaming it's
so I think I need to end the stream and start my computer because this is stopping me and
stopping me and i'm going to be test this locally so what has been changed
I'm going to be test this locally.
So what has been changed?
we start today's stream with a page that did not get the connected wallet and
showing how much is being earned which songs to display
We have since updated the past two hours, we've updated this page on Couprex, our base
on chain to only in the last step that I'm working, showing the total earnings to be
across the protocol.
I'm ending the video now.
So do some debug.
Okay. call. I'm ending the video now, so do some debugging locally without the burden of the server that is running when I use Restream. If you got any value in this video, as always,
please click the button, leave a comment below, give us a follow or a retweet, depending on the platform you're on, and I'll be back in a couple hours with
