rns.recipes

https://reticulum.network/manual/brandolinis.html

a8d24177d946de4f1f0a0fe1af9a1338:/page/blob.mu`g=reticulum|r=reticulum|ref=HEAD|path=AGENTS.md

Thanks for pinning this @Zenith.

I wrote this new chapter of the manual with the purpose of having an evolving reference and go-to guide to help clarify and alleviate the energy drain associated with the small number of, but very persistent and exhausting bad-faith actors that have been orbiting the community lately.

It is definitely not the only, or authoritative reference on this subject. There's plenty of information, examples and history on this and other forums, wikis and elsewhere. But I think having a resource that deals more directly with it, in a more focused manner, was timely at this point.

Feel free to use any material from it, quote it, copy it, link to it, print it as booklet, base a satirical play on it - whatever you'd like ;) I will keep it updated as necessary. If you find anything that's missing, let me know.

It is a long, and in some cases rather dense and verbose chapter. I tried to write it so that most sections can be read in isolation, or as a part of the whole. Therefore, some points and information are repeated here and there. This can still be improved, and it is a work in progress.

If you don't have the time to go through the 18,000 words of it, there's one thing, which is presented rather late in the chapter, in context of the more positive and forward looking sections, that I'd like to highlight here:

A History Of What Works

Let’s recall, because it is the ground truth this entire thing rests on, that the coexistence model has worked - is working, right now, at scale. Reticulum’s protocol decisions have been discussed and evaluated in the community, openly, for years. Protocol upgrades have been designed, coordinated, and executed between a loosely organised group of independent developers, node operators, and users - and have succeeded, repeatedly, without any corporate board, without any central command, and without the collapse that the skeptics predict every second week (while screaming for GOVERNANCE). The reference implementation has been developed in the open for over a decade, by a maintainer who answers for it, fixes bugs or issues within hours of their discovery, and is set down in code deliberately kept small enough (the entire protocol implementation under 15,000 lines, including its comments) for a human to read, verify, and challenge.

This is the empirical baseline that every narrative examined in A Movement Of A Dozen conveniently ignores, in order to justify:

• The claim that the project is a one-man dictatorship
• The claim that the community is excluded
• The claim that the networks need saving from their own founders

The reality, documented and reproducible, is that a loose community of humans coordinates complex technical evolution without the apparatus the narratives insist is missing. The health of the networks is not a promise for the future; it is a demonstrated property of the past and present, under the leadership and community model that brought it into existence and navigated it through difficult decisions and situations over a decade. My job is to keep it that way, and you can be damned certain that I take it seriously.

The conclusion of that section, is in my opinion one of the most important points of that entire document: That we, a small group of dedicated, loosely organized, and very different individuals from all kinds of backgrounds, and scattered across the planet, without any central hierarchy and governance, have and continue to manage to successfully create, maintain, nurture and make available a complex and powerful communications technology centered on real human values, for many thousands of people who actually need it, and have placed their trust and reliance in us to do so.

That is a success worth cherishing and being proud of; not just as any single individual, but as a community of people who naturally take responsibility for the areas of work we excel at, care about and do our best in. The results speak for themself.

Thank you so much, every one.

haha nice !

Is this because of my comment in https://rns.recipes/forum/general/a-gentle-look-at-prns#post-2902 ?

I've been thinking about expanding on and providing some more substantial basis for reference and discussion on all of these topics for a while, but it was a bit of a complex task, because some of the topics touched on are inherently so novel and unexplored. So yes, in those regards, your excellent article @p1ld7a most definitely helped frame and crystallize the thinking on the machine learning sections in a way that spurred on and motivated an attempt of some answers.

It definitely doesn't answer everything you raised there, or imagines itself to provide an exhaustive exploration in any capacity, but I hope you can see the connecting threads, and find the ideas constructive towards finding those answers.

I get the idea behind Bandolini's Reference but it's awfully long and I keep thinking it's AI generated with the repeated dashes and excessively verbose paragraphs. It reads more like a rant than a manual page about AI "cleanroom" implementations. If something's too long for someone to want to read, they're not gonna read it and will keep doing exactly what it's meant to tell you not to do.

I probably should have added a section on the anon wise-crack phenomenon as well.

I get the idea behind Bandolini's Reference but it's awfully long

The concept of "reference" may have escaped you.

Apparently, even my initial post above is too much for you to read. From that:

It is a long, and in some cases rather dense and verbose chapter. I tried to write it so that most sections can be read in isolation, or as a part of the whole. Therefore, some points and information are repeated here and there. This can still be improved, and it is a work in progress.

Regarding:

I keep thinking it's AI generated [...] It reads more like a rant [...] If something's too long for someone to want to read

Comprehension failed successfully. First live functional demonstration. Congrats.

System operating nominally.

Reminds me of Linux in that a central maintainer accepts patches and controls the project, and the maintainer comes across as toxic in online discourse around the project occasionally but it overall ends up working fairly well for the project.

Some have even gone as far as proposing that such is the only viable way to successfully manage and ensure the constructive development of this class of systems. So far, little evidence has been presented to the contrary.

In this relation, "toxic" is usually defined in relation to a single, unknown outsider, hiding behind an Anonymous handle, in the face of rational arguments or a slap on the wrist for being outrageous, having emotions they cannot constructively deal with, and reactively reaching for the justice police hotline's summoning call.

I'll take a break from here for a while, and when I return, gratefully accept any potential donations of bullshit in this thread as further reference material for the chapter.

Real criticism, patches, debate and proposals for additions are of course also very welcome. Provided you have actually read the thing you are proposing changes for, and are not hiding yourself behind an anon handle or newly created account.

If you cannot stand by your words with an ident hash or a handle known by the community, your words have very little weight and value, and you can expect them to be largely ignored.

Unless, of course, they can actually stand alone on the sole merit of their logic, evidence and accuracy.

This article was long but well worth the read! Thank you Mark and EVERYONE else who ensures Reticulum stays healthy and free.

There was food for thought here. Some of what intrigued me was the "hidden" moral axis in committee "approved" open source licencees and how they differ from that of Reticulum. A moral stand is a moral stand, whether it points to how people are allowed to use and share the software OR who is allowed to do use if freely.

Quote from Mark:

Both licenses contain moral axioms. The difference is that the Reticulum License states its axioms out loud:

Intentionally restricting the way that millions of people use and build upon a foundational communications technology - The mechanism of copyleft

Intentionally restricting a small number of organisations from using the technology to violently harm human beings - The mechanism of the Reticulum License

Which of these is more free? The answer is not a matter of committee approval. It is a matter of what the word “free” means to the people whose freedom is at stake. The question of whether “open source” requires the blessing of a particular licensing orthodoxy is examined in Open Source Means Open Source.

Further it was interesting to read that for some individuals, the below list means the project is not open-source. In my naivety I thought open-source just meant everyone could read the code, and then you could put a license on top of that. This is Marks statement declaring just how open and permissive the license really is:

Open Source, in this project’s understanding, means:

• The source code is available, to everyone, without charge

• Everyone may use, copy, modify, merge, publish, distribute, sublicense, and sell the software

• No one is discriminated against as a person - developer, user, community, or project

• The protocol itself is dedicated to the public domain, where no one can own it

• And the single, plainly stated condition of the license is that the work shall not be consumed to harm human beings, or ingested to replace the humans who made it

If that is not “open” by a definition written in the 1990s, then the definition is the thing that has failed - not the software, and not the people who use it.

Open source means open source. It was true before the committees existed to certify it, and it will remain true after they are gone.

This quote as well is an important message I think deserves to be repeated. Mark has ensured for a decade that this protocol could not be influenced by people with big money. Let's show the respect we can for this dedication to keep the protocol free in any way we can, be it network building/thoughtful coding/donating.

The sustainability problem

Reticulum has been developed and maintained for over a decade by a single person, supported by a small group of contributors and network-building users, without corporate backing, without VC funding, through several serious attempts at commercialization and takeover from both the corporate and the ideological side. The license is part of what makes that sustainable, and possible at all.

It ensures that the specific, painstaking labor of the reference implementation cannot be hijacked to undermine the intent of the project, while leaving the protocol itself, the mathematical rules of how Reticulum works, dedicated to the public domain, where it belongs to humanity and can never be owned. Anyone can implement the protocol, provided they themselves invest the actual work and effort. What the license protects is the work, and the intent embodied in it.

The core of the article though is about the "attacks" on the protocol (by LLM copies of the protocol and by people with "caring concerns"), how it is affecting the protocol and the community using it and how we can all be more aware of it.

The attacks from several fronts and the consequences thereof:

They are three fronts of the same operation, run by the same cast.

• The license attack and other urgency-engineered narratives are the cover: They supply the ideological justification for treating the reference as illegitimate, and needing replacement.

• The ports are the inventory: they supply the “replacements” that the narrative claims the ecosystem needs.

• The takeover narrative is the objective function: the repeated, persistent, escalating claim that the reference should be replaced, and that the speakers themself are the natural heirs.

And the results of this:

People may believe their own narratives entirely, or partly, or not at all; the pattern is the same in any case, and the pattern is what matters here, since it is the exact thing that has been so insidiously destructive and resource wasting for the actual Reticulum project and community, ever since Reticulum was more widely discovered, popularized, and became a prime target for all sorts of grift known to man.

The consequences are very real:

• Time. The community’s scarcest resource is the attention of skilled people who actually build and maintain the network. The campaign converts that attention into reactive defence, on a cycle with no end.

• Harm. Hastily machine-generated implementations, marketed as drop-in replacements and carrying traffic onto shared networks, mislead users and can damage the network and its neighbours. We, the actual reticulum community, all rely on these networks every day, and it is my belief that we need to defend them. The fabricated measurements and laundered authorship examined in this chapter are not editorial embellishments; they are the mechanism by which real users are induced to run unverified, and often destructive software.

• Erosion of the currency of trust. Every manufactured scandal, every fluently polite smear, every fabricated “movement” debases the currency of trust and degrades it for everyone; including, most of all, the honest projects that come after. This is deep harm, and it is the primary reason this chapter exists.

Whatever the intent - profit, control, attention, or a simple, obsessive inability to stop - the mechanism is the same, and the response should be calibrated to the mechanism as a whole, not to the individual person acting as the current avatar for it.

Again - I want to send a heartfelt thanks to all the developers and the dedicated community around Reticulum.

seems like you have cleared up a bit on your polarized view a bit, great :-)

The first is this chapter. It was produced with machine assistance, openly: the structure was directed by the human, the material was assembled with the tool’s help, every conclusion, every line, every slight nuance of meaning and semantics was examined, edited, and accepted or rejected by the human, and the process described publicly - including the precise characteristics of the technological assistance framework used. The human can answer for every claim in these documents, because the human made the decisions the claims rest on.

here you make the destinction that a "human has to understand every claim", a proper gatekeeper but elsewhere you make "the line" at "human should understand every line of code" which means a proper "10x developer" (to use a bad description)

i think if a project openly discloses its use of ai contributed code (authored by claude etc) but reviewed, and tightly driven by humans that understand every claim, able to read every line of code, but not necesarrily able to produce every line of code (numerous reasons), then that project has as much a chance of being worthwhile to go through or use as any "stackoverflow" written project before it.

remember we are all living in a copy paste reality, no such thing as originality only sampling from stochastic gathered prior knowledge.

btw i understand your critique of prns at a certain point, thanks for laying it out. seems like there has been some deliberate avoidance of facts, like proper ai attribution and some rather airy claims. i agree with you that this is bad "engineering". or maybe its just "snake oil".

but there is any ways to do things, many ways to use tools. for example i am vibe coding this repo: https://github.com/sloev/spore/blob/master/docs/ROADMAP.md OPENLY using ai. i discose every use of ai, i tell openly about project status, what it does what it doesnt.
its not ready for any consumption at all. it is based on sampling IDEAS from and studying years of projects. i feel great working on it. it gives me great understanding of concepts like forward secrecy using ratched keys and i have learned about fountain codes which still amazes me right now.
another also openly disclosed ai driven project is https://sloev.github.io/emergent/ where i research how simple "mechanics" can rise to complex life-like behavior.

i use ai to gather info and i use ai to write it. but i am sifting every answer through my mind, guiding it, feeding it even more info. it started as a gist with me writing some thoughts and using ai to extend with more prior art references etc https://gist.github.com/sloev/36555d00d485020635fa9110813f7124/revisions

For me "vibe coding" is as silly a term as coding.
for example i once met a dude that said he went on the siberian express once a year to write firmware for some cpu project. he said "then i just download the documentaton for said language, go on the train forth and back again and wupti firmware is written, completely offline" i guess this is a proper coder, but the code might look the same as one 5 years ago that sampled stack overflow answers etc.

anyway: great to hear that

"The public discussion around machine learning and software development has been derailed, by the loudest voices on both sides, into a farcical fight between “AI enthusiasts” and “AI haters”."
cause it definitly sounded like you and zenith had a shared vibe on an anti vibe crusade

Cant you vent somewhere else? Go get a gym subscription or something.

@Mark Related to the licensing discussion, could you share your rationale for using copyright transfer for contributions instead of a CLA? It's been an open question for me. I keep thinking that rngit could enable a nice workflow for accepting cryptographically signed CLAs from contributors with less administrative burden, but obviously admin overhead isn't the only reason to avoid them.

Personally I have mixed feelings around it. A lot of contributions to a project like this are things that wouldn't exist outside the context and history of the bigger project. In cases like that I don't think twice about it. In other cases contributions might be somewhat more standalone, or might be independently useful in some other context. Basically all the interesting code I've ever written gets filed in a library in my head for future reference and it's nice to not have to additionally tag all of it with copyright caveats (and there's already enough of my past creative work that's owned by an evil corporation and I have to quarantine in my brain).

I ask this as a fan of the Reticulum license itself. I wish more projects committed to their values the way you have. I agree that the way people react to "moral clauses" in licenses is often telling, if not of their own specific intentions, then at least of how embedded their thought is in capitalism and the violence and extraction it normalizes.

An important part of this seems to be the distinction of the protocol and the implementation.

But protocols are written in specs, and whenever this gets brought up the answer is that the reference implementation is the spec. So how could one use the protocol without also looking at and learning from the implementation?

The clean room example states one shouldn't look at the original code.

To Mark and the other dedicated Devs, thank you for this gift and all of the continued hard work.

I am honored :) thank you !!!

I am also glad that this opened a potential better way on how we react towards AI projects (slop or not).

Now, if I may, it would be nice to add a small definition of the law on top of the page:

Brandolini’s Law, also known as the bullshit asymmetry principle, states that it takes much more effort to disprove false information than it does to create it.

Cheers !

@K8 That's a really good question, and something that was never really explained. The rationale behind it was pretty simple, and boils down to more or less just the administrative burden you mention.

At the time, I did not see any effective way to handle this, which would not cause so much extra work and setup around it, that it would make the small amount of contributions coming in almost pointless, in terms of time I'd have to spend setting it all up, doing the acrobatics, getting people to somehow "sign" in some way, reminding them before submitting, et cetera. There was not any appealing infrastructure for handling this, that did not rely on some sort of centralized or platform lock-in, which was something I could not accept.

I'm not up to date on what exists in this area currently, but at the time, it was my impression that the CLA setup many projects were using was mostly symbolic, and wouldn't hold in a court, if any dispute did occur.

So to be honest, the copyright transfer was a quick fix in lack of anything better. The simplest catch-all that would not cause problems down the road, and which would be at any time reversable. Not an ideal solution, but what would work for a time. Then all kinds of other things happened, and it stayed that way.

(Of course, before saying the following, I have to say here that this is not a legal statement, the contribution conditions still apply until changed in the guidelines, et cetera, et cetera)

For the record, I do not persanlly consider any code contributed to Reticulum or any other project that I maintain something that those projects, or myself, own or hold copyright over, in the context of being able to control or have any say in what other things the author of that code wants to do with it. That would be preposterous, and is directly against my core conceptions of what creative work is. What you create yourself, you own and are free to do with as you please. Those are required base conditions of labor, a necessary foundation for an economical system that respects people. Oh lord, it's hard not to veer this directly into an armchair dissertation on capitalism. Slam the brakes, Mark.

So yes, I completely understand the annoyances of having code in your brain filed away under "corporation lock", I'm completely allergic to that shit myself.

For what it's worth, and I know that it's not worth much unless you know me really, really well, I would never excercise the copyright granted from any contributor against any use of their own creative work, no matter if that use disagrees with my own moral axioms, or anything else.

The only purpose that transfer serves is to ensure that someone cannot state a claim against RNS down the road, and demand that ten lines of code they added years ago are no longer allowed to be used in the system.

Therefore, I can promise fully and confidently, that copyright for any code contributed will be transferred back to their original owners once there is a reliable and well-thought out mechanism for handling a CLA or similar system, which can ensure the very limited purpose the copyright transfer was a catch-all for.

But I'm not really the type that just finds a recommendation and then rolls with. It'll take me days, if not weeks to get a full overview of the legal landscape before I could confidently land on any candidate.

As it tends to go with these things, if none of the people who have actually contributed asks or have a problem with it, I usually end up working the more functional parts of the system instead. Rare is the afternoon that I sit down and really feel the urge to write a CLA.

That being said, integrating cryptographic signing in rngit connected to commit identities is a brilliant idea for a system like this, and could serve as a useful prototype for other kinds of distributed agreement systems as well. Very nice thinking on that one! Hadn't even crossed my mind. That could make the whole thing a bit more exciting to approach ;)

@Mark Awesome, thanks for explaining! I had a feeling and hope you were approaching things in that way, and reading more about where you're coming from with the copyright transfer really helps to build trust to the point that its not really a concern for me anymore. Working toward some kind of CLA system is wonderful, though, and it's great to get the best of both worlds (trust + agreements).

I spent a lot of years as a feral forest creature, burned out on technology after working for an evil corp, and hardly touching a computer. I really appreciate how often you, in many small ways, through word and deed and just being who you are, keep affirming that I've landed in the right community where I can put my skills and experience to use for good.

@Sojourner, that's also a very good point, and something that is left a bit floating in the chapter. It focuses more on dispelling the "clean-room" myth that I've met so exhaustingly many times lately.

Answering it in any kind of satisfying manner will be a bit of night-drive, so bear with me.

First of all, I'd like to say that historically, protocols were written in specs. I've read a lot of RFCs. The systems they describe range from incredibly simple to really quite complex. Writing a good RFC is an art. The problem with that is also that products of art quickly attain immutability, and every minor decision to change something in a new versionof the protocol will usually entail months of discussion on just how exactly.

Also, I am not the IETF, and I doubt the IETF is very interested in Reticulum. All that kinda-joking aside, the same problems pertain to an "informal formal" specification.

Additionally, and more importantly, a protocol like IP is a lot simpler than Reticulum. The original RFC 791 is only 43 (quite small) pages. You can read and understand it in an afternoon. Then there's all the errata, subsequent RFCs that update previous ones, and so on, but let's leave them out of the picture for now.

A full, correct, verified and signed off "formal" spec for Reticulum would be a massive undertaking. And no, those LLM-generated "Reticulum specifications" that are floating around are not that; they're what I'd refer to as the minimal conformal surface of one: The minimal outer surface shape that conforms to the presentation of the semantics contained in "Reticulum Protocol Speficication". The inside of that manifold can take on an almost infinite amount of configurations that will support that outer presentation, but a vanishingly small number of those are actually, and correctly, a formal Reticulum protocol specification. A large part of arriving at that result is a very specific, very meticulous, and very longwinded process.

(I promise I will actually answer your question eventually)

The Reticulum we have today would not have been possible to create from a pre-conceived RFC. In some basic sense, that is how the project started. There was a very rudimentary protocol specification, which the initial versions were built from. But they are nothing at all like what we have today. If I should have kept those up to date while working, we would not have the actual networks now. So I chose very early to let the implementation be a reference implementation instead, and focused very hard on making that a core quality and first priority of it. Which is also why RNS is not called just Reticulum; it is an implementation of the protocol, and the reference.

For a very complex system, like Reticulum is, I think a functional reference is much better than a static and dead spec. Maybe in ten or fifteen years, when everything is settled by the very fact of networks being much larger, and change next to impossible, I can take six months off and write a full, "official", stamped and signed protocol specification. But anything less time of work on that would be laughable, even if you shipped me an NVL72 and fed me intravenously.

On the other hand, the reference implementation exists now, is runnable, proven in the wild, easy to test and integrate with, has very readable code, clean structure, a small amount of well-defined modules and files, and is less than 15,000 lines of code (for the core, excluding utilities). Most importantly: It still receives updates. There are still key parts of this system missing. The core protocol and functionality is all ready, but there are important pieces still missing.

(Almost there now)

It serves two purposes currently:

• Act as the primary driver for building and intermeshing real, physical networks on a stable, reliable, well-tested and very functional foundation, both locally and globally
• Provide the primary reference material for building other implementations, both for specific purposes, and general purpose implementations.

Regarding the second purpose, I think the right way to go about this is to start at the base, verify, add higher layers, verify and then iterate. A full transport node drop-in replacement is not the base. The core cryptographical machinery is.

Then basic networking functionality, then a full packet-handling leaf node, then the more advanced protocol primitives; links, resources, channels, buffers. Each of those steps are weeks of testing, by humans, in many different situations, in the real world.

Now, requiring that anyone should do just half of this without looking at reference would be sadistic, and it is directly contrary to entire point of having a reference implementation.

(Here we are. Yet another obligatory poem that I am not a certified legal professional, and this is, for all intents and purposes, hyperbole. Yes, it's silly, but it has to be said, and I'm doing my best here, okay?)

No implementation needs to be a clean-room implementation, and you do not need to achieve such an insane goal to be able to assert your own copyright over your own work. I cannot give you a specific set of boxes to tick, since that is something that a court will decide according to the specifics of every case, but in simplified terms, the decision process is very straight-forward:

Did you actually make this, and was substantial human creative work required to do so?

Very Important! Remember: The examples below would be exactly the same whether RNS had been licensed under MIT, GPL, or the Reticulum License. That has nothing to do with the matter. The matter is, that you are asserting copyright over the work. In all of the above cases, you could license the derivative under the Reticulum License (or your own, compatible sublicense that, additionally forbade downstream derivatives to use the letter e), and be totally fine!

If you create the most criminal piece of junk port, intentionally make it work only 10% of the time, and try to sell it for $1,000,000 with a Ricky Martin commercial, there is nothing that I can do about that, as long as you follow the license conditions! I wouldn't like it, but there would be nothing I could (and therefore would) do. Other than rant royally about it, of course. Which I would.

Imaginary Case 1

You read the code of the reference until you understand it like you had spoken Reticulum since age 5, and then write an implementation in Brainfuck with your own bare hands.

No court would contest that you own that masterpiece. Ever.

Would I ever, in the wildest of psychedelic trips, as much as bat an eye in the direction of trying to claim any rights over that? Lol.

Imaginary Case 2

You start writing a Reticulum implementation in C, reading and referencing the Python code, carefully building up the core primitives, using the reference to test against, evolving, verifying, iterating. Your commits show this evolution clearly, because you did it.

Would a court side with some troll or madman who tried to steal your genuine work here? That's highly unlikely and would have to rest on some incredibly rigorous proof coming from the claimant. I'm not saying it's impossible, but then again, very few things are.

But wait, why is that okay? You did look at the code, right? Yes, and that is not a problem, because you have (a) demonstrated substantial creative work and (b) the underlying protocol, the language you are implementing here is public domain, and therefore itself unencumbered by any rights or patents. This means it is only the actual code and documentation that can be the subject of any claims, not an additional auxillary also attached to it.

Would I be an arsehole? No, of course not.

Imaginary Case 3

For brevity of this post, let's assume more or less the same setup as Case 2, only that you now use an LLM to also read the code and teach you about it. You use it to debug and scan your code when things go wrong, help you write tests (which are ingesting your own, original code).

Same result. You're doing the work.

Imaginary Case 4

In this example, you not only use the LLM to learn about the code, but you occasionally have it generate methods or functions directly from the reference implementation source code or documentation. The work is still genuinely yours, and the project history can prove it.

Legally speaking, we're now getting into much more muddy water, where I cannot give you any exact pointers, and the decision would rest on the particular scope and details of the case. It would be assessed according to the overall amount of material you used and generated, and what you did yourself, along with a whole range of other factors.

Would I consider filing a claim against such an implementation? No.

Imaginary Case 5

You ingest the reference implementation source code and/or documentation into a machine, and have it generate, in substantial parts or fully, a Reticulum implementation.

Would a court accept your claim to copyright over that "work"? Lol.

Would I consider filing a claim against such an implementation? Absolutely.

I've filed cases for a lot less, for example people using Creative Commons licensed photographs I took commercially without permission. It's generally a very easy process for small claims, and quite streamlined in most of the world.

Okay, I hope that clarified things considerably.

In reality, if you want a better understanding of issues such as this, it is very helpful to look up copyright case decisions and read them. Lot's of them. It's actually not as boring as it sounds.

Thanks @K8, that means a lot to hear :) Appreciate you being here and helping out! Sometimes I feel like I could use a few years as a feral forest creature.