JavaScript SDK for Agents


The current interfaces for Sovrin favor Python. I’m interested in developing a Sovrin agent that in a system that is JavaScript based.

Is it possible at this point to develop a JavaScript SDK for Sovrin.

If I had money to pay someone to do it, what kind of support would they need from Evernym and is it a level of effor that Evernym could support?


There’s a different answer depending on whether you’re talking about javascript in browser/app land, or javascript on a server (e.g., node.js). The reason is that browser-based javascript doesn’t support raw UDP sockets, and today, interacting with the ledger requires code to support RAET, which cannot be done without some low-level networking pieces. The high-level ajax-style http request isn’t enough.

If you’re talking node.js, then today it is theoretically possible, but far harder than it should be.

We are actively investigating how to replace the protocol that one uses to talk to the ledger. Conversations are quite intense, and they are motivated by the very sort of question you’ve asked–it needs to be possible to talk to sovrin in any reasonable programming language. Straight https is an obvious choice, but it has some problems with certificates introducing a flawed trust model into sovrin, and making sovrin dependent on CAs. We’ve looked at many other alternatives and want to open the discussion to the larger community as soon as we have a rational summary of the choices to offer.

I believe within a very short time we’ll have a more satisfying answer to this question.


Thanks Daniel. Definitely interested for the server side.

Is the problem that RAET is puthon specific? Or are there larger issues.

I agree that HTTP/TLS is likely a poor choice for communicating with the ledger for the reasons you state.


Yes, a big part of the issue is that RAET is python-specific. If we want cross-programming-language support, we need to either port it or replace it.


I agree that a JavaScript Browser based interface is a good thing to do and is the least work.

Plenum uses Raet. Both of which are written in Python. RAET is UDP not TCP.

For a Node.js server side version there would either need to be a port of Plenum and Raet to JavaScript, orr a thin node.js wrapper around the command line Sovrin interface. I suggest the latter approach.

Raet is modular enough that a TCP version that includes the ECC end to end encryption could be built (This avoids the problems of Https) But IMHO there is not enough savings in effort to justify a TCP port when a UDP has many advantages and RAET already makes UDP reliable in a more performant way than TCP.

But then if you are not building a browser based node, running Plenum in python in server is not a problem and adding a thin Node.js, Javascript wrapper around the command line interface to Sovrin is easy to do on the server side.Then one can have a web app light weight client without too much trouble.


But off course if all you want is a browser app. Then Python (Flask, Django) web framework would be easy to set up.

Finally is what you want is to do development of a custom node with different functionality and you want to do it in node.js because python is not a good fit for your developer skills then another alternative is to implement a javascript version of the Unix Domain Socket UXD interprocess communication protocol from Raet. Raet includes an extremely lightweight interprocess communication protocol that uses unix domain datagram sockets. UXD is reliable and much faster than TCP for interprocess communication and does not have the packet size limitations of UDP, Also for comms on the same machine one does not need additional encryption/auth etc. So the The RAET UXD protocol is almost trivial to implement and could easily be ported to Node.js. This way one could run Plenum in python side by side with Node.js. Plenum RAET for for host to host comms and UXD for Plenum to App layer comms where the App layer is written in Javascript. The Uxd protocol in Raet greatly simplified porting SaltStake to raet.

Because UXD supports datagrams it simplifies programing in general over TCP because message framing is build in to datagrams and UXD are already reliable. More people should use UXD for interprocess (does not work on Windows, but Raet supports a Windows mailbox protocol which is essentially a reliable datagram service so we made is look like UXD.


It would be really handy if there was a REST service that would allow us to perform all the same operations as the CLI. That way it would be really easy to create simple visual mock ups (using Angular or React etc.) for demonstration purposes. You Python gurus could probably do that in about 10minutes using Django and Swagger right? :slight_smile: