An SDK that lets people contribute unused internet capacity through an app they already use. The app offers a reward, the user decides whether to participate, and P2PSDK handles the network connection.
P2PSDK is built for publishers adding bandwidth sharing to their own products. A platform package embeds the network runtime; the application decides when to present the feature, how to explain the reward, and how long to keep the SDK instance alive.
The SDK handles connection state, device identity, and verification of the consent decision. It is designed to operate without reading personal application content. Publishers still own their app’s privacy disclosures, reward records, and telemetry.
For a user, participation starts with a clear choice and remains manageable from the app’s settings. For the publisher, it provides an additional way to earn alongside an existing advertising setup.
Participating devices connect to the platform as exit nodes. The platform routes customer requests through those connections, records the bandwidth used, and makes usage and account data available through its control plane.
The SDK connects Android, iOS, Windows, macOS, Linux, and webOS devices to the proxy platform. Once a device is online, the platform can route requests through it as an exit node. Participation follows the app’s consent and lifecycle controls.
The proxy platform sends usage data to two services. Traffic accounting records transferred bytes against devices and accounts. Analytics aggregates activity for network and product reporting.
Publishers and operators use the control plane to manage accounts and access, inspect usage, and read reports. Its dashboard and API connect these operations to the running proxy platform.
Current public pages from P2PSDK: the product website, its consent example, and integration documentation. Select an image to view it at full size.
01 / Product website. The current positioning, participation flow, and supported integrations.
View the product website ↗Accepting an offer and being online are separate states. The integration needs to handle both, along with refusal, network changes, and shutdown.
Present the supported consent flow. A declined or cancelled decision leaves the SDK disabled.
The verified decision enables creation of the SDK instance. The application owns its lifetime.
Request a connection. The SDK manages setup, connection attempts, and its assigned retry policy.
The connected event confirms readiness. Disconnection events let the app reflect changes in availability.
Close the instance during final shutdown. Keep consent revocation available from persistent settings.
Consent is verified for the application, device, and disclosure version. A successful revoke closes the active instance. If revocation fails, the app needs to show the error and offer a retry. See the consent contract and runtime responsibilities.
Commercial terms are agreed with each publisher. Eligible participation and contributed bandwidth can both inform the calculation.
A contracted rate applies to qualifying users who have opted in. The agreement defines who counts, the reporting period, and any differences by geography or device class.
A usage component reflects eligible capacity actually contributed to the network. Publisher reporting covers participation, bandwidth, and accrued revenue once production access is enabled.
The reward offered inside an app is a separate product decision. A publisher may offer coins, access to a feature, or another benefit; the SDK does not establish a universal cash payout to each user. Review the published payout model when discussing terms.
The work includes package access, user-facing consent, and testing on the operating systems your app supports.
Packages are distributed privately. Onboarding provides the platform artifacts, application key, consent configuration, and a test environment. Keep the wrapper and its native library on the same release; confirm target platforms and commercial eligibility before scheduling production.
Explain what participation involves and what the reward is. Respect declines and cancellations, keep a visible revoke action in settings, and handle errors without claiming that an unsuccessful revoke has completed. Changes to the disclosure version require coordinated testing.
Exercise network loss, screen-off states, suspension, resume, and final shutdown. iOS can suspend the app; Android foreground execution needs explicit setup; desktop runtimes depend on a live host process. webOS keep-alive is best effort. Participation and rewards need to reflect these limits.
If the app already uses a VPN, proxy SDK, or custom networking stack, review coexistence during onboarding.
Rust powers the proxy engine, node registry, and consent backend. Go handles traffic accounting, Django provides the control plane and API, and Vue 3 supplies the administration interface.
Choose the SDK implementation that fits your application's language and integration environment. Rust, Kotlin, Swift, C#, and TypeScript versions are available for native and language-specific integration.
Full SDK support for the following operating systems.
Full support for TCP and UDP traffic.
Schedule a consultation with our proxy infrastructure experts and discover how enterprise-grade solutions can accelerate your growth.
