Browser and mobile platforms bring numerous restrictions, both in terms of technology and resource availability. Such restrictions make it difficult, or even impossible, to achieve the sought properties of privacy, censorship-resistance and anonymity that Logos aims to deliver.
However, what we’re building at Logos is not the only technology impeded by those limitations. Popular applications across the industry often offer web versions with limited features, but these remain accessible to users without friction. This pattern exists because, ultimately, developers decide where to invest their effort, and user acquisition matters.
The Developer Imperative: Maximum Return for Minimal Effort
From a developer’s point of view, they want minimal development effort for maximum return. An ideal architecture would allow them to build a web application using a Logos JavaScript SDK that can work in a browser, albeit with limitations, but can also run in Logos Core using local nodes with full capabilities.
The Waku API effort exemplifies how to provide libraries that achieve this goal. By ensuring that the API to use Waku services is explicitly defined and simple, we not only enable alignment between implementations, but also enable injection into the DOM to easily forward API calls to a browser extension or Logos Core modules. This architectural approach creates a seamless pathway from lightweight web experiences to full-featured native applications.
The Web-to-Native Pattern: A Proven Acquisition Strategy
The pattern of using web applications as an entry point before converting users to native applications is well-established in the industry. Discord and Slack both exemplify this approach: they offer functional web versions that allow users to experience the core product without friction, whilst consistently nudging users towards their native desktop and mobile applications where performance is better, features are more comprehensive, and the experience is more polished. Discord uses technical mechanisms to automatically open links in the native app when installed, whilst Slack’s engineering team has documented investing heavily in desktop app performance. These companies understand that the web is an excellent discovery and onboarding tool, but native applications provide the superior experience that retains engaged users. This web-to-app funnel strategy has become an industry standard approach for user acquisition.
However, it’s worth noting that today’s push from companies towards mobile apps is often nefarious rather than user-centric. Academic researchers discovered that Meta’s Facebook app runs local WebRTC servers on users’ devices, enabling capabilities and data collection that would be impossible or more transparent in a browser environment. The technique allowed Facebook to bypass incognito mode, VPNs, and Android permissions to track users. More tellingly, platforms like DoorDash have used API-level blocking to prevent third-party apps from accessing information that would benefit workers, with the Electronic Frontier Foundation highlighting the deceptive privacy claims used to justify such restrictions. The key difference is that whilst you can modify websites locally using browser tools and extensions—something courts have consistently supported as users’ right to control their viewing experience—legally and technically you cannot modify mobile apps (DMCA in the US) in the same way. This asymmetry gives companies unprecedented control over user experience and data.
In our case, however, the push from web to native applications will be legitimate and driven by genuine technical and economic realities rather than corporate control. The limitations we’re working within are fundamental to the platforms themselves, and the migration path we’re creating genuinely benefits users by unlocking capabilities that cannot exist in constrained environments.
Understanding Platform Limitations
This approach necessarily creates heterogeneity of devices, with devices being either mostly offline (browser tabs), limited in battery, data usage (mobile data plans) or by their technology stack (TCP/UDP vs WebSocket/WebTransport). Such devices cannot meaningfully participate in reciprocal tit-for-tat protocols, whether due to bandwidth usage restrictions or their regular unavailability.
Natural Conversion Pressure
What if users never convert and remain in the browser? This may happen, but there are a number of factors in place that will help conversion.
Currently, Waku has some limitations in the browser, but most are invisible to users simply because there’s no cost difference between consuming resources from the network (edge node) and participating as a full peer (relay node with tit-for-tat). This means that today, from a pure Waku perspective, users have little compelling reason to migrate from web to native applications beyond convenience or features.
However, this is set to change dramatically with the introduction of incentivisation mechanisms. As incentivisation is brought in to ensure sustainability of the network itself and prevent everyone defaulting to “edge node” mode, these differences will become stark economic realities. Users will face a clear choice: operate on browser (edge) or mobile and pay for services, or run native desktop applications to access services for “free” through tit-for-tat contributions, or even get paid by providing services to edge nodes.
This economic model will complement the technical limitations that other protocols, such as Codex, already impose, creating multiple converging incentives for users to migrate to native applications after getting a taste via web apps. Where Codex’s technical constraints create capability boundaries in the browser (e.g. in relation to messaging: no strong backup, limited message archival, file size restrictions), Waku’s incentivisation model adds economic motivation. Together, these create a comprehensive conversion funnel across the entire Logos stack, mirroring the proven Discord and Slack pattern but with genuine user benefits rather than corporate greed.
The Strategic Value: Preview, Then Convert
This may be enough to enable a “light preview” of applications built on Logos, whilst driving onboarded users towards Logos Core or native desktop applications. This approach fully enables the security, privacy, anonymity and censorship-resistance of the Logos technology stack for committed users, whilst lowering the barrier to initial adoption.
However, we must be cautious not to repeat the mistakes of Ethereum and IPFS browser implementations. Both protocols have seen (some or) widespread adoption in browsers, but often at the cost of true decentralisation. Browser-based Ethereum typically relies on centralised RPC endpoints (Infura, Alchemy), whilst IPFS in the browser often depends on centralised HTTP gateways rather than participating in the peer-to-peer network directly. This creates a facade of decentralisation whilst actually funnelling users through centralised chokepoints that can be monitored, censored, or become single points of failure.
For Logos, it may be preferable to offer more limited functionality in the browser rather than compromise on our core values of decentralisation (ie privacy, anonymity and censorship-resistance). If providing full functionality in a web SDK requires relying on centralised gateways or RPC providers, we should instead embrace the limitations and offer only what can be achieved whilst maintaining true peer-to-peer architecture. A genuinely limited but decentralised web experience is more honest and more aligned with our values than a feature-complete web experience built on centralised infrastructure. This approach reinforces rather than undermines the value proposition of migrating to native applications.
There’s a legitimate risk that what happened to Safe could happen again if we’re not careful. The February 2025 Bybit hack, which resulted in $1.5 billion stolen through a compromised Safe{Wallet} developer machine, demonstrates the severe risks of web-based infrastructure. Attackers injected malicious JavaScript into the Safe UI served from AWS, manipulating what users saw when signing transactions. Whilst the Safe smart contracts themselves were never compromised, the web interface vulnerability allowed attackers to deceive multiple signers into authorising a transaction that drained Bybit’s cold wallet. This incident underscores why we need to ensure that users are funnelled towards native applications, and that web applications serve as a stop-gap in the user journey rather than the final destination.
Whilst I don’t have a complete answer for how to orchestrate this transition, the first step remains understanding the difference in properties we can achieve on each platform, and building the infrastructure that enables both the lightweight entry point and the path to full capabilities. In any case, the developer experience is critical,to ensure developers can easily build applications that enable this web-to-native funnel. Do note it is my understanding that secure distribution is a key goal for Logos Core/Codex, I assume that such attack will be preventable for Logos Native apps.
A web SDK isn’t a compromise on our values. It’s a strategic tool for adoption that acknowledges how developers work and how users discover new technology, whilst maintaining a clear path to the full Logos experience where both technical capabilities and economic incentives naturally guide users towards becoming full network participants.
