I love Web5 for the simplicity it gives developers. Decentralization is tough. Many devs want to build decentralized applications - but they can’t be creating their own decentralized networks.
So folks building atop the Web5 programming model get decentralization for free. That’s powerful. It’s why application servers and container orchestration engines are so prevalent - they do the heavy lifting of resource management and plumbing, freeing app developers to focus on business logic. All they’ve got to do is use the Web5 APIs.
In MVC architectures we do this all the time - there’s the application layer, and above that, an HTTP layer (the controller) which does request/response parsing and calls the application.
Looks crudely like this:
Sweet. The user application is free to define its own API, and exposes whatever it wants as HTTP endpoints. Those HTTP endpoints do whatever parsing/validation/plumbing nonsense they want and call the application’s APIs.
I envision a similar setup for decentralized applications - a DWN/Web5 layer.
As an SDK, it’s meant to be imported into a user’s project and called upon directly. As a first implementation for us, this makes sense because we are building a web-based Wallet as a browser extension. That wallet needs to “speak DWN” - sending DWN-formatted messages and sending them over the wire.
So now our application can look a little like this:
Here we’ve swapped the HTTP layer for a DWN one. And because there’s no Java Servlet engine, or Node Express, or any of the other ecosystem support for DWN as there is for HTTP, we import an implementation of the DWN SDK. The application’s DWN layer interacts with the application and uses the DWN SDK to send and receive messages.
For many users, this may be preferable. Make your application, import the DWN SDK, and call upon the DWN SDK in-process.
There are some observably true limitations to this approach I think are worth addressing:
- There’s a development and maintenance cost to each language impl of the emerging DWN standard.
- We would like for as many people as possible to use DWN as early as possible.
My opinions from those are:
- It doesn’t make sense for us to deliver DWN SDKs in several languages in the near-term. It likely does as things mature and our community grows.
So I propose a language-agnostic API for DWN, based on HTTP. We have some precedent for this; we’re already doing it in the SSI Service. Folks wanting to call upon the operations that the SSI SDK provides can do so over the SSI Service’s HTTP endpoints. We can wrap the DWN SDK in a DWN Service and expose its API over HTTP.
That’d look like this:
Here we’ve removed the DWN SDK from the user application. Instead, we’ve exposed the DWN SDK to the application, not to the world, through an HTTP API instead of an language-specific API. It’s adding an API to the existing DWN SDK over a network boundary instead of an in-process one.
Then folks could run the DWN as a service. It has the following benefits:
- Easily run and secured via a container
- Developers could call upon it using familiar means with wide ecosystem support, HTTP
- Immediately opens DWN for use in any language, even
- Larger enterprises who are hesitant to bring in new dependencies are more likely to run services with well-defined containerized security policies, which are easier to enforce.
- Upgrade path requires pulling a new container image of the service, rather than rebuilding and redeploying the user application
- I don’t see any. We still ship the DWN SDK and folks are free to use it directly if the in-process approach better serves their use case. For many this will be true.
Note: this is a different discussion from the issue of decentralized message format and transport. That exists between the DWN SDK and the WAN. This is only about how user applications, the SSI Service included, may call upon the DWN.
Excited to hear your thoughts.