Reseed over WebRTC Data Channel #27

New Issue

idk · 2025-04-21T15:12:42-04:00

idk commented

2025-04-21 15:12:42 -04:00

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

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

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: idk/I2P_in_Private_Browsing_Mode_for_Firefox#27