avi12 / youtube-time-manager-feedback

The place to give YouTube Time Manager feedback.
3 stars 0 forks source link

Syncronization across devices [Suggestion] #10

Open it0na72 opened 5 months ago

it0na72 commented 5 months ago

Is your feature request related to a problem? Please describe

No issues so far. Just wondering how feasible would it be for this to count towards videos watched on mobile or multiple computers. image

Is it a change to the extension's functionality or to the pop-up settings page?

Extension's functionality

If the latter, please propose a new design on Figma or describe it as detailed as possible

No response

Additional context

No response

avi12 commented 5 months ago

Synchronizing with mobile vs synchronizing with other browsers are different procedures programmatically

Synchronizing with mobile requires retrieving data from YouTube API(s) (e.g. YouTube Analytics API), which will cost me money

Synchronizing with other browsers is quite easy for small amounts of data (with chrome.storage) However, for larger amounts of data (>8KB), like in this extension's case, I'll need to resort to using some backend system + database, which will cost me money

Therefore, data synchronization will be a paid feature

avi12 commented 5 months ago

So far dealing with back-end, payment processing, and databases seems overly complicated to me, so I decided to return to it later when my mind is ready to tackle the challenge I would rather wait to implement paid features than implement them incorrectly

Niborian commented 5 months ago

Cant you use the built in "screen time" function of samsung/android phones to just look at how much youtube is used? and for larger amounts then 8KB is that always since thats just a max per item so you could just devide it up then send it? (its 102,4KB max in sync storage). (im not a pro, but if im not wrong then with this method you should be able to add about 5.52 entries containing the channel information, time spent, and a timestamp. (1 year = 102.4KB) and if you sync every time the "buffer" reaches 6KB or when paused then it can sync it without every getting above the 8KB. Also after 1 year of data you can make it save : time watched, top 3 youtubers (time per) and it wouldent eat up that much space, ofc paying would make the limitations much less a problem, but then people can choose for their needs. Im happy to try to help if you want me to :)

avi12 commented 5 months ago

My goal is not only to allow synchronization between Chromes but also between Google accounts E.g. a user uses Chrome on computer A and Firefox on computer B, and he will log into the ext with his Google account to synchronize between the browsers chrome.storage.sync's purpose isn't to store data but rather user preferences

Niborian commented 5 months ago

if you auto delete data every 3 years (from the sync) (able to download data for year 1 and 2, until year 3, then it deletes the data for year 1 and 2, and then the same happens when year 3, 4 and 5 is done then it deletes 3 and 4) with an approch like this you would have to watch:

5 minutes long:

Hours per day: Approximately 0.38 hours Videos per day: Approximately 0.38 10 minutes long:

Hours per day: Approximately 0.76 hours Videos per day: Approximately 0.76 15 minutes long:

Hours per day: Approximately 1.14 hours Videos per day: Approximately 1.14 20 minutes long:

Hours per day: Approximately 1.52 hours Videos per day: Approximately 1.52 25 minutes long:

Hours per day: Approximately 1.90 hours Videos per day: Approximately 1.90 30 minutes long:

Hours per day: Approximately 2.28 hours Videos per day: Approximately 2.28 1 hour long:

Hours per day: Approximately 4.56 hours Videos per day: Approximately 4.56

Okay, this dosent account for that but I will send it anyways😅

avi12 commented 5 months ago

Deleting data is not a desired behavior whatsoever Moreover, I updated the ext after being in maintenance for about 7 years and long-term users were desperate to get the old ext data

Niborian commented 5 months ago

well yes I see that, just a idea to keep it free, you could add a paid and a free version where the free one deletes every now and then and the paid one saves data for x amount of years, I did some googeling and found this information:

you can replace chrome.storage.sync and expand your syncing capabilities across browsers using Google accounts, for free:

Firebase Realtime Database: The free Spark plan offers 1GB of storage and up to 10GB/month of data transfer, should be more then needed for this use

Firebase Authentication: Including OAuth2 integration with Google accounts, it's free for unlimited users, making it great for managing user logins across different browsers.

Google Cloud Firestore: In the free tier, Firestore gives you 1GB of storage, 50,000 reads, 20,000 writes, and 20,000 deletes per day.

avi12 commented 5 months ago

You are 100% correct, but it is more challenging than I imagined to use Firebase from within an ext In addition, since Stripe isn't supported in my country, the only way to charge money is through PayPal, which comes with a whole bunch of difficulties like having to set up a website dedicated to retrieving a recurring payment from the user Also, I have no experience with databases or managing users and I wouldn't want to mess it up

While trying to make sense of the backend, I also realized another difficulty: suppose a computer has multiple Google accounts stored and the user accidentally selects the wrong account and starts a subscription; in that case, I also need to implement a mechanism to transfer the data from account A to B

I wonder if there are more edge cases to think about, which, considering that I'm not experienced with the backend, suggests to me that I should probably pay for a freelancer to set the backend up

Niborian commented 5 months ago

What if you start trying with the free stuff I sent and when thats working you can then think about adding the paid subscriptions for your service :)

heres a simple explaination for how you could use paypal to be paid for the subscribtion :)

Create a PayPal Business Account: If you haven't already, you'll need to set up a business account with PayPal to access their subscription services.

Set Up PayPal Subscriptions:

Create Subscription Plans: Use PayPal's dashboard to define your subscription tiers, pricing, and billing cycles. Integrate with Your Extension: PayPal provides APIs and SDKs to integrate payment features directly into your application. For a Chrome extension, you'll likely use PayPal's JavaScript SDK to add a subscription button or payment flow to your extension's user interface. Handle Subscription Verification:

When a user subscribes, PayPal sends a notification to your backend server (using webhooks), confirming the subscription's start. Your backend then updates the user's status to "subscribed" in your database, unlocking the paid features in your extension for that user. Manage Subscriptions:

Use PayPal's webhooks to listen for subscription cancellations, renewals, and payment issues. Update the user's access accordingly in your backend. Simplify Access Control:

Implement a simple authentication mechanism (e.g., OAuth with Google) to link the user's subscription status to their Google account used in the Chrome extension. This way, you ensure users can access the paid features across multiple devices or browsers as long as they use the same Google account.

avi12 commented 5 months ago

Thank you for your information, but how about the database architecture? How should the data be stored?

Niborian commented 5 months ago

Well you can set up a 3NF database thats supposed to be really good setup, I make one in sql workbench and send a picture as an example, just give me some time😅

Niborian commented 5 months ago

Example Heres an example, im not 100% sure if I did everything 100% correct (it will work, but if its in 3NF is something else) but this should give you an idea

avi12 commented 5 months ago

I feel like it would be better to use NoSQL (like Firestore) to make the database flexible

Niborian commented 5 months ago

Yes thats probably smart, I just have sql workbench already so I made an examlpe there, and since you wanna use NoSQL then you dont need the data to be structured, I can try to make that to if you want me to help you with this :)

avi12 commented 5 months ago

I would love that In general, there are two kinds of data that need to be stored:

  1. The ext data
  2. Data that`is fetched using the YouTube Analytics API AFAIK there is no way to get detailed data from YouTube's server, i.e. the API only provides a number representing the amount of minutes spent watching YouTube at a given day, without a channel distribution data
Niborian commented 5 months ago

Okay, I will take a look at that, migth take a while due to other things I need to prioritize :). if you could break down the data even more that would be nice?

avi12 commented 5 months ago

That's the thing, I'm not sure what exactly needs to be stored The ext data structure is the same as what's exported from the data when you click "Export data" from the extension popup I don't know what's the structure of the payment information; I suppose that the YouTube server data will have a similar structure to the ext data, i.e. timestamp and then amount of minutes spent that day

Niborian commented 5 months ago

This is the start of it, do you see something missing or not needed?

Collections and Documents Structure Users Collection

Document ID: Automatically generated or use UserID. email: User's email address. googleAccountID: Identifier from Google OAuth. subscriptionStatus: Active, Pending, etc. Subscriptions Collection

Document ID: SubscriptionID. userID: Reference to Users Document ID. planID: Basic, Premium, etc. startDate: Timestamp. endDate: Timestamp. status: Active, Cancelled, etc. Payments Collection

Document ID: PaymentID. subscriptionID: Reference to Subscriptions Document ID. amount: Number. paymentDate: Timestamp. paymentMethod: PayPal, etc. status: Completed, Failed, etc. YouTubeData Collection (To store data fetched from YouTube Analytics API)

Document ID: Automatically generated. userID: Reference to Users Document ID. date: Timestamp for the day. minutesWatched: Number of minutes watched that day. ExtensionData Collection (To store data exported from the extension)

Document ID: Automatically generated. userID: Reference to Users Document ID. timestamp: When the data was exported. data: This could be a structured object or an array containing the details of extension usage, similar to the YouTubeData structure.

avi12 commented 5 months ago

That's a great start! Some paid features that were yet to be added:

Niborian commented 5 months ago

So like this:

Collections and Documents Structure Users Collection

Document ID: Automatically generated or use UserID. email: User's email address. googleAccountID: Identifier from Google OAuth. subscriptionStatus: Active, Pending, etc. Subscriptions Collection excludedChannels: Array of strings. Each string is the ID or name of a channel the user wants to exclude. excludedPlaylists: Array of strings. Similar to excluded channels, but for playlists. Goals Collection

Document ID: Automatically generated or a specific GoalID. userID: Reference to Users Document ID to link the goal to a specific user. description: A textual description of the goal, e.g., "Spend 60% of the following week watching math content." targetPercentage: The percentage of time the user wants to dedicate, e.g., 60. contentArea: The subject matter or category of the content, e.g., "math." timeFrameStart: Timestamp marking the start of the period for the goal. timeFrameEnd: Timestamp marking the end of the period for the goal. TimeLimits Collection

Document ID: Automatically generated or a specific TimeLimitID. userID: Reference to Users Document ID. dailyLimit: Maximum number of minutes the user wants to spend daily. weeklyLimit: Maximum number of minutes for the week. specificLimits: An array of objects, each containing dayOfWeek (e.g., Monday) and limit (minutes) to allow for different limits on different days.

Document ID: SubscriptionID. userID: Reference to Users Document ID. planID: Basic, Premium, etc. startDate: Timestamp. endDate: Timestamp. status: Active, Cancelled, etc. Payments Collection

Document ID: PaymentID. subscriptionID: Reference to Subscriptions Document ID. amount: Number. paymentDate: Timestamp. paymentMethod: PayPal, etc. status: Completed, Failed, etc. YouTubeData Collection (To store data fetched from YouTube Analytics API)

Document ID: Automatically generated. userID: Reference to Users Document ID. date: Timestamp for the day. minutesWatched: Number of minutes watched that day. ExtensionData Collection (To store data exported from the extension)

Document ID: Automatically generated. userID: Reference to Users Document ID. timestamp: When the data was exported. data: This could be a structured object or an array containing the details of extension usage, similar to the YouTubeData structure.

avi12 commented 5 months ago

What if a user accidentally logs into the wrong Google account, starts a subscription, and realizes his mistake? Is there a safe way to let him migrate his data to another entry in the database? Also, what's the safest way to upload the data to the server?

Niborian commented 5 months ago

I would expect that accidently starting a new subscription is a longer process then just logging into the wrong email... would have to add paypal or someother method to pay then pay.. should be enough "hint" to understand that they are on the wrong mail.... also could just refund the user if the user doesnt use the service on the wrong mail

avi12 commented 5 months ago

Honestly, I don't want to deal with refunds If the user starts a subscription, he pays immediately and if he regrets, it's too late - he can only cancel the subscription

Niborian commented 5 months ago

Well then you have to write that in the "payment contract" since theres a law (atleast in my country) that you have minimum 14days to regret your purchase... you can just make a automatic checker that says if its used more then 2h (current month) then its not refundable and it works 1time per email. its easier to get people to pay if they know they can try for 2h then stop if they dont like it. again this has to be in the contract since its not 14 days.

(I dont know how this works, but I think this is correct😅, anyways I have a way better experience with services that I could refund if I dident like) but we can look closer into this when we are gotten that far😅

avi12 commented 4 months ago

I'm working on a prototype that uses Firebase @Niborian When it's ready for testing, would you like to try it out?

Niborian commented 4 months ago

Sure, just send med a direct msg when you want me to test😁

avi12 commented 4 months ago

Add me on Discord: avi12

avi12 commented 4 months ago

@Niborian Hey man, could you help me with the db stuff? Ping me on Discord