rns.recipes

So, I've been wanting to solve the problem of stamp values having quite horrible dynamic range. The integer values, as you may have noticed, represent exponentional difficulty growth, which is annoying.

The good news is that I found the solution, and RNS will have 256 times the dynamic range in stamp value targets.

LXMF will inherit it too, of course, and it is (largely) backwards compatible. All old versions will understand and validate a 16.125 value stamp (counted as value 16 on old versions). Old versions won't be able to understand a 16.125 cost specification, of course, but this can be handled with some simple transitional logic. All good.

All in all, this means that stamp costs can now be adjusted finely. Much, much easier to deal with.

The question I'm interested in hearing people's opinion about is that of display convention. Should we stick with the current scale, now just in decimal form? For example 12.176, 15.5, et cetera? Or should we say to heck with it and invent an entirely new scale? Could also just be "integerized" so a current value 12 stamp would be represented as 3072.

Personally, I think sticking with the current version, just with added decimals is the least confusing, and it will avoid a lot of UI refactoring for app maintainers, so that's probably what I'd wager for.

But interested to hear if anyone has any insights here that I didn't think of?

I can tell y'all, this is a bit of a joy to finally see working:

> RNS.Destination(RNS.Identity(), RNS.Destination.IN, RNS.Destination.SINGLE, "test", "stamped")
[Verbose]  Identity keys created for <d137833dfa16acbfa307fdd027cfe75a>
[Debug]    Generating stamp with cost 25 for <0deaa67c83e2a454739b325b69845af4…>
[Debug]    Starting 10 stamp generation workers
[Debug]    Stamp with value 25.43359375 generated in 6.14s, 78553269 rounds, 12.79 Mrps
[Debug]    Generated and persisted stamp with value 25.43359375 for <0deaa67c83e2a454739b325b69845af4>

Identities themselves can also be directly stamped:

> RNS.Identity(value=21)
[Debug]    Generating stamped key with cost 21 for <9d5dc399e31b28f7f87bf4d68b46a20a…>
[Debug]    Starting 10 stamp generation workers
[Debug]    Stamped key with value 21.3984375 generated in 3s, 222ms and 497.94µs, 1265016 rounds, 392.56 Krps
[Verbose]  Identity keys created for <e38d6d813878f7b61ca9d8afcf839cb3>

And I realize now that I apparently suck at demonstrations. I should of course have run those with target values like RNS.Identity(23.141), but you get the point ;) It works like that as well, of course.

I like decimals and I also lean toward putting the values on a log scale. People usually expect things to be linear when they’re twiddling a slider or whatever, and I think it would make more sense to actually interact with a linearized scale for end users. It would also make it easier to add either hard limits or at least sensible recommendations for stamp values that won’t take forever to compute.

Also: this is awesome!

Good input @K8, thanks!

For those that want to play around with it already, the implementation is now pushed to Aleph. If you're interested in how it actually works, take a look at RNS/Stamps.py, a good place to start is the comments in the stamp_value function.

My only request is that there is a way to pass in an external stamp generator function, since multiprocessing sadly doesn't really work in chaquopy https://chaquo.com/chaquopy/doc/current/android.html#multiprocessing

Here's the diff of what Columba uses for LXMF (also has changes for tracking the interface an inbound message arrived on) https://github.com/markqvist/LXMF/compare/795fdaa...torlando-tech:LXMF:8912186e48b482a76bf04e2ac4b6c8940991aecc

I have no attachment to the implementation details of the code in my fork, just wanted to share for posterity.

Way back in December 2025 I noticed stamp generation was very slow in Columba and tracked it down to this essentially being single threaded in chaquopy, and this was how I figured it could be handled gracefully in LXMF: optional param to pass in a separate generator function, and in Columba I'd have the actual stamping done on the kotlin side with full multi threading support. But that's probably the extent of what I told Claude and it did the rest lol so if you have better ideas around the whole problem or code structure etc. feel free to reimplement as you please :)

Nice! Running now on my backbone, and I started to see this in RMAP (amazing!) If I could suggest anything, it would be this:

1. RMAP updates aside/out-of-scope, maybe capping the number of decimals to maybe two (or three?) would be enough customisability range for the majority of nodes? Not empirically proven, but just a gut feeling.

(from py: Fields: {'DST_COST': 251, 'PR_COST': 250})

Side note: I also noticed my values are different from what I assume my discovery stamp value should reflect unless I'm reading your post wrong, so adding below in case they are helpful

rnsd 1.6.0 @ commit ecd677ba7fe6ac0ad0bcc7ee8f33e84b2c725d15
discovery_stamp_value = 16
Running on Mac Studio, with Apple M4 Max

rmap reads all the sent fields from announces so for newly implemented rns fields it doesn't know what they are and put out a generic name or the field code. i think it will be updated for sure to allow the new release format display. i love this fractioned stamp new function, but i didn't get it right maybe... what is actual the difference from 16 to 16.125 for instance? can it be measured and displayed in 'time of cpu work' or similar index?

Yes, the destination cost and PR cost are not the discovery stamp value. Those two are new, separate stamp cost signalling that RNS 1.6.0 now includes in discovery annouces.

They tell other nodes what stamp costs are required to propagate announces through that node, and make path requests towards it, so the autoconnect system can choose transport nodes based on that information as well.

Destination cost is the required stamp value for a destination's annouces to be accepted and broadcast further on to the network. It is a one-time-per-destination generation, and thus usually higher value/difficulty. The path request cost is the stamp cost required per new path request, thus lower value. Also, these costs are at a lower overall difficulty tier than the LXMF stamps you might be used to, so they generate a lot faster than an LXMF stamp at value 23.5, for example.

There is already a prettycost(stamp_value) formatting helper method in RNS that formats these (potentially long) decimal values for display. Currently, 1.6.0 is not released yet, so as soon as it is, sites like rmap.world can use those helpers, or an equivalent, for consistent display and rendering.