Closed PaulRBerg closed 3 years ago
Issue Status: 1. Open 2. Started 3. Submitted 4. Done
This issue now has a funding of 10.0 ETH (1399.38 USD @ $139.94/ETH) attached to it.
Issue Status: 1. Open 2. Started 3. Submitted 4. Done
Work has been started.
These users each claimed they can complete the work by 2 weeks, 1 day from now. Please review their action plans below:
1) walidmujahid has started work.
I am interested in working on this 2) zoek1 has started work.
I will create a new that integrates a video call and finance where a mentor is paid by mentee using the Sablier protocol for real-time finance streaming. 4) tgrecojs has started work.
Starting work on streaming integration. 5) bobeu has started work.
Simply get to work and do what I need to do, Perhaps, I'll improve as well. 6) devilla has started work.
I'll sit on it and simply do it. :-) 7) impetus1 has started work.
I will be a part of this bounty and help others get started with dapps
Learn more on the Gitcoin Issue Details page.
nice; looking forward to seeing the submissions!
Please start work everyone!!
On Wed, Jan 8, 2020 at 10:44 PM Gitcoin.co Bot notifications@github.com wrote:
Issue Status: 1. Open 2. Started 3. Submitted 4. Done
Workers have applied to start work.
These users each claimed they can complete the work by 1 month from now. Please review their action plans below:
1) walidmujahid https://gitcoin.co/walidmujahid has applied to start work (Funders only: approve worker https://gitcoin.co/issue/gitcoinco/web/5727/3872?mutate_worker_action=approve&worker=walidmujahid | reject worker https://gitcoin.co/issue/gitcoinco/web/5727/3872?mutate_worker_action=reject&worker=walidmujahid).
I am interested in working on this
Learn more on the Gitcoin Issue Details page https://gitcoin.co/issue/gitcoinco/web/5727/3872.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/gitcoinco/web/issues/5727?email_source=notifications&email_token=AAD5PCPIIIVJIWSF2LJV2DLQ422STA5CNFSM4KEAKF42YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIPBWAQ#issuecomment-572398338, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAD5PCNIKNBFOUXDCTLHUBTQ422STANCNFSM4KEAKF4Q .
--
@owocki http://www.twitter.com/owocki
gitcoin is live and has generated over $2.7mm for Open Source Software - see our results https://gitcoin.co/results
Excited to see interest in this bounty!
@walidmujahid, @zoek1, @lcoenen and @celebritydeveloper, if you have any questions, please feel free to ping me in the Sablier Discord server. I'll provide you with all the support needed.
Will not include or handle compound tokens or compound streaming for any relevant features that could use them.
gitmentor
feature branch ("minimally": To Be Described Soon)Hey @lcoenen the flow looks awesome! yeah let's sync on Discord whenever you want. Also happy to jump on a quick call if that would help clarify the requirements and how the Sablier part should work.
Is it just me or does seem that Sablier coudl be used to remove the need for a signaling server? Just go full webrtc or ws or something and send the peer data over the intial transaction that creates the Sablier stream, then use MM or Infura to query the peer connection data in case the peers get disconnected.
Maybe I'm confusing Sablier with ETH Whisper or something. Here's a webrtc noob.
Hey @ohsix1 Sablier can't be used as a signalling server, since it has been specifically designed for streaming money and nothing else.
The way it works is that we calculate the time elapsed between the deposit and now and multiply that by the pre-defined payment rate. This gets us a "real-time" balance computable at any time between the start time and the stop time.
Read more about it on https://github.com/ethereum/EIPs/issues/1620 (see v2 published on Sep 27, 2019).
@lcoenen @zoek1 Out of curiosity, are you two utilising Mattermost?
If so, are you extending it with a plugin or with something reminiscent of oauth-client -or perhaps oauth-client itself?
If you are using Mattermost, would you be open to sharing what your local development setup looks like and your approach to testing it? Or perhaps are you using a remote setup?
above diagram makes sense to me!
theres a few of us chatting about this on gitcoin.co/chat in the channel that was automatically created for this bounty..
Issue Status: 1. Open 2. Started 3. Submitted 4. Done
Work for 10.0 ETH (1678.36 USD @ $167.84/ETH) has been submitted by:
@owocki please take a look at the submitted work:
We submitted our work with @zoek1 , there is a video demo here: https://www.youtube.com/watch?v=IxD9zHaqPJs :)
Hey @lcoenen and @zoek1, many thanks for your submission, this is so epic! I'll review it over the next few days.
this is dope. nice work guys. wow.
whats up with the 1 minute of deadspace waiting for the stream to connect then the 45 second countdown? i skipped ahead in the video, but a user doing this isnt gonna wanna wait for 60+seconds i dont think
@zoek1 @lcoenen I took a look at your project. I think it is interesting, and with no intention of sounding condescening in writing since I also took part in this hack, I think you put good effort into it. However, from UX -I am uncertain if that is the best phrasing- standpoint, I do not see the value of having a mentor being paired with a mentee based on availability.
The simplest and best way, in my opinion, is just have the user find their own mentor and have them request a session with that mentor.
This way, the user is not wasting gas on creating a session in which the mentor may not show up, nor would they wasting money on a random mentor that may turn out useless.
If you instead let the user do all the work of searching for their mentor and having them request -or even do a session invitation to rephrase the procoess-, then Gitcoin can avoid some complexity in making a system that pairs mentors with mentees automatically based on some criteria -be that availability, relevant skills, price, or leadboard ranking.
I think most information is already available in a profile if that route must be taken, but I do not think that is a good route.
Intsead, an extra "mentor" tab to provide more information and then editing the /users page to also including searching and filtering for mentors instead of just searching users for bounties. I think that is much better distrabution of focus when it comes to complexity and much better for integrating this new product with Gitcoin sooner rather than later.
Also, using a request, scheduling, or invitation process for mentor and mentee sessions makes it clear to a user that "waiting" is to be rather expected. So, going that route instead of automatic pairing would fix the expectations and hence the experience that I believe @owocki commented on yesterday.
I also see that you are using Jitsi. I must be honest and say that I thought about doing that too, but I had determined that it would just add more complexity than needed on Gitcoin's devops team or whoever manages the backend.
Instead, Mattermost could be used and extended to a point. Either custom plugin or using something like Zoom that users install on their own devices and where Gitcoin does not have to deal with set up of more backend software than immediately needed.
I yet to have fully reach the stage of setting up Mattermost in my hackathon project, so I am very certain of complexity that I am missing.
Personally, I am heavily taking inspiration from things like Codementor, Hackerhands, and even Upwork.
Finally, I know the hackathon has ended, but I fully intend to work on the project I started. That said, I think "competing" when trying to build this project for Gitcoin is rather ineffient.
What do you say to collaborating in some fashion @zoek1 and @lcoenen? You can take the prize for the hackathon -I will aim for other prizes in upcoming hackathons-, I am far more interested in having a scucessful product integrated into Gitcoin.
Post Script:
whats up with the 1 minute of deadspace waiting for the stream to connect then the 45 second countdown? i skipped ahead in the video, but a user doing this isnt gonna wanna wait for 60+seconds i dont think
Just to add to what I mentioned above, a delay before a session start datetime will be enevitable, @owocki, unless that start datetime of a mentoring session is different from the start datetime of a Sablier money stream.
Perhaps a session should begin immediately -I think upon the mentors approval- while the ability to cancel a money stream is made available once the transaction is processed and in the blockchain.
However, the mentor may not recieve payment for the full amount of time they spent with the mentee. Perhaps this could be resolved by adding extra cost to the deposit for the estimated amount of lag time expected before a money stream starts.
this is dope. nice work guys. wow.
whats up with the 1 minute of deadspace waiting for the stream to connect then the 45 second countdown? i skipped ahead in the video, but a user doing this isnt gonna wanna wait for 60+seconds i dont think
Well, first, that's a hack - I didn't know how close from now I could set the beginning of the stream. Beside, the rational was that as a mentor I would like to be prepared and not have somebody randomly pop up on my screen.
That being said, we focused on the D-app itself and the stream and didn't spend much time on the UX or design.
@zoek1 @lcoenen I took a look at your project. I think it is interesting, and with no intention of sounding condescening in writing since I also took part in this hack, I think you put good effort into it. However, from UX -I am uncertain if that is the best phrasing- standpoint, I do not see the value of having a mentor being paired with a mentee based on availability.
Well, to be honest I focused on the web3 aspects and we didn't spend much time thinking about the UX or the design, it was a hackathon after all - we tried to have something functional for the deadline. If we want to get it published, there will be several caveat / hack to fix, and the UX would have to be re-designed.
The simplest and best way, in my opinion, is just have the user find their own mentor and have them request a session with that mentor.
This way, the user is not wasting gas on creating a session in which the mentor may not show up, nor would they wasting money on a random mentor that may turn out useless.
If you instead let the user do all the work of searching for their mentor and having them request -or even do a session invitation to rephrase the process-, then Gitcoin can avoid some complexity in making a system that pairs mentors with mentees automatically based on some criteria -be that availability, relevant skills, price, or leadboard ranking.
Inverting the process would be a good idea, but gitcoin would still be a listing collection, correct? Otherwise, how would one find a mentor?
I think most information is already available in a profile if that route must be taken, but I do not think that is a good route.
Intsead, an extra "mentor" tab to provide more information and then editing the /users page to also including searching and filtering for mentors instead of just searching users for bounties. I think that is much better distrabution of focus when it comes to complexity and much better for integrating this new product with Gitcoin sooner rather than later.
I really don't know their process here, is there a figma or a wireframe-like tooling we could use to specify the UX better?
Also, using a request, scheduling, or invitation process for mentor and mentee sessions makes it clear to a user that "waiting" is to be rather expected. So, going that route instead of automatic pairing would fix the expectations and hence the experience that I believe @owocki commented on yesterday.
I agree, we just didn't have the manpower or time to implement such a system.
I also see that you are using Jitsi. I must be honest and say that I thought about doing that too, but I had determined that it would just add more complexity than needed on Gitcoin's devops team or whoever manages the backend. @zoek1 advised to use jitsy as it could be intergrated with Mattermost. As far as I'm concerned, it can be changed quite easily - at the moment, the users are just connected to a specific room (the mentor eth address).
Instead, Mattermost could be used and extended to a point. Either custom plugin or using something like Zoom that users install on their own devices and where Gitcoin does not have to deal with set up of more backend software than immediately needed.
I yet to have fully reach the stage of setting up Mattermost in my hackathon project, so I am very certain of complexity that I am missing.
Personally, I am heavily taking inspiration from things like Codementor, Hackerhands, and even Upwork.
Finally, I know the hackathon has ended, but I fully intend to work on the project I started. That said, I think "competing" when trying to build this project for Gitcoin is rather ineffient. I know dude, I'm sorry, if I had know you were working on this I would have invited you along! I didn't check the page to be honest. Next time!
What do you say to collaborating in some fashion @zoek1 and @lcoenen? You can take the prize for the hackathon -I will aim for other prizes in upcoming hackathons-, I am far more interested in having a scucessful product integrated into Gitcoin.
Sure, let's try to do that. To be honest I'm taking a bit of a break now but I'm interested in getting shipped as well. For sure, an appointment system would be the best.
Post Script:
whats up with the 1 minute of deadspace waiting for the stream to connect then the 45 second countdown? i skipped ahead in the video, but a user doing this isnt gonna wanna wait for 60+seconds i dont think
Just to add to what I mentioned above, a delay before a session start datetime will be enevitable, @owocki, unless that start datetime of a mentoring session is different from the start datetime of a Sablier money stream.
Perhaps a session should begin immediately -I think upon the mentors approval- while the ability to cancel a money stream is made available once the transaction is processed and in the blockchain.
However, the mentor may not recieve payment for the full amount of time they spent with the mentee. Perhaps this could be resolved by adding extra cost to the deposit for the estimated amount of lag time expected before a money stream starts.
Well, to be honest I focused on the web3 aspects and we didn't spend much time thinking about the UX or the design, it was a hackathon after all
Haha. I should have joined your team. You know what to do within the context of a hackathon and know where to put hacks and caveats to save on time in competition -in my case, I do not have such experience in hacakthons :-D
Inverting the process would be a good idea, but gitcoin would still be a listing collection, correct? Otherwise, how would one find a mentor?
Yes, that would exist. I did not mean to imply there would be no need of listing collection. On my project, I had added an persona_is_mentor
to the Profile
model and tried to simply filter out and list those that had that field set to True to be shown on the "request" form I have as well as on the /users
page. I do not have that fully working.
I really don't know their process here, is there a figma or a wireframe-like tooling we could use to specify the UX better?
I have noticed Figma is used alot for UI design amongst the Web3 projects. I am not much of a designer or have much experience with Figma, but I am certain that visual representation of UX is also included in Figma. I mostly prefer to read bullet points or paragraphs laying out the user experience. I did note down my ideas on user experience in my notes and comments for this product here: https://github.com/gitcoinco/web/issues/5727#issuecomment-573280534
That being said, we focused on the D-app itself and the stream and didn't spend much time on the UX or design.
got it; i agree with this decision. we can cleanup the UX later if we decide to use this code :)
still digging out my inbox. will spend more cycles here later in the week
i am going to select a winner soon..
questions:
Before team up we talked to distribute equally the prize: 50% @lcoenen, 50% me
@owocki
@owocki Video submitted: https://youtu.be/gK8xPIm9tMk
Thanks @walidmujahid ; request form looks good :)
⚡️ A tip worth 5.00000 ETH (920.48 USD @ $184.1/ETH) has been granted to @zoek1 for this issue from @owocki. ⚡️
Nice work @zoek1! Your tip has automatically been deposited in the ETH address we have on file.
⚡️ A tip worth 5.00000 ETH (920.48 USD @ $184.1/ETH) has been granted to @lcoenen for this issue from @owocki. ⚡️
Nice work @lcoenen! Your tip has automatically been deposited in the ETH address we have on file.
⚡️ A tip worth 1.00000 ETH (184.1 USD @ $184.1/ETH) has been granted to @walidmujahid for this issue from @owocki. ⚡️
Nice work @walidmujahid! Your tip has automatically been deposited in the ETH address we have on file.
just sent some tips :) nice work @lcoenen @zoek1 i gave u first place. @walidmujahid i gave u an honorable mention !1
Issue Status: 1. Open 2. Started 3. Submitted 4. Done
Work has been started.
These users each claimed they can complete the work by 1 week, 1 day from now. Please review their action plans below:
1) walidmujahid has started work.
I am interested in working on this 2) zoek1 has started work.
I will create a new that integrates a video call and finance where a mentor is paid by mentee using the Sablier protocol for real-time finance streaming. 4) tgrecojs has started work.
Starting work on streaming integration. 5) bobeu has started work.
Simply get to work and do what I need to do, Perhaps, I'll improve as well. 6) devilla has started work.
I'll sit on it and simply do it. :-) 7) impetus1 has started work.
I will be a part of this bounty and help others get started with dapps
Learn more on the Gitcoin Issue Details page.
Issue Status: 1. Open 2. Started 3. Submitted 4. Done
This Bounty has been completed.
Additional Tips for this Bounty:
Thanks for the Tip. I know it only looked that way because it was the only thing shown, but there was more than just a request form :-D
In any case, I have been working on finishing this product beyond the demo. I hope to have my WIP PR open for review soon.
Closing this out for now as we never ended up getting Sablier code for production. Will reopen if decided to revisit this
What
Proposal to create a bounty for this tweet.
Description
Add a new page in the Gitcoin website that embeds a video call and uses the Sablier protocol for the real-time finance part. The mentee streams money to the mentor while they are on the call.
Useful Links
Proof of Concept