Recent activity in Textile’s public Slack channel, as well as external discussions with developers and other stakeholders has indicated an strong interest in having a Textile Javascript API. The specifics of such an API have yet to be established, but the general consensus is that one is needed to help support things like browser-based Textile apps, Node.js apps, and other use-cases. In this issue, we will outline some minimal requirements, and suggested ‘steps’ required to have a full-blown js-textile implementation.
Ideal Scenario
Ideally, we would have a single code-base that supports all necessary platforms (mobile, desktop/server, and browsers). This is currently almost possible thanks to various tools for cross-compiling Go code. On mobile Textile currently uses gomobile to build iOS and Android frameworks. On desktop/server, binaries are compiled using Go’s built-in build tools and xgo. For browser support, Go now supports targeting WASM, and there has been some progress on the IPFS side of things. However, this is a) producing extremely large bundles, and b) not stable enough to actually for much of anything. Clearly this is a useful future target to track.
Reasonable First Steps
To get a working Textile Javascript implementation working sooner rather than later, some incremental steps are likely required, as a full blown Javascript port would be a major undertaking. For example, most of the packages outside of core are likely pretty easy to port to Javascript, but the core textile package is large, complex, and full of custom transport, service, and communication implementations. It would likely require a great deal of support from the core Textile developers. As such, the following outlines a way forward towards a full port, with the full port a very last step.
Step 1
js-textile-http-client
The first step, and one that is already underway along multiple fronts, is a ‘simple’ Textile JS HTTP Wrapper Client. This would provide access to an underlying textile-go node’s REST API, adding various simplified APIs to support in-browser and programmatic desktop access. For the most part, the API would mimic the command-line and/or mobile APIs, with some browser-specific enhancements. Right now, this is the focus on the Textile JS efforts.
Step 2
js-textile
Phase 1
Given the steps involved in fulfilling Schemas and adding data to Threads, including the various communication protocols involved, a good next step would be to implement a light Textile client that supports data access only. This light client would likely start by supporting the following functionality:
- Wallet init and account generation
- Some minimal keypair tooling for secure storage of secrets
- Wrap a
js-ipfs peer (as we do in textile-go) for fetching data
- Crypto and Protobuf tools for data extraction and minimal hash tree parsing
Essentially, the client would be able to access existing Textile data given a File hash or Thread id (this might be slightly harder). This would be useful for creating ‘public’ Textile Photos viewers, sharing data with non-Textile users, and other use-cases where encrypted data in Threads is needed. It would not support adding data to Textile/IPFS, nor would it support a full-blown peer with Thread updates, backup, p2p communications, etc.
Phase 2
As a quick ‘follow-on’ to Step 2, we could facilitate building a Textile Javascript client that supports interacting with remote Cafes. Cafes provide http- and p2p-based access to most of the functionality that a Textile peer would need to participate fully in the Textile network. This means, some operations (wallet + account init, encryption/decryption, IPFS fetching, etc) could be done entirely locally based on work in Step 2, and others (thread updates and interactions, p2p messaging, thread and message outboxing/inboxing) could be done via Cafe REST and p2p APIs as part of work done in Step 3. This would still require extensive core Textile developer input/time, but would be significantly simpler than a full-blown Textile Javascript implementation, and would pave the way for Step 4, which would then incrementally move the remaining ‘remote’ pieces to local Javascript ports. The idea here would be to have something that supports almost everything a developer building on top of Textile could want in the browser, faster, and without many of the security considerations required from a full-blown Textile Javascript SDK.
Phase 3 (full implementation)
Full blown Textile Javascript node. Would require either a full Javascript port, or some sort of cross-compiling magic. This is likely a long ways off, and would require significant core developer time. Luckily, if we ‘tick’ all the boxes in the previous steps, this should really just be porting over core Textile code from Go. Again, doing things incrementally like this means we can have a mostly full-blown Textile node in Javascript, and slowly port over additional pieces as it makes sense.
Specific deliverables here would include code parity with textile-go.
![dependabot-preview[bot] avatar](https://avatars.githubusercontent.com/in/2141?v=4 "dependabot-preview[bot]")
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent