Nostr + Bitcoin infrastructure for Ripple implementations - seeking collaboration

[Melvin Carvalho]

Hi everyone,

I've been following the discussions here for a while and I'm impressed by the ongoing work - Johan's ripple.archi with the 3-phase commit and penalty system, Evgeni's Swaptacular reaching production, the Villages.io relaunch, and the continuing evolution of Credit Commons.

I wanted to share some infrastructure components we've been working on that might be useful as shared building blocks, and get your thoughts on whether they could help the broader Ripple ecosystem.

## The components

**1. did:nostr for identity**

A simple DID method using Nostr's secp256k1 keys:
  did:nostr:<pubkey>

This gives us:
  - Cryptographic identity (same curve as Bitcoin)
  - Already used by millions in the Nostr ecosystem
  - Portable across implementations
  - One keypair for social identity + payments

Spec: https://nostrcg.github.io/did-nostr/

**2. Nostr relays for sync and discovery**

Instead of each implementation running its own servers for state sync,
Nostr provides:
- Decentralized relay infrastructure (thousands of relays exist)
- Real-time push via WebSocket subscriptions
- No single operator controls the network
- Could be used for trust line announcements, path queries, payment coordination

This doesn't replace the payment protocol itself - just the sync layer.

**3. Web Ledgers for state format**

This one is honestly still a draft (v0.1.4, W3C CG-DRAFT status):

https://webledgers.org/

The idea is a simple JSON-LD format mapping URIs to balances:
- Any URI can hold a balance (did:nostr, WebID, email, etc.)
- Interoperable across implementations
- Built on linked data principles

I'd love input from this community on whether this format could work for mutual credit, and what's missing. It's explicitly a "work in progress" and could benefit from people who actually build these systems.

**4. Blocktrails for optional Bitcoin anchoring**

For implementations that want Bitcoin-grade finality without requiring every payment to touch the chain:

https://blocktrails.org/

- Anchor state to Bitcoin via Taproot key tweaking
- SPV-verifiable (no full node required)
- Optional - only for high-value txs, periodic checkpoints, or disputes
- Doesn't replace other commit mechanisms, supplements them

## On the atomic commit problem

I've been thinking about a layered approach that builds on existing work:

1. **Bilateral netting first** - Most obligations can be cleared directly or via cycle detection, no multi-hop commit needed

2. **Nostr-coordinated consensus** - For online parties, fast coordination via signed messages on Nostr relays

3. **Johan's 3-phase commit with penalties** - For contested cases where game-theoretic enforcement is needed

4. **Bitcoin anchor** - Fallback for disputes or audit requirements

This isn't meant to replace what anyone's building - I'm genuinely curious whether these pieces could be useful as shared infrastructure across Villages, Swaptacular, ripple.archi, Credit Commons, etc.

## Questions for the list

1. Would did:nostr work as a common identity layer? Or are there reasons to prefer something else?

2. Has anyone experimented with Nostr for payment coordination? The real-time subscription model seems well-suited to multi-party protocols.

3. What would need to change in Web Ledgers to be useful for mutual credit? Happy to work on the spec with anyone interested.

4. Is optional Bitcoin anchoring valuable, or does it add complexity without benefit for most use cases?

I'm not trying to propose "yet another implementation" - more interested in whether we could converge on some shared primitives that benefit everyone.

Happy to dive deeper on any of these, or help integrate with existing projects.

Best,
Melvin

[Johan Nygren]

Hi Melvin. Did you see Hans-Florian Hoyer's three-party novation? I was not aware of it until a few days ago. It is ingenious. For the layered approach for the peer-to-peer money system, it seems to be the lowest layer. Cycle detection is multihop and much more complex. I think what frameworks are best suited for peer-to-peer money system + potential integration with blockchain is interesting, but I don't understand it well. For example, I don't know what " discovery" means in the context of trustline system. In my implementations, like here, https://gitlab.com/bipedaljoe/p2p-novation, each node is a username@domain. They already know each other and there is nothing to discover. The domain registry is the discovery mechanism. Simply finding "who is in the network" is a bit uninteresting, as it is trustline based and each person has theirs? Whichever framework is well suited or the best, it should be easy to build, for example, p2p novation on it to demonstrate the functionality and what it is good for. It is an extremely simple protocol. I think this coordination protocol may be ideal: https://gitlab.com/bipedaljoe/p2p-novation/-/blob/main/docs/novation-protocol.png.

[Johan Nygren]

We could discuss what frameworks are the best.

I see a need for 1) atomic p2p-transactions and 2) atomic routing. The framework does not handle atomic network layer, this the app does (3-phase commit for Ripple or loop clearing).

Atomic transactions seem ideally done with "Lockstep", a shared counter and alternating dominance (then just simple ACK/NACK, and a node who is dominant and already sending just ignores the other side). This is same I suggested a year ago, but now with ACK/NACK rather than just ACK. The pending Tx is persisted in storage together with the state transition from incoming Tx.

Atomic routing, nodes have to be able to reserve a route between two peers internally, to guarantee they can route. Send buffer can be full otherwise (unless infinitely large send buffer, it can always be full otherwise). Atomic routing returns error unless it succeeds, thus sender keeps retrying until it succeeds. The reservation prevents deadlock. Nodes should handle parallel routes for all peer pairs internally (to avoid an offline peer blocking the linked peer), but not more than that. No "route ID" here, just the peers linked by their peer identifiers. Global ID is for the network layer routing, like payment ID in Ripple, this is all app level.

This demonstrates such a framework: https://gitlab.com/bipedaljoe/p2p-novation/. P2P-novation as 500 lines of code "app". Ripple would be at most 2000 lines of code "app". The framework does any multi-user management with one node per user. It handles everything not app-specific.

It does not seem Nostr focuses on these things. It is some kind of other framework?

If anyone has a great framework that could run novation as an example in 500 lines of code, I am very happy to learn about it. Can Nostr do this? Three-party novation is the simplest example to demonstrate a framework well suited for trustline money.

[Johan Nygren]

Updated framework, https://gitlab.com/bipedaljoe/p2p-novation. Completely reworked from previous version.

What I call "atomic routing" treats Alice and Bob and Carol (or whoever is the routed hop) as a single atomic entity, more or less. It assumes the routing will work (as a single atomic entity), or it returns an error, forcing transaction to retry. Such retry could end up in deadlock (circular blocking) due to send buffer overflow. The send buffer overflow can be avoided by reserving send slots in advance.

In 3-phase commit with Pre-Commit step, if Bob is an intermediary, they will need to have reserved a "route channel" internally between Alice and whoever the next hop in payment chain is. They did so in the Prepare step (and Prepare was not "atomically routed", so it was allowed to return a NACK in case the path had timed out).

In https://resilience.me/resilience.c I instead manually use push routines in the "application layer" that ensures anything that needed "atomic routing" is pushed to the send buffer (and there sends are removed if they fail at transport layer...). With p2ptx I tried to generalize it to a framework.

Does Nostr solve these types of things? I.e., things a p2p trustline system seems to need?

Peace, Johan

[Johan Nygren]

Like Rust, this "ownership" for "internal routing channels" limit ownership to one. Only one peer can own a route to another peer. This ensures "atomic routing", at the time when the owner wants to route, it is guaranteed to succeed. 

Lockstep (now with ACK/NACK) guarantees a "payment channel" has a strict order of events. Thus when both parties want to sign off on any state changes at any step, there are no race conditions. Good for Lightning network / Raiden Network ("collateral" on top of Ripple).

This seems like convenient features for P2P apps. Does Nostr do anything of the sort? How does Nostr manage "atomic routing" if used for Ripple or Lightning network? Manual push routines in case of send buffer overflow (as I have done in previous versions)? Thus manually tracking internal state at the app-level?

Example use of "ownership" of routing channel at node:

PreparePayment: node attempts to reserve peer-in to peer-out route both forward (for CancelPayment or PreCommitPayment) and backwards (for RollbackPreparePayment). If failure, return NACK to previous hop. If success, route PreparePayment to next hop and return ACK to previous hop with Pending.AckRouteChannel set to previous hop. If next hop returns NACK, use  Pending.AckRouteChannel to route RollbackPreparePayment backwards, with Release as the ReserveAction on both Forward and Backward. If next hop returns ACK, all internal routing is now guaranteed to be atomic for CancelPayment, PreCommitPayment or RollbackPreparePayment (i.e., for phase 1 and 2 in the 3 phase). To make phase 3 atomic, PreCommitPayment reserves Backward (while it does Release on Forward). And on CommitPayment from the end recipient, Release is done (on what is then Forward, as it is from the seller direction...)

I have improvised, but it seems this "ownership" rule can be useful. Doing everything manually at app-level does work, as is proven with https://resilience.me/resilience.c, but a framework makes it easier for anyone to build a trustline-based app or P2P app in general. I ignored frameworks entirely when I built my reference implementation of Ripple a year ago, since it is, well, harder. It was easier to start manually (also why it is in C...), then generalize once everything has been proven manually. So that's what I did.

https://gitlab.com/bipedaljoe/p2p-novation

[Melvin Carvalho]

Hi Johan,

Thanks for the detailed technical breakdown, you're asking exactly the right questions.

Three-Party Novation:

I need to spend some time with Hoyer’s work, could you share a link? The novation-protocol.png diagram is elegant, and I'd like to better understand how it compares to cycle detection as the “lowest layer” primitive.

Our Framework: DNS + Nostr Hybrid

We currently use both approaches:

- DNS / domain identifiers for server-based nodes (e.g., username@domain)
- Nostr for nodes without servers (mobile, offline-first, relay-based)
- did:nostr as a universal identifier that works in both modes

This gives participants a choice: run a server when stronger guarantees are required, or rely on relays when simplicity and mobility are preferred.

On Atomic Routing"

You’ve identified the core gaps very clearly:

- Route reservation (to prevent deadlock)
- Lockstep ordering (to prevent race conditions)
- Ownership semantics (a single peer owns the route)

Nostr relays don’t provide these guarantees natively, so we’d expect to implement them at the application layer, much like in your framework. A question that follows naturally: could your p2ptx framework operate with Nostr as the transport layer for ACK/NACK and coordination messages?

Concrete Next Steps"

Would it make sense for me to try implementing novation (based on your ~500 LOC example) using:

- Your atomic routing primitives
- Nostr for message transport
- did:nostr for identity

That should give us a clear signal on whether this combination provides real value, or merely adds complexity.

Best,
Melvin

pá 16. 1. 2026 v 12:21 odesílatel Johan Nygren <joha...@gmail.com> napsal:

--
You received this message because you are subscribed to the Google Groups "Ripple Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rippleusers...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/rippleusers/7637395b-3f88-45b1-ac9b-20e1d89504c8n%40googlegroups.com.

[Johan Nygren]

Very happy for your kind words Melvin. Happy you also think atomic routing is essential. I think I exaggerated that it had to be limited to one at a time, it simply needs to limit to avoid "send buffer overflow" (a persistently stored send buffer...). And even if that seems like a small issue, apps otherwise needs to achieve exact same thing internally, which is quite a bit of code and mental effort.

Hans-Florian's 3-party novation - and that it can be generalized to a global p2p trustline network - sems to be a thing people just missed, in general. Hans-Florian has spent years promoting his "Twin Tokens" (which has central membership) whilst being something of an expert on novation since at least 1990? It would not make sense for him to do so, if people had realized that the fact it reduces to a three-person operation means it can be done with trustlines.

So there is not much material on it. I attach a PDF Hoyer sent me that he edited after I mentioned to him it could be done with trustlines, and now he specifically emphasizes his approach "is not trustline-based, the central membership is the trustline".

3-party novation itself is an old idea. It seems courts in Rome used to coordinate it, but it did not scale up to everyone doing it, all the time, I assume. For this, computers+internet are needed, that periodically scan if a node is an intermediary (has both IOU-in and IOU-out) and try to match in/out that know one another (by asking them...) and if the debtor can novate to the creditor without exceeding their credit limit there.



Cycle detection instead is "multihop in terms of trust", it is necessary to clear debt between strangers. It is much more complex. I mean, finding a path between three people, vs finding an arbitrarily long loop, is much more complex. And, novation does not find loops. It only finds if a person is an intermediary in debt, i.e., has IOU-in and IOU-out, and then it just checks if the debtor and creditor could instead do the same debt in between themselves (and this only works if there is mutual trust between all three, otherwise, loop clearing is needed).



Novation is strange, because it is exact same as happens in a bank (or "LETS" which is a bank that arbitrarily enforces or pretends everyone has to also for some reason trust one another...). A to bank to B to bank to C is same as A to C for the bank... One problem Ryan wanted to solve with Ripple is people should be responsible for their own debts, and I think this is true between strangers (across trust boundaries) and that multihop payments and loop clearing is needed there, but within trust boundaries, albeit person-to-person, organically, novation seems like the best lowest layer. It ensures the trust graph is actually multihop in terms of trust. If graph settled at A to B to C, the novation ensures A does not know C. Multihop payment only does that in "forward direction", but if I receive a multihop from someone, and at the same time have outgoing IOU, the node-in and node-out may actually know one another, and then novation remove one link in the graph.

I think for frameworks, best is to start with demonstrating novation. But plan to scale to Ripple or loop clearing. Trying Nostr + Lockstep + route reservation could be a good idea. I just don't yet know what role Nostr takes care of. There is also the "collateral" part, integrating possibility to use Ripple with "collateral" for Lightning/Raiden network, maybe Nostr functionality is good there. I would need to understand what Nostr is. I know Jon Stokes who helped me with Bitpeople.org likes it.

Peace, Johan

[Johan Nygren]

Hi Melvin,

On Lockstep, I have now realized exactly where it is actually important for Ripple. It is only at a race condition between finalize payment, and "cleanup payment" (where the chunked penalties had reached full payment amount). My first version a year ago that used Lockstep, did not have that race condition. My manual version afterwards - that I think was the right priority at the time - did, but it solved it by agreeing that the previous hop was always the general (the solution is always a singular general, either a constant one, or one that alternates). This is good, it pin-points the rationale for Lockstep in Ripple (rather than just as a general P2P framework).

Peace, Johan