As a DeFi degen, I was delighted to witness the launch of osmosis so much so that I am spending my nights and evenings re-distributing $OSMOs into the pools I am participating in. While the osmosis frontend is the necessary and effective building block for doing just that, it comes a bit short with respect to some more complex features around liquidity providing and efficiency of applying them.
As a liquidity provider, I'd like to follow a certain asset allocation, e.g. allocating e.g. 50% of my holdings to $OSMO, and 25% each to $LUNA and $ATOM. Now with all the volatility involved, this is actually not a trivial process for a human to efficiently converge to exactly that on a daily basis. Having that in mind and as a practical problem every day, I came up with the idea of building an additional frontend for managing and executing a certain strategy on osmosis. Plot twist: Early on in the development process however, after finally having made IBC run locally (🙈), did I acknowledge that I have to persist user specfic data additional to the data we have in
osmosis-1. This inspired Log in with $OSMO 👇
What it does
Log in with $OSMO is the necessary building block for authenticating and authorizing access to centralized applications complementary to osmosis. It is a OAuth 2.0 compliant server that uses
osmosis-1 as the Identity Provider and a user issued transaction in it to authenticate users. Developers who build on top of osmosis can use **Log in with $OSMO` by implementing e.g. OpenID Connect to leverage the OAuth Authorization Code Flow for authenticating requests to their app.
How it is built
Log in with $OSMO is backed by a cloud native OAuth 2.0 and OpenID Connect server, for the basic OAuth dance and ultimately issuing
jwts to application clients. The authentication interface on top of that is a server side rendered node.js application. (It can not be only a Single Page App, there has to be a server-side component with access to the OAuth server.) The user interface implements the wallet connection as well as means for the user to sign an actual on-chain transaction to provide a proof of authenticity.
The demo application is a simple client side application fronted by a reverse proxy implementing OpenID Connect for enforcing authenticated access. For unauthenticated users, requests towards https://rebalance.diffusion.zone will be redirected to https://auth.diffusion.zone, providing above mentioned means for authenticating. After successfully doing so, the user is redirected back to https://rebalance.diffusion.zone with a nice and fresh session cookie set. Subsequent requests by the user to e.g. https://rebalance.diffusion.zone/api will be picked up by the reverse proxy and get enriched by adding the users
jwt (Access Token) as the
Authorization header for requests passed to upstream services. Upstream services, trusting the JSON Web Keys of the above mentioned OAuth server, can now authenticate requests and authorize actions given the
jwt at hand.
Log in with $OSMOS is built extensible with respect to addition of new OAuth Clients. New clients can be added by submitting the OAuth Client as a kubernetes manifest complying to the spec like the one for rebalance.diffusion.zone. Merged PRs will be picked up by the underlying kubernetes clusters GitOps setup.
Challenges ran into
- It's not easy to run a osmosis fully sync a new node on mainnet. I ended up having to switch from older to newer versions of
osmosisdwith increasing block height. I get why this is happening, but I think we can improve on documentation there :). I did also not get
state syncrunning on mainnet, regardless of the seed and peer list.
- This is not only osmosis specific, but it was quite difficult to get IBC up and running locally. I intended to have osmosis running locally with faster reward cycles for making my strategies testable in a speedier way. While I managed to run
relayerlocally, dockerized and composed, it was quite hard to find all the relevant documentation for doing so.
- Major: Log in with $OSMO allows for strong authentication, by signing an actual transaction, for centralized applications complementary to osmosis, allowing for a new class of applications to be built on top of it
- Minor: I think I've found a slighly nicer way of manipulating the
osmosisdconfig files as a part of the build process. The whole
sedsetup omnipresent in the cosmos ecosystem for configuring
gaiadinside of Dockerfiles is not really readable and maintainable imho
- Launching a full node is not trivial. The on-chain data comes with a history, which the latest binary might not be able to understand
- It's not so easy to setup IBC locally, but you will definitely need a relayer
- There is quite a learning curve involved wrt. the REST APIs exposed by nodes in the network. While we do have a nice swagger documentation for cosmos rpc, it wasn't immediately clear to me how to properly write queries for transactions.
I think it'd be nice to explore how Login with $OSMO itself can become less of a central party. While in my opinion it's fine for centralized applications to exist complementary to decentral ones, it'd be nice for the authentication system itself to be trustless. Furthermore, I'd like to investigate how Login with $OSMOS can develop into the direction of becoming a platform such as
Auth0 to empower developers of the ecosystem to jumpstart work on complementary applications to osmosis. Working title: