rns.recipes

Hi there,

I see this forum lists things like reticulum-go as feature complete and microReticulum as WIP, but I'm just curious what vetting was done for those tags?

For reticulum-go, it doesn't enforce or support ratchets, meanwhile the human author somehow still marked that it does, which is odd. There is a list of other things that would be expected in an implementation that is feature complete which aren't there.

After seeing the drama around Ken's slop unfold, and Zenith's comments on alternative implementations, I was a little surprised to see that tag or claim on the Go implementation. I assume this is just a case of prematurely adding the tag and perhaps not deeply testing, but since there's extra scrutiny on alternative implementations given the recent thread, I thought the implementations listed here should at least be put under the same scrutiny, as I assume it's not meant to be an endorsement and was just an honest mistake.

Thank you.

After seeing the drama around Ken's slop unfold, and Zenith's comments on alternative implementations, I was a little surprised to see that tag or claim on the Go implementation

Ivan who develops that is active on the forum and he might have some more info regarding ratchet implementations. When I looked at it the Destination impl it had the ratchet functions, but they don't seem to be wired in.

I will ask him to see where that is on the roadmap. For now I set the tag back to WIP.

Thanks.

Though for some reason there is a duplicated entry now with a (WIP) text tag and not a real tag, while the original one also remains. Perhaps someone is sleepy... or maybe using LLM themselves?

Only joking... appreciate the quick reply!

Thanks for noticing. Ratchet APIs were implemented a bit ago but I am wiring it in for v1.0.2.

Speaking of implementations on the front page, Liam Cottle's rns.js hasn't had a commit for 1.5 years now, I think it's safe to say it's abandoned. Maybe replace it with reticulum-js, which for some reason has its own section at the bottom?

Evaluating implementations is difficult. We really need a standard test suite that verifies parity and interoperability with the reference implementation with absolute scrutiny. Implementations roll their own, which seems to be the weakest link in the chain, it can never be more correct than its test suite. Vibecoded parity/interop tests are notoriously untrustworthy.