Skip to content
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

Non-interactively verifiable attribution #138

Open
bedeho opened this issue Feb 1, 2023 · 0 comments
Open

Non-interactively verifiable attribution #138

bedeho opened this issue Feb 1, 2023 · 0 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@bedeho
Copy link
Member

bedeho commented Feb 1, 2023

Background

Assume we have this

#139

The problem is still that a malicious application can lie, they can start scraping content without publisher authorization, and then receive council payouts for this. This is a position the DAO def. does not want to put itself in. While various manual mechanisms can work to discourage this from happening, such as a trusted council agent manually checking each channel before it is included in payouts, that has clear scaling problems. Another alternative would be to require channels to publish some sort of opt-in message on YouTube, but that also has a lot of friction involved.

Proposal

We need a way for apps to convey the evidence from YouTube infrastructure about the fact that has received authorization, and embed this evidence as part of the on-chain publishing. This evidence should be verifiable by anyone, and the council in particular, proving that the given channel owner has opted in through the YouTube API.

The difficulty here is that YouTube currently does not provide any such evidence. It provides an access token, which regularly expires, which can only be verified by interactively asking YouTube. Even if it did not expire, publishing such a token would be a security risk.

One way to work around this, which admittedly will not be simple, is to zksnarkify the following predicate "YT server X provided access token for channel Y" where the proof uses access token and other TLS related information as private inputs.

There are many designs and sketches of such TLS oracles that can be reviewed, and probably also POC implementations.

@bedeho bedeho added enhancement New feature or request help wanted Extra attention is needed labels Feb 1, 2023
@bedeho bedeho changed the title Verifiable attribution Non-interactively verifiable attribution Feb 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

1 participant