Transcoder ENS Integration - Phase 1

[cfl0ws]

Give a 3 sentence description about this proposal.

Complete the Ethereum Name Service (ENS) integration within the Livepeer infrastructure. The integration will allow Transcoders to be identified and interacted with using an ENS name. This is a continuation of work Chris organized at the ENS Workshop in August 2018.

Describe the problem you are solving.

It's difficult to identify a transcoder on the Livepeer Explorer. An Ethereum address identifies the transcoder. An LPT holder looking to bond to a transcoder must map the address from the Explorer to the transcoder campaign on the Livepeer Forum.

When bonding, the LPT holder must confirm they are sending LPT to the correct Ethereum address. Giving transcoders human readable names would simplify both processes. The Ethereum Name Service (ENS) can provide these names.

Describe the solution you are proposing.

Phase 1 Scope -

• Step 1: A user can see an ENS name in the Livepeer Explorer so a transcoder is easily identifiable by a human readable name
• Step 2: When a user bonds, the transcoder name is populated in Metamask, providing the user with additional security they are bonding to the intended transcoder

For Further Investigation -

• Link an ENS name to a domain set by the transcoder to learn more about that transcoder
• Linking additional metadata, including the domain from the above example, to an ENS name
• How much of this work can be used in a new staking dapp
• Understand how current Explorer is built, to understand how and where the ENS registry would be called
• Understand how current transcoder addresses are displayed on the Livepeer Explorer

Describe the scope of the project including a rough timeline and milestones

• Baseline current integration status
  • Completed by the Livepeer team to-date
  • Completed by the volunteer team at the 2018 ENS hackathon
• Develop completion plan
  • Define scope
  • Develop user flows/user stories
  • Develop spec (technical + UX)
  • Registration process for transcoder
  • User testing
  • FE discussion to determine future relevancy
  • Linking metadata to an ENS name
  • Complete gap analysis against current work
  • Define required resources
  • Develop estimated timeline

Note: The anticipated Phase 2 would include forming the team to do the work and manage the work to complete the integration.

Timeline - Approximately 3 weeks, start to finish

Please estimate hours spent on project based on the above

• Baseline current integration status = 1 day
• Develop completion plan = 5 days

Total = 6 days @ 8 hrs/day

[ericxtang]

Hi @chris-remus thanks for the proposal. This looks great. I just have one question about how the transcoders can actually get the ENS names - do you foresee this happening in the explorer interface too somehow?

[RaffiSapire]

@chris-remus @ericxtang I'm not sure if I understand your question Eric, is it, how do they register, what is the process for getting an ENS name, and is this done on the explorer or personal reach out? Chris has one bullet that says "Registration process for transcoder," do you think that is what he's referring to there?

[cfl0ws]

@ericxtang @RaffiSapire This could be done in one of two ways. The first would be to issue sub-domains using a tool like manager-beta.ens.domains -

The transcoder would request their subdomain of the chosen transcoder domain. Assuming Livepeer owns that domain, Livepeer could issue the subdomain. I understand @dob has ideas on the preferred domain.

Livepeer could also build subdomain registration into the explorer. This would be more involved. It would also introduce uncertainty into the process. For example, a bad actor could register a subdomain that should belong to a known transcoder.

I think for now the first option's the way to go. We could pursue the second option in a next iteration, possibly after the Streamflow release. These are the two options we'd decide between during this phase of the project.

[ericxtang]

I see. I think for now it's ok for us to make it know that transcoders can reach out to us to get their transcoder.eth subdomain.

[cfl0ws]

@RaffiSapire Could you please provide some insight into the decision/kickoff timeline for this?

[RaffiSapire]

Thank you @chris-remus. For this Phase 1 of planning, we propose a 345 LPT planning grant. It is really important that it leads to Phase 2: execution. Failure here is to create a plan and not move into implementation.

The first 3 items on this list should be done as part of this grant application, not part of the grant. Baseline current integration status:

• Completed by the Livepeer team to-date - I believe this is known information and putting pen to paper here and making clear will be good.
• Completed by the volunteer team at the 2018 ENS hackathon - this is also known information and sharing in a paragraph will be great. Develop a completion plan
• Define scope - please include here. We recommend that success here is defined as an implemented ENS name in the explorer, and something around a key measurement that represents usability.

For Phase 1: 440 LPT

• Develop user flows/user stories - 150 LPT. This is expected to be in the form of mockups, done on UXPin or whatever mockup software you use. The output should link to 2 full user flows for both a transcoder to set up and interact with it, as well as a token holder who is bonding. I estimate based on my own experience this should take no more than 2 days.
• Develop spec (technical + UX) - 250 LPT that includes the Registration process for transcoder, User testing, FE discussion to determine future relevancy, Linking metadata to an ENS name. The output should be github issues written by a developer that describe what needs to be done, how it would be technically done, and how much time it should take. It may entail back and forth with Eric if he has questions on how you are interacting with the blockchain or another component. This should take a day and requires an engineer.
• Complete gap analysis against current work - 40 LPT - this is evident in the process of designing the technical spec, figuring out what is done and what needs to be done. Putting it on a page in a clear visual way will be helpful.
• Define required resources - this is part of the technical spec - whoever you are working with on the technical spec should help you identify the right skillsets to execute the issues.
• Develop estimated timeline - this is part of the technical spec. Each issue should include a time estimate for completion.

[cfl0ws]

Hi @RaffiSapire I've reviewed your proposal and am working on my response. I hope to post it early next week.

[RaffiSapire]

Hey @chris-remus, just wanted to follow up here. I reviewed and allocated additional time for the UX step, increasing the Phase 1 to 440 LPT. Let us know if you're still game, I know you anticipated 6 days of work, but we spent some time going through what needs to be done, and Eric and I set time estimates above. I know you were concerned that the grant size didn't cover 48 hours of work, but we think it's going to be less than that for this phase. See our breakdown above and let me know if you're interested in pushing it forward.

[RaffiSapire]

We are integrating 3box instead, I am closing this issue.