New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Transcoder ENS Integration - Phase 1 #6

chris-remus opened this Issue Dec 14, 2018 · 7 comments


None yet
3 participants
Copy link

chris-remus commented Dec 14, 2018

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


This comment has been minimized.

Copy link

ericxtang commented Dec 18, 2018

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?


This comment has been minimized.

Copy link

RaffiSapire commented Dec 19, 2018

@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?


This comment has been minimized.

Copy link

chris-remus commented Dec 20, 2018

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

screen shot 2018-12-20 at 3 44 55 pm

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.


This comment has been minimized.

Copy link

ericxtang commented Dec 20, 2018

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.


This comment has been minimized.

Copy link

chris-remus commented Dec 24, 2018

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


This comment has been minimized.

Copy link

RaffiSapire commented Dec 27, 2018

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: 345 LPT

  • Develop user flows/user stories - 75 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 1 day.
  • 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 - 20 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.

@RaffiSapire RaffiSapire closed this Jan 3, 2019

@RaffiSapire RaffiSapire reopened this Jan 3, 2019


This comment has been minimized.

Copy link

chris-remus commented Jan 4, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment