"Livestream-to-earn" Template Publisher App

[criticaltv]

Introduction

This issue is to define the minimum viable product for a MVP "Livestream-to-earn" Template Publisher App.

MVP stands for "minimum viable product", and represents the minimal feature set to achieve the objective.

A Template App is a body of code which can be used to publish an app, configured for a specific situation. This allows a base level of functionality to be replicated by anyone for their specific circumstance.

"Livestream-to-earn" is the act of livestreaming, and at the same time being paid by anyone who is consuming the livestream.

Example Usage

For example, the Template can be used by Ethereum Football Club to publish the Ethereum FC Livestream-to-earn app.

This would allow any spectator at an Ethereum FC match to livestream the action, and get paid in Ethereum, by anyone who is watching.

Scope of Functionality

The app should allow the User to:

• Publish video and audio from their device's camera and microphone

• See the video which is being livestreamed

  • on their device's screen

• Monitor for payments from "pay-to-play" consumers

  • to an Ethereum wallet created by the app

User Journey

Screen 1 - on launch:

The following user interactions are possible:

• Tap the Camera Thumbnail "You" in the bottom right to go to Screen 2
• Tap the Hamburger Button to go to Screen 4
• Tap the x to close the app

Screen 2 - go live:

The following user interactions are possible:

• Tap the Hamburger Button to go to Screen 4
• Tap the x to close the app

Screen 3 - receive first payment:

The following user interactions are possible:

• Tap the Hamburger Button to go to Screen 4
• Tap the x to close the app

Screen 4 - more information (overlay)

The following user interactions are possible:

• Tap the "Copy Private Key to clipboard" to copy private key to clipboard
• Tap the "Copy Ethereum address to clipboard" to copy Ethereum address to clipboard
• Tap the Hamburger Button to go to hide overlay

Layout

The layout of the app should be as defined below.

The app must be implemented to these specifications in order for this issue to be closed and bounty to be paid out.

Base Canvas (9x16)

The app as designed above requires a canvas on a device with a 9x16 aspect ratio - such as 2160x3840, 1080x1920, 720x1280 or 450x800.

If the device has a screen with a 9x16 aspect ratio, laying out the app should be trivial.

If the device does not have a screen with a 9x16 aspect ratio, the app should allocate an appropriate frame with a 9x16 aspect ratio on the device's screen for the app to operate in. Laying out the app should then be trivial.

On Launch Layout

Livestreaming View Layout

Livestreaming View Detailed Layout

Layout Components

Header Bar (9x1)

The artwork for the Hamburger Button and x will be provided during the implementation.

Wallet Bar (9x1)

The two lines of text should be the same length (which will require different font sizes).

The two lines of text should be aligned in the centre of the panel, with appropriate padding / spacing.

Live Camera Panel (9x9)

The "live" text should be displayed over the camera feed, to tell the user that they are live.

The microphone level monitor should show if sound is being detected by the microphone.

"You" Panel (9x2)

Note: the price per minute should be set as a default in the app template.

Note: the "set your price per minute" function should be inactive (for now). This will require some further integration with the Consumer app.

Broadcaster Node Bar (9x1)

The Broadcaster Node is the server receiving the livestream from the user, and distributing to consumers.

They are responsible for running the broadcasting server. They will not receive any income from consumers in this phase.

Live Stream Selector Bar (9x2)

App Specifics

No Internet Connect

In the event that the device does not have internet access to the RTMP endpoint or the ETH endpoint, the app should still launch successfully, activate the camera, and allow a user to select "You" to go live.

In this instance, the app will not be able to retrieve the wallet balance, and will not be able to go live.

The app should be able to gracefully handle the situation when it is unable to either a) reach the RTMP endpoint, b) reach the ETH endpoint, and to report these errors to the user.

Disconnection

In the event that the livestream fails for any reason, the app should handle this gracefully, and inform the user that they are no longer live.

In this instance, the app should return the user to Screen 1, with an appropriate error message.

Configuration of template

The following parameters should be configurable by a user of the template, when creating the app:

Copy

All copy, e.g. error messages, titles, hamburger button content should be configurable in the template.

Broadcaster Node settings

• RTMP endpoint for publishing content to, e.g. rtmp://89.145.161.141:1935
• ETH Address for display in UI, and in future, to receive payment

Payment settings

• ETH endpoint (e.g. infura)
• Default "price per minute"

AV settings

• Keyframe interval e.g. every 60 frames / 2 seconds
• Maximum Video Stream Bitrate e.g. 2000kbps
• Maximum Audio Stream Bitrate, e.g. 320kbps

Specific Deliverables

Code should be written in pure Kotlin, and should make use of existing open-source libraries wherever possible.

The following specific deliverables are required for this issue to be closed and any bounties paid out:

• Sample app generated from template:

  • .apk file for debug purposes
  • .apk file signed for release to e.g. Google Play Store or FDroid.

• Merged PR to this repo containing:

  • Template App codebase
  • Project which can be imported to Android Studio
  • Documented process for generating an APK from template, e.g. which configuration files to edit to change config

Resources

KEthereum

Kotlin RTMP Library

videoDAC's Streaming Back-End

[gitcoinbot]

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

---

This issue now has a funding of 600.0 LPT (294.12 USD @ $0.49/LPT) attached to it as part of the videoDAC fund.

• If you would like to work on this issue you can 'start work' on the Gitcoin Issue Details page.
• Want to chip in? Add your own contribution here.
• Questions? Checkout Gitcoin Help or the Gitcoin Slack
• $97,480.39 more funded OSS Work available on the Gitcoin Issue Explorer

[criticaltv]

Hi @psudoanon thanks for applying.

Let me know if you have questions about setting up the Streaming Back-End to test against.

[gitcoinbot]

@psudoanon Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!

• reminder (3 days)
• escalation to mods (6 days)

Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days

[psudoanon]

So far I've gotten the basic application architecture setup, finished reviewing the linked Kotlin RTMP library and implemented permissions handling; I'll be making a small update to the RTMP module in order to make the keyframe interval configerable before proceeding to the wallet generation and testing with a local backend

[criticaltv]

OK cool.

Do you have any blockers that I may be able to help with?

[psudoanon]

@criticaltv

I'm running into an issue with the streaming backend.

Followed the setup instructions for the precompiled binary and it works fine when using FFMPEG to send a test broadcast signal to the RTMP endpoint.

Once I try sending a video signal from the Android app and linked RTMP library I get the following SegmenterTimeout error:

Any ideas on what might be causing this? The signal being sent is H264 AVC at 30FPS

[criticaltv]

We sometimes get this when it doesn't send a keyframe...

[psudoanon]

Thanks, yeah looks like that was it :)

…

On Wed., Apr. 22, 2020, 2:17 p.m. criticaltv, ***@***.***> wrote: We sometimes get this when it doesn't send a keyframe... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#31 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOZ6FUJZGV5U4CI6MJPRQNTRN4YFDANCNFSM4LDOTFXA> .

[criticaltv]

OK @psudoanon - that's reassuring to know that you've resolved that one.

Keyframe interval is a regular "thorn in my side", which is why it was specifically called out in the spec.

You may also wish to have a look at these simpler instructions for a streaming system - they use the same base software as Streaming Back-End, but much much simpler: https://github.com/videoDAC/simple-streaming-server/

Do please let me know if you hit any more blockers. Hope you're well

[gitcoinbot]

@psudoanon Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!

• reminder (3 days)
• escalation to mods (6 days)

Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days

[gitcoinbot]

@psudoanon Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!

• reminder (3 days)
• escalation to mods (6 days)

Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days

[psudoanon]

Hey, sorry for the delay. Ended up having to go through a couple different RTMP libraries before finding one that worked reliably; just finishing up the wallet generation side of things and then I'll have a PR and the associated resources all generated and uploaded :)

…

On Mon., Apr. 27, 2020, 12:15 p.m. Gitcoin.co Bot, ***@***.***> wrote: @psudoanon <https://github.com/psudoanon> Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions! - reminder (3 days) - escalation to mods (6 days) Funders only: Snooze warnings for 1 day <https://gitcoin.co/issue/videoDAC/android/31/4223?snooze=1> | 3 days <https://gitcoin.co/issue/videoDAC/android/31/4223?snooze=3> | 5 days <https://gitcoin.co/issue/videoDAC/android/31/4223?snooze=5> | 10 days <https://gitcoin.co/issue/videoDAC/android/31/4223?snooze=10> | 100 days <https://gitcoin.co/issue/videoDAC/android/31/4223?snooze=100> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#31 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOZ6FUK24NYLKYJ4OHJAW5DROWVS5ANCNFSM4LDOTFXA> .

[criticaltv]

@psudoanon thank you for your continued efforts on this - much appreciated.

Looking forward to seeing what you have made :)

[gitcoinbot]

@psudoanon Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!

• reminder (3 days)
• escalation to mods (6 days)

Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days

[gitcoinbot]

@psudoanon Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!

• reminder (3 days)
• escalation to mods (6 days)

Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days

[criticaltv]

Hello @psudoanon sorry about the gitcoin bot.

Is there anything I can do to help with the template app build?

[psudoanon]

No worries, I'll have a PR up soon and then you can verify it builds locally on your end :)

…

On Mon., May 4, 2020, 1:56 a.m. criticaltv, ***@***.***> wrote: Hello @psudoanon <https://github.com/psudoanon> sorry about the gitcoin bot. Is there anything I can do to help with the template app build? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#31 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOZ6FUKYMGC4QN3Z62FCZDLRPZKHDANCNFSM4LDOTFXA> .

[psudoanon]

Hey @criticaltv

I've filed a PR here: #45

Do you mind taking a look and making sure you can import into Android Studio as expected?

As far as the APK deliverables go, where would you like the RTMP base URL set to? The application is also using the Infura API. I was using a personal API key I generated while developing - did you want to setup your own?

[criticaltv]

@psudoanon thanks I'm trying my luck with it now.

Is there an email address I can get you on to share the RTMP endpoint, it's a little sensitive :)

[psudoanon]

Yeah, you can send it to adam.allidina@gmail.com :)

…

On Sat., May 9, 2020, 6:35 a.m. criticaltv, ***@***.***> wrote: @psudoanon <https://github.com/psudoanon> thanks I'm trying my luck with it now. Is there an email address I can get you on to share the RTMP endpoint, it's a little sensitive :) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#31 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOZ6FUI52XPMGHSEZ6V2Z3DRQUWYFANCNFSM4LDOTFXA> .

[criticaltv]

Hey, so, I've managed to generate an apk from the code, using Android Studio - which is cool.

Some initial feedback:

• I've managed to get the app connecting to a local instance of simple-streaming-server - which is great!

• The screen goes dark, per the system's screen time-out setting (in my case 15 seconds!) - and when this happens, the streaming stops also. The app should take over the entire screen, and keep hold of it until the user taps the screen to close the app.

• The UX / UI doesn't seem to follow the principles set out in the original issue:

In essence, the objective is to limit user interaction down to:

• tap app launcher = start streaming
• tap screen = stop streaming.

...and nothing else.

So, the following are unnecessary for the user and can be removed:

• "Start Stream" button - streaming should automatically start when the app is launched
• "Stop Stream" button - streaming should continue until the user taps the screen to close the app, and copy the private key to clipboard.
• Flash button - the flash should automatically turn on, by default

I know that this approach might seem unconventional - but I am really trying to simplify things for an end-user, and to make the UI as uncluttered as possible.

• Also, it looks like the camera feed on the screen is being squashed somehow (the red thinkpad button is exactly circular, but here appears oval):

• The wallet functionality stuff is excellent - it imports to MetaMask perfectly (as you'd expect!). And the connectivity to infura also works for retrieving the balance... the Private Key stuff is dangerous, but also interesting for those without anything to lose...

Other UI stuff:

• The app should take over the entire screen - including the Android OS bar at the top with the time and the battery indicator and the wifi / mobile signal indicators etc.
• The purple bar with "Livestream to earn" at the top isn't necessary, this can be removed
• When closing the app, it would be good to have a subtle android system level notification saying "Wallet private key copied to clipboard"
• There's no need to include any logic to switch orientation - I'm happy for this to default to landscape for now.

So, in essence, it should look like this to the user at all times:

such that the only action required from a user is to "tap screen", and the app takes care of the rest.

(I acknowledge that the "LIVE" indicator was not in the original specification, so feel free to raise an issue for this, and I will add a new bounty to it, if you would like. This should perhaps be grey if the device is unable to connect via RTMP...)

But I'm really pleased with the progress... and with a few simplifications, it could be really interesting to play with.

[criticaltv]

Some other thoughts - for future scope, future issues, future bounties - just spitballing:

• Perhaps display the user's Ethereum address with the balance, so that they can see who they are

• If the app can't connect to the rtmp endpoint, perhaps show a subtle android notification error message like "Check your internet connection"

• Perhaps replace the "Broadcasting to rtmp://..." subtle notification with something like "view your livestream at http://livestream2earn.com/stream/0x62CD952fEa913116F304C89e24c0E2181682048C" or similar. This may be too complex for now, but worth considering for future.

[criticaltv]

Also... when you switch the orientation of the device, this appears to kill the stream... steps to reproduce:

1. Hold device in landscape
2. Press Start Stream (which turns into "Stop Stream") - content starts being received
3. Turn the device 90 degree to portrait
4. Button returns to showing "Start Stream"
5. Stream ends and rtmp endpoint reports SegmenterTimeout and ends stream
6. Press "Start Stream" again (which turns into "Stop Stream")
7. No content is received by the rtmp endpoint (presumably the app still thinks it's streaming, so doesn't actually start streaming again)
8. Press "Stop Stream" (which appears to put the app back into the state it was in originally)
9. Press "Start Stream" (which turns into "Stop Stream") - content starts being received
10. Keep device in landscape orientation - everything keeps working just fine :)

Hopefully this may all be fixed by the above requested removal of complexity associated with a) starting / stopping streaming, b) switching orientation etc.

[psudoanon]

Hey, I've finished addressing the issues you've mentioned and will have a new repo up soon with the updates

I've also added a new issue for the "Live" indicator #46, feel free to add the image resource to that ticket if you have one

Regarding the other functionality you mentioned, I'd be happy to work with you to get those featured implemented as well :)

[gitcoinbot]

@psudoanon Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!

• reminder (3 days)
• escalation to mods (6 days)

Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days

[psudoanon]

@criticaltv I've updated the PR with your requested changes, would you mind taking a look? Once we get everything finalized on this bounty I can get started with the "Live" indicator :)

[psudoanon]

@criticaltv have you had a chance to take a look at this? was wondering what your thinking regarding @mul1sh comment regarding switching the PR repository. thanks :)

[chrishobcroft]

Hi @psudoanon I am looking at this.

I'm trying to load it up in a clean install of Android Studio on a clean install of Ubuntu.

I'm hitting these errors when importing the project:

I will try to debug it, but if you have any pointers, I would appreciate them.

[criticaltv]

@chrishobcroft you need to enable some SDK stuff - see stpe 5 of this: https://github.com/videoDAC/pay-to-play/blob/master/APK/Import/index.md

@psudoanon I've managed to get a build running on a phone.

Some feedback:

1. The app won't open if the phone is held in portrait mode. It just crashes.

It succeeds at launching if the phone is held in landscape mode.

I would expect to be able to launch the app in any orientation. Hopefully it's a simple enough fix?

2. It seems much less processor heavy, the last version drank battery like a fish, and the phone nearly melted. This one seems subjectively less hot. I wonder if that's just circumstance.

3. The first time the app is launched (in landscape), it crashes...

Here's the flow of "calls to action" steps I observed:

• Start with apk in my file browser:

• Open the file, and see Android's installation script:

• Confirm the install, and see confirmation:

• Launch the app, and see a warning that the app has crashed:
  • It appears that immediately before this stage, the app crashes but then somehow restarts itself, hence prompting this warning.
  • I would expect it to skip this step, and show the requests for permission

• Click "Close App", and see the OS asking you to grant the app permission to take pictures and record video.

• Grant permission to take pictures and record video, and see the OS asking you to grant the app permission to record audio:

• Grant permission to record audio, and we're back to the file browser from the beginning.
  • At this point, I would expect the app to be streaming.
  • In the context, given the app has crashed, this is not unexpected.

4. Second time launch (i.e. after the permissions have been granted), the app launches successfully, and starts streaming into the endpoint.

5. There is some kind of interstitial page as the app launches - which flickers before the camera appears. I hope this might be easy enough to remove?

6. The app offered to report some kind of bug to something called blueline - do you know what this is?

7. The persistent notification about the Private Key being on the clipboard is a nice touch. The user needs to swipe it away, so it's harder for them to miss it! I have created an issue to track ideas for how to develop this further: What do we do about the Private Key on the Clipboard? #50

[gitcoinbot]

@psudoanon Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!

• reminder (3 days)
• escalation to mods (6 days)

Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days

[gitcoinbot]

@psudoanon Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!

• reminder (3 days)
• escalation to mods (6 days)

Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days

[psudoanon]

@criticaltv Thanks for the detailed bug report, hope to have an update ready for you this weekend. #50 looks good as well!

[psudoanon]

@criticaltv I was looking into the crash when launching the application in portrait mode, can you confirm that it only crashes when the Android system portrait lock is enabled? I think there are two ways we can go about fixing it:

1. If portrait lock is enabled, have a dialog pop up prompting the user to disable the portrait lock before continuing application setup
2. Allow for broadcasting in portrait or landscape, default to broadcasting in landscape if no sensor lock is enabled and respect system sensor lock settings if enabled

Do you have a preference?

[criticaltv]

My preference is for something more simple, and in fact, more rigid (and hopefully less complex!)

To give you a flavour, I suggest that you try out Alice's Pay-to-play Streaming app on a physical smartphone (not an emulator).

The app takes over the whole screen, fixing the content in the display. No matter how you turn your phone, it keeps the same orientation, even if you set the screen to "auto-rotate". It doesn't try to be clever, it stays fixed in place.

I like this because:

1. it always maximises use of the screen, leaving no big blank spaces
2. it doesn't confuse the viewer, by occasionally rotating unexpectedly
3. it isn't complicated.

What I would propose for the Publisher, is to also fix things, and don't try to rotate (i.e. ignore the OS "auto-rotate" settings).

• read from the camera in landscape mode
• take over the whole screen
• display what's being read in landscape mode
• publish in landscape mode...

if the Publisher changes the camera orientation, then the app should keep everything as it is in relation to the device, fixed, in landscape mode. The Consumer gets to feel the change in orientation, and can actually adapt to it themselves.

For me, this would represent minimum complexity, and would also integrate most effectively with the Consumer app.

Does that make sense? Hopefully, this might represent the least-complex path to closing this issue - but I will let you decide, as this behaviour was not explicitly specified in the original issue.

[criticaltv]

OK, FWIW, on further investigation, I've got it working on my device, so I've been able to investigate how it behaves with different "Auto-rotate" settings in the OS.

Here is a summary of findings

	Auto-rotate ON	Auto-rotate OFF
Launch with device in Portrait orientation	APP CRASHES	APP CRASHES
Launch with device in Landscape orientation	APP LAUNCHES	APP CRASHES

[chrishobcroft]

Hello @psudoanon - how are you?

Are you able to share any progress on the development of this feature?

Are you still intending to proceed with delivering this bounty?

Thanks

[psudoanon]

Yeah sorry about the delay, had a busy few weeks where I've been focusing on other stuff; I'll try to have a fix before the weekend, just been having difficulties reproducing the reported crash on my device. @criticaltv would you mind letting me know the make / model of the Android device you're using along with the Android version? Thanks!

…

On Wed., Jun. 24, 2020, 5:32 a.m. Chris Hobcroft, ***@***.***> wrote: Hello @psudoanon <https://github.com/psudoanon> - how are you? Are you able to share any progress on the development of this feature? Are you still intending to proceed with delivering this bounty? Thanks — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#31 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOZ6FUIOQBDT5XUV7J6BBIDRYHBZTANCNFSM4LDOTFXA> .

[criticaltv]

@psudoanon

[criticaltv]

Also, still able to replicate that same behaviour...

[chrishobcroft]

Hey @psudoanon where are you at with this?

@mul1sh is nearly done on multi-channel support.

If we could deliver this feature and close this issue, we could enable multi-Publisher from mobile, to be connected with multi-Consumer, with pay-per-minute.

I also have a public school in India who would be a great use-case for what we're building. Proposing to use Goerli to measure which teachers the students watch the most... whoever receives most göETH from students.

[chrishobcroft]

There's also a lot of work in the pipeline to evolve this concept, including:

• integrating Consumer app with Publisher app to create integrated end-user experience. UX/UI Design is almost complete.

• integrating with Canon's SDK for connecting DSLR cameras, for beautiful visual quality

• integrating with the device's microphone input, to allow stereo line-in, e.g. from a professional sound-mixer.

• integrating zksync for gasless Publisher operation (helps onboarding), cheaper payments (reduces cost per minute), and gasless withdrawal to e.g. a Crypto-Fiat exchange.

• integrating with ENS / 3Box to make decentralised / on-chain "Publisher profiles"

• integrating something like Jitsi, for written chat (and maybe even picture-in-picture video) comm's during livestream

• there is also a plan to offload the payment validation to the server-side, and pay per-2s-segment using Probabilistic Micropayments, with a DPoS staking mechanism for community to stake to Publishers, and receive share of fees.

But we need to deliver an MVP first.

[criticaltv]

Yo @psudoanon - I echo @chrishobcroft's words here.

Keen to know when we can ship this. I feel we're so close to having something which would be very interesting to release and try out with real end users.

Let us know if we can help with anything?

[criticaltv]

@psudoanon - we haven't heard from you for over 6 weeks now.

Please can you update on whether you intend to complete this work?

If I don't hear from you in 48 hours, I will open this bounty to other contributors.

[psudoanon]

Hey, sorry about my delays. I got caught up in some personal business earlier this summer and didn't have much time to dedicate to this. All good now and I'll try and have the updates ready for you within the week.

…

On Sun., Aug. 9, 2020, 5:22 a.m. criticaltv, ***@***.***> wrote: @psudoanon <https://github.com/psudoanon> - we haven't heard from you for over 6 weeks now. Please can you update on whether you intend to complete this work? If I don't hear from you in 48 hours, I will open this bounty to other contributors. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#31 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOZ6FUIFPBN5PUWNHUJTW73R7ZTG7ANCNFSM4LDOTFXA> .

[gitcoinbot]

@mul1sh Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!

• reminder (3 days)
• escalation to mods (6 days)

Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days

[gitcoinbot]

@mul1sh Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!

• reminder (3 days)
• escalation to mods (6 days)

Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days