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

Reseed over WebRTC Data Channel #80

Open
eyedeekay opened this issue Mar 2, 2020 · 0 comments
Open

Reseed over WebRTC Data Channel #80

eyedeekay opened this issue Mar 2, 2020 · 0 comments
Labels
enhancement New feature or request Next Things I will probably work on after what I am working on now.

Comments

@eyedeekay
Copy link
Owner

eyedeekay commented Mar 2, 2020

This can't be done in just this extension, but this extension is probably an important component of a future plan in which this is straightforward. This is the trickiest thing I've tried so far, K, let's define some phases here...

Phase 0: Design

We're pretty different from Tor in the places where Snowflake would really matter, but it's an inspiring effort and a cool product. This process probably won't bear much resemblance to Snowflake when it's all designed, but Snowflake was the original inspiration for the idea.

What we want to do is make it possible for I2P users to easily reseed eachother in a peer-to-peer way when necessary. It must be done no more often than a normal reseed, and it must only ever be client initiated.

This is not a webRTC transport for I2P. That would be an entirely different project. Especially if it were to do something genuinely insane like try to incorporate browser users not otherwise running I2P into the routing process. That would be crazy, right? Right? (It might not actually be that crazy but I have enough to think about right now). This is only for reseeds.

Questions

  • Where to get the reseed file? Locally or from a reseed server? Probably a server, and we act as a proxy, but we need to examine advantages and disadvantages of each. Maybe both, server then a local fallback?
  • Do we need to geolocate and never fetch a reseed file for a user in a country which is already automatically in hidden mode? Probably yes. Might want to never make them reseed helpers anyway.
  • How to distribute the reseed file? If it comes from a server it will be signed by a key we already trust, that's fine, but if it comes from somewhere local we may want to use an interstitial

Components

  • Browser Extension - This repo. We use it because we can to some extent assume that people using this extension are also using I2P and can thus provide a reseed from a local source if need be.
  • Javascript Import - Placed on web pages, a'la Snowflake and or Flashproxy. Shows a download link that says "Download reseed file over WebRTC," uses a (random?) extension user.
  • Native Proxy - Runs locally, obviates the need to download the reseed in a browser by fetching it over WebRTC on behalf of the router. Will start out as a "Bridge" but eventually be incorporated into I2P if successful.
    1. Go version, using pion/webrtc
    2. Java version, using whatever that Guardian Project library is probably

Phase 1: Manual Mode

Components required

  • Browser Extension
  • Javascript Import

Phase 2: Bridged Prototype

  • Native Proxy, Go Version

Phase 3: Router Incorporation

  • Native Proxy, Java Version
@eyedeekay eyedeekay added enhancement New feature or request Next Things I will probably work on after what I am working on now. labels Mar 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request Next Things I will probably work on after what I am working on now.
Projects
None yet
Development

No branches or pull requests

1 participant