Multi-user server for Ripple/Resilience now available (proxy)
39 views
Skip to first unread message
Johan Nygren
Sep 8, 2025, 1:12:01 PMSep 8
to Ripple Project
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
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
Sep 12, 2025, 12:56:01 AMSep 12
to Ripple Project
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
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
Sep 12, 2025, 7:06:58 PMSep 12
to Ripple Project
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
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
Sep 12, 2025, 10:11:40 PMSep 12
to Ripple Project
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
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
Sep 13, 2025, 9:46:39 AMSep 13
to Ripple Project
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
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
Johan Nygren
Sep 20, 2025, 3:29:54 PMSep 20
to Ripple Project
There is 5 servers up and running now, I just did a multi-hop payment from my domain johan.to to another "canadian-dollar.money" (run by Taylor, see announcements here) via an intermediary jipple.net. Works perfectly.
So, reserve payment attack solved (picking up where Ryan got stuck in 2006), true Ripple Inter Server Protocol implemented, a perfectly user friendly layer on top of it all that does not sacrifice true P2P functionality (i.e., you can still manage your own keys, but if you want to you can choose to automate it) and the core software is just 2500 lines of code, with the simplest possible design. And, it has my swarm redistribution built-in (as this is a Ripple group people might care more about Ripple than my idea, but what I built is then also the first true decentralized Ripple).
Registration on https://jipple.net is now open for anyone. Works unless it is spammed. But in a multi-server settings there can be thousands of smaller servers so the issue with such attacks is less (and such vulnerability does not exit in core network).
Anyone wanting to run a server, it is very basic Python + the single-user C server, all available on https://gitlab.com/bipedaljoe/proxy-py or https://resilience.me. I am def...@johan.to if anyone wants to form a trustline.
To use 3-phase commit to also make Lightning network possible or Interledger ("inter-payment-channel" perhaps sufficient design for that?) and make all such networks inter-compatible, is probably fairly easy, the 3-phase commit is the key, and the presentation of it in Austria this summer (video here) is fairly good, the idea is very logical and common sense, but it was a bit hard to discover, it required that you "did not listen" and tried to do things yourself, so you could notice the other 2-phase commit (finish-on-timeout) and then bridge 20 years of work with that. With it, all decentralized multi-hop payment systems are possible and they can all be inter-compatible probably (I already sketched on such design, but Resilience is my priority so it comes first). The 3-phase commit is the key. And it was invented thanks to the discussion and feedback here in this group...
Peace, Johan
https://i.imgur.com/zlQJdMv.png
So, reserve payment attack solved (picking up where Ryan got stuck in 2006), true Ripple Inter Server Protocol implemented, a perfectly user friendly layer on top of it all that does not sacrifice true P2P functionality (i.e., you can still manage your own keys, but if you want to you can choose to automate it) and the core software is just 2500 lines of code, with the simplest possible design. And, it has my swarm redistribution built-in (as this is a Ripple group people might care more about Ripple than my idea, but what I built is then also the first true decentralized Ripple).
Registration on https://jipple.net is now open for anyone. Works unless it is spammed. But in a multi-server settings there can be thousands of smaller servers so the issue with such attacks is less (and such vulnerability does not exit in core network).
Anyone wanting to run a server, it is very basic Python + the single-user C server, all available on https://gitlab.com/bipedaljoe/proxy-py or https://resilience.me. I am def...@johan.to if anyone wants to form a trustline.
To use 3-phase commit to also make Lightning network possible or Interledger ("inter-payment-channel" perhaps sufficient design for that?) and make all such networks inter-compatible, is probably fairly easy, the 3-phase commit is the key, and the presentation of it in Austria this summer (video here) is fairly good, the idea is very logical and common sense, but it was a bit hard to discover, it required that you "did not listen" and tried to do things yourself, so you could notice the other 2-phase commit (finish-on-timeout) and then bridge 20 years of work with that. With it, all decentralized multi-hop payment systems are possible and they can all be inter-compatible probably (I already sketched on such design, but Resilience is my priority so it comes first). The 3-phase commit is the key. And it was invented thanks to the discussion and feedback here in this group...
Peace, Johan
https://i.imgur.com/zlQJdMv.png
Johan Nygren
Sep 23, 2025, 5:05:43 PMSep 23
to Ripple Project
mTLS now removed and server-cert only TLS used (in "federated" layer that automates the key management so users only bother with username@domain)
1st to solve reserve payment attack, 1st true implementation of Ripple Inter Server Protocol (and also has my redistribution system Resilience)
core infrastructure is just 2400 lines of code incl. sha256, with no dependencies more or less except UTP
https://resilience.me
peace Johan
1st to solve reserve payment attack, 1st true implementation of Ripple Inter Server Protocol (and also has my redistribution system Resilience)
core infrastructure is just 2400 lines of code incl. sha256, with no dependencies more or less except UTP
https://resilience.me
peace Johan
Reply all
Reply to author
Forward
0 new messages