Multi-user server for Ripple/Resilience now available (proxy)

[Johan Nygren]

This year in indirect collaboration with this community I solved "reserve payment attack" with 3-phase commit (allows Ryan's 2006 idea of slow gradual payments, the trick was to get a penalty on every phase), presented in Austria this summer (video), and I built a single-user server in C (prior to that in Golang, but I now focus on the C version). I now had AI build a multi-user proxy. It has an admin UI where the admin can boot up single-user processes, and the proxy then routes traffic so that the single-user processes all share the same public port. It also simplifies adding accounts within the same server (just need to specify username, otherwise needs both username+server address+port+symmetric key, and the key could be done with diffie hellman if the client supports PKI but this one does not).

Anyone can test it on https://jipple.net with users "alice", "bob", "carol", "dave" and "eve" (no passwords). And anyone can run it themselves with the codebase on https://bitbucket.org/bipedaljoe/resilience-c-misc/src/main/proxy.c or roll their own.

This seems to have been the original vision for Ripple Inter Server Protocol, except I have also built swarm redistribution into it (although people can set their trust index to 0 and not participate in the Resilience "module" on top of Ripple).

Peace, Johan

[Johan Nygren]

Big improvements on the proxy design. 

It now automates all key management for users that want that. With mTLS between servers, and they automatically generate keys for users. And users can use manual key input as well, if they have accounts with people who use it more P2P. This combines best of two worlds, user friendliness for those who want that, and true P2P (without reliance on central certificate authorities and such) for those who want that.

https://gitlab.com/bipedaljoe/proxy

It runs my C single-user instance for each user. I modified the C server so that it can run in "local" mode (makes proxy easier to build). This lets same implementation be used for stand-alone as well as for "federated" multi-user setup (with auto-key exchange...)

The proxy has a HTTP API. It is very easy to build the web server that interacts with it, and from there anyone can build front end UI.

Fully automated key management (becoming dependent on certificate authority...) is even easier than adding a PKI layer (although that is also possible) and with symmetric key only at the actual "nodes" all approaches are supported. Most people would probably prefer the fully automated approach, P2P people might prefer either PKI or just setting one symmetric key per relationship (which is also very easy to do, friends do not change that often, neither should trustlines).

The proxy is not finished, but the overall architecture is there. I have had AI build most of it (while I build the C server myself since it is more important). The C server is 100% finished. It also adds swarm redistribution on top of Ripple, and people can opt-in to use that by setting their "trust index" above 0, or just keep "trust index" at 0 and use Ripple normally. My priority has been a very robust "node" (the C server) and then some very user friendly layer on top of that and I think this proxy design is very user friendly and very easy to build.

This all seems to be aligned with the original vision for a Ripple Inter Server Protocol. With the "reserve payment attack" problem solved this spring, 19 years after the "gradual penalty" idea was first described by Ryan in 2006, it seems like it could be quite easy to finish a perfect proxy implementation, that can use the already well-built C server, and then people can build their own web-server to interact with it very easily. A robust foundation makes it easy. I have backed up my Resilience C server to Ethereum indexed to private key "resilience" as well (sha256 hash of "resilience"...)

If anyone wants to collaborate on perfecting the proxy (or work on web-app/UI part) it would be great. The proxy will probably just be around 1500 lines of code. It is very light weight, as is the C server (2500 lines of code incl. sha256...) You have my email...

Peace, Johan

[Johan Nygren]

Update, writing the proxy in Python

It is cleanest code for a simple reference implementation

Domain-specific API routes written in half an hour with Claude Max

https://gitlab.com/bipedaljoe/proxy-py/-/blob/main/routes.py

The rest is generic, the "federation_server" (that handles mTLS requests triggered by api/federation routes) only other domain-specific. It does the automated key generation for adding users and requesting to make payments. The part that makes things user friendly. And anyone who prefers per-user asymmetric key (as was Ryans vision I think) can build that on top of my Ripple implementation if they want, and anyone that prefers symmetric cryptography (one key per trustline) has that built-in (it is what my C implementation uses, the "federated" key generation is a layer on top of it and per-user asymmetric key would be as well).

Then once proxy is finished the front end is very simple.

And my Ripple implementation has "swarm redistribution" (guaranteed basic income by tax redistributed via the credit lines similar to electricity) built-in, and it is opt-in, people who do not want to voluntarily contribute keep their "trust index" at the default zero value (they are also cut-off from redistribution as credit lines gain "conductance" in proportion to tax paid, clearly seen in my C single-user codebase here in update_balance function).

This all seems very in line with Ryan's original vision for Ripple Inter Server Protocol, and that I solved "reserve payment attack" this spring by resolving how to do Ryan's original 2006 "gradual penalty" idea also seems very in line with the RISP vision.

Anyone who wants to collaborate you have my email, or if anyone has finished Ripple Inter Server Protocol on your end I would be happy to look at that instead but it seems to me that I am the first to build it as everyone has been stuck at 2-phase commit and not realized cancel-on-timeout and commit-on-timeout 2-phase had to be combined into a 3-phase to have a penalty on each phase, required since "gradual penalty" idea from Ryan in 2006 makes the cumulative timeout very long so it has to rely on the penalty instead and therefore requires penalty on both (all) phases. As I realized since I was "not listening" and trying to finish Ripple project and project Resilience myself.

Hakuna matata,
Johan

[Johan Nygren]

The proxy is now complete, published on https://resilience.me/ together with source code for the single-user instance.

Proxy not tested yet but looks good (Claude Max wrote it, I audited all of it). Will build the HTML+javascript in following days.

Hakuna matata, Johan

[Johan Nygren]

The proxy now tested and now works fully. Domain-to-domain trustlines and payments with automated key-management (but still allows users to use manual keys if they want to form trustlines and make payments to users who do not use "federated" layer) work. The proxy code in Python is very good. The C single-user instance is good. The HTML+javascript front end somewhat "vibe coded" (I have not audited every line) but the quality of Claude Max is incredible and the front end works well (trivial for anyone to roll their own front end...)

So we now have Ripple Inter Server Protocol, with path-based redistribution built-in.

All published on https://resilience.me, my domain I bought in 2014 two years after I invented path-based redistribution in 2012.

Test with "alice", "bob", "carol", "dave" or "eve" (no password) on https://jipple.net, and to test inter-domain you can use "alice" (no password) on https://johan.to.

Anyone interested you have my email...

Hakuna matata, Johan