@ 30b99916:3cc6e3fe

#btcpayserver #lightning #lnd #powershell In this article I'm going to go through basics of what it takes to implement a BTCPAY server instance on a VM cloud hosted computer or on your own computer. I've been running BTCPAY server now for about 2 years and haven't done much with it other than host an LND lightning node. After watching a [BTC SESSIONS tutorial](https://www.youtube.com/watch?v=-GJr4XjRCPo), this motivated me to do a little more with my BTCPAY server instance. A BIG Thanks goes out to BTC SESSIONS for getting me motivated again. Of course, none this would be possible without the grand contribution the BTCPAY server team as made. I take a knee to these giants before me. ==**Step 1**== is if you don't know anything about BTCPAY server then watching the BTC SESSIONS tutorial is a requirement. Be aware that your being directed to use a one-click process for doing BTCPAY server installation these days, but this leaves one without the knowledge and experience needed to trouble shoot your own installation. My old saying is: ``` "You can't learn how to ride a horse by watching someone else do it. You have to experience it for yourself". ``` If you want to skip the experience, then this article is a waste of your time. ==**Step 2**== is to decide where to host your BTCPAY Server instance, self-hosting on your own hardware, hosting on cloud instance, or buy a node in the box solution that supports the installation of BTCPAY server. There isn't a wrong answer here so choose the option that works for you. Initially, I started with the LunaNode hosting solution and later implemented a second instance on Oracle Cloud Infrastructure (OCI) because they offer an always free VM instance using the parameters below. I have yet another implementation of a full Bitcoin core and LND instance running on my home server. ``` Shape: VM.Standard.A1.Flex OCPU count: 4 Network bandwidth (Gbps): 4 Memory (GB): 24 Local disk: Block storage only (200GB) ``` Currently, I'm still running the full Bitcoin core with LND but it has no active channels and it is only available via Tor. The OCI instance is still running strong and the LunaNode instance have been removed. In the 2 years of hosting BTCPAY server with OCI, I've paid 0 hostings charges. Other hosting providers are charging close to $75 dollars per month for this type of configuration. You do have to use a credit card to reqister. [Oracle Cloud](https://www.oracle.com/cloud/free/). The last I checked the always-free offer is still available. If this is your first exposure to BTCPAY server, I recommend you create a new Linux VM just for the sake of gaining the experience of installing and configuring the software. Then implement your final solution on the hardware or hosting service of your choice. Your are going to need a DNS name so here is one of many options available - noips.com offers a free Dynamic IP address or low cost for a non-nagging one. Just to be different, I'm going to do things in reverse order just so you'll get a glimpse of a functional implementation before umbarking on the journey yourself. The link below links to my Point-of-Sales app running on BTCPAY Server hosted on OCI. [Barnyard Market](https://btcpayserver.sytes.net) The BTC SESSIONS tutorial referenced above does a great of demonstrating how to do implement a Point-of-Sales app. My LND Lightning node alias is ==SANJOSE_UBETCHA== and you can go to **mempool.space** to lookup information on it, if desired. Us small time lightning node operators need to band together if we are going to stand a chance at surviving. We can't compete on a liquidity basis but we can compete on a connectivity basis, if we herd together. A warning to those considering running your own lightning node: It's a big club and your not in it. -George Carlin At the time of implementing my BTCPAY server instance running a lightning node was the only option for accepting lightning payments. But, now with NWC you can use your own lightning wallet to receive and make payments in sats. You'll need to pay some sats to one the big club members to open a payment channel though. This is likely the cheaper route to take when all things are considered. I'm seriously considering dumping my LND instance and maybe even lightning too. If Lightning is just turning into a big player game, I'm out. Here are the core things that I configured with my BTCPAY server instance. ``` 1. A DNS name pointing to my Linux server. a. securely configured Linux system Davide-btc has done great job of outlining the steps https://github.com/asyscom/Node-Security-Hardening-Guide-for-BTC-and-Lightning-Node-on-Ubuntu b. git cloning of the BTCPAY software. c. PowerShell installed because I want it. I'm not going to justify this. ``` When I originally started this article, I thought it would be easy to just reference existing documentation to get the job done, but this information is being dropped in favor one-click installation. So the information below is from my old notes which may be outdated, so please let me know if something is incorrect or missing. At this point, 1(a) and 1(c) should be completed and tested so only 1(b) is left to do. 1(c) is optional BTW. Prove it: If you CAN'T answer yes to the following questions, don't proceed with installing BTCPAY server. ``` You can you ping your DNS name from a remote network? You can you ping your IP address from a remote network? You can ssh to either IP or DNS address and get a console session? Do you have root access on your linux system (sudo su -)? ``` Here are my old notes on the steps I took for installing BTCPAY Server on a Linux server. ``` # Login as root sudo su - # Create a folder for BTCPay mkdir BTCPayServer cd BTCPayServer # Clone BTCPay docker repository & set environmental variables git clone https://github.com/btcpayserver/btcpayserver-docker cd btcpayserver-docker # Run btcpay-setup.sh with the RIGHT AND DESIRED PARAMETERS export BTCPAY_HOST="YOUR DNS NAME" < PUT YOUR DNS NAME HERE export NBITCOIN_NETWORK="mainnet" export BTCPAYGEN_CRYPTO1="btc" export BTCPAYGEN_ADDITIONAL_FRAGMENTS="opt-save-storage-s" export BTCPAYGEN_REVERSEPROXY="nginx" export BTCPAYGEN_LIGHTNING="lnd" < SKIP THIS ONE IF YOU DON'T WANT LND LIGHTNING NODE export BTCPAY_ENABLE_SSH=true # Run the setup script . ./btcpay-setup.sh -i ``` After setup process completes, it will take some time before the blockchain is fully in sync so don't PANIC. Also, capture the console output generated from the setup script and save it to a text file for later recall about what it did. Browsing to your DNS NAME should now greet you with the BTCPAY Web server interface. The excellent BTC SESSIONS tutorial can now guide you from here. ==Next steps.== How is your opertional knowledge of Docker? If it is lacking you need to bone up on it. https://www.docker.com/ Here some useful things to know how to do with docker on your BTCPAY server instance. List the BTCPAY server docker container services that are actually running and their version information. ``` #ssh to your server sudo su - cd <to your BTCPAY install path> cd Generated cp docker-compose.generated.yml docker-compose.yml docker ps --format "table {{.ID}}\t{{.Image}}\t{{.Names}}" rm docker-compose.yml ``` List the logs for a given docker container service ``` #ssh to your server sudo su - cd <to your BTCPAY install path> docker logs --tail 100 btcpayserver_bitcoind # the prior example lists all the container names that can be used with 'docker logs' command ``` To renew the SSL certificate restart the *letsencrypt* container ``` sudo su - cd <to your BTCPAY install path> docker restart letsencrypt-nginx-proxy-companion ``` Hopefully, this illustrates why you need to be famliar with the docker commands. [BTCPAY Server Docs](https://docs.btcpayserver.org) This is the official documentation source and I've just touched on a few of them. [BTCPAY Server Chat](https://chat.btcpayserver.org) This is the official chat channel. Go here when you are stuck and need to ask the experts on BTCPAY server. Now, I'm going move onto some of the automation stuff I've recently done with the REST Api(s) related to BTCPAY server. ==BTCpay== and ==BTCpayApi== are two PowerShell scripts that I wrote to make use of the LND REST api and the Greenfield REST api. Generally, speaking REST api(s) provide the ability automate many of the tasks assoicated with software packages like LND and BTCPAY server. The BTCpay and BTCpayApi creation is a proof of concept work to determine if it can free me up from the daily grind of button clicking on the associated GUI applications to get the same work done. At this point, I'm finding great value in using these REST api(s). You can refer to [BTCPayApi](https://cadayton.onrender.com/scripts/BTCpayApi.html) to get the full details about these 2 scripts. BTCpayApi sole function is to invoke the REST Api(s) and return PowerShell objects to the caller. BTCpay (the caller) is responsible for submitting the correct input to BTCpayApi and processing the returned PowerShell objects as desired. One of the useful commands is showing the status of the current active channels as shown below.  Another useful command is performing a Circular Rebalance between two active channels.   ==Notice how the channel balances have changed between Node4 and Node5.== The node names being displayed are aliases that I made up to replace their real alias names. There is an xml configuration file called, LNDnodes.xml that maps these alias names to their public key and chan_id. One of the more difficult aspects of creating these scripts was ensuring that it did not leak sensitive data by embedding the values or keeping clear text data in a file. The current choices for protecting sensitive data are the key-value store implemented with ==Keybase==, the key-value store implemented with ==Hashicorp Vault==, and lastly the most laborious and error prone option is to input the data manually when prompted. Each key-value store options comes with their own set of requirements. Since Zoom has purchased Keybase, the future of this application is unknown. In addition, Keybase is a centralized service so they could lock out your account on their whim. So, I'm going to focus on using the key-value store with Hashicorp Vault which has recently been purchased by IBM. The Hashicorp Vault solution that I'm using is totally self-hosted instance using the free download version. My corporate IT days provided me some exposure to this product and I never consider it for personal use until I discovered it had a REST api. Okay I said, "move over Web interface" here I come. The script, ==VaultApi== totally automates all aspect of using Hashicorp Vault. See [VaultApi](https://cadayton.onrender.com/scripts/VaultApi.html) for details. Now with that history out of way, let's dive into configuring stuff in BTCpay/BTCpayApi. ==The task at hand is to update the configuration file, BTCpayApiCfg.xml.==  I've collaspe the Keybase section because I don't want it to be a distraction and no this is my real path information that I'm using. Lines 4, 7, 21, 26, and 27 are the lines that need to be updated. The url format is, https://mydomain/quack/flap/ Looking a line 21, it is just executing the VaultApi script to go get the admin macaroon for LND. It would be very trivial to implement support for any other password manager that supports either CLI and/or REST Api for retrieving data. ==Hope this information has been of help.== Thanks! for reading it.

@ 66675158:1b644430

In the twilight of his days, Myrddin sat upon the weathered stone bench overlooking what remained of Libertalia. His ancient hands—once steady enough to craft the most intricate mechanisms known to the Free Realms—now trembled as they rested upon the gnarled walking stick he had carved from windfall oak. The city below, once a marvel of independent districts connected by the invisible threads of mutual cooperation, had become something else entirely. Something monstrous. The sun was setting, casting long shadows across the Grand Plaza where the Central Authority's banners now flew. Myrddin's eyes, still sharp despite his five hundred and seventy years, could make out the uniformed guards patrolling in perfect synchronicity. The sight made his stomach turn. "I built the foundations for freedom," he whispered to himself, "and they have erected prisons upon them." A figure approached from behind, footsteps deliberately heavy to announce their presence. Myrddin did not turn. "Master Myrddin," came the voice of Thalion, one of his few remaining former apprentices not yet captured by the Authority. "The Council of Remnants awaits your wisdom." Myrddin scoffed. "Wisdom? What wisdom can I offer now? I who planted the seeds of our destruction through my own shortsightedness?" "You could not have known—" "I should have known!" Myrddin's voice cracked with the force of his outburst. "Every great civilization before us fell to the same disease. Centralization. The pooling of power into fewer and fewer hands until the many are crushed beneath the weight of the few. I knew this. I studied the ancient texts. I designed our systems specifically to prevent this very outcome." Thalion remained silent, allowing the old engineer his moment of self-recrimination. "Come," Myrddin finally said, rising with difficulty. "Let us not keep your Council waiting. Though what good words can do against the machinery of oppression, I cannot say." As they walked the hidden path down from the overlook, Myrddin's mind drifted back to the beginning, to the founding of Libertalia four centuries earlier... --- The Founding Council had gathered beneath the great oak that would later mark the center of Libertalia. Twelve visionaries from twelve different traditions, united by a single purpose: to create a society where no person would rule over another. Young Myrddin, barely forty years old but already renowned for his brilliance, unrolled the plans he had spent a decade perfecting. "The Nexus System," he explained, pointing to the intricate diagrams. "A method of connection that requires no central authority. Each district, each guild, each family unit can connect to the whole while maintaining complete sovereignty over their own affairs." Lorien the Sage, eldest among them, leaned forward with interest. "You propose that trade, communication, defense—all can function without a ruling body?" "Not only can they function," Myrddin replied with the confidence of youth, "they will function better. A decentralized system is resilient. Cut one connection, and a hundred others remain. Attack one node, and the system routes around the damage. But most importantly, when power is distributed, corruption finds no fertile ground in which to take root." "And what prevents a group from seizing control?" asked Marwen the Warrior. "From forcing others to submit to their will?" Myrddin smiled. "The architecture itself. See here—" he pointed to a complex series of interlocking mechanisms, "—the Consensus Protocol. Any attempt to exert control beyond one's rightful domain triggers automatic resistance from the system. The more one tries to centralize power, the more difficult it becomes." "You speak of mechanisms as if they have will," Marwen said skeptically. "Not will, but design," Myrddin corrected. "Like water flowing downhill. I have designed a system where power naturally disperses rather than concentrates." The Council debated through the night, questioning every aspect of Myrddin's design. By morning, they had agreed to build their new society upon his principles. Libertalia would be a constellation of sovereign individuals and voluntary associations, connected but never controlled. For three generations, it worked exactly as Myrddin had envisioned. The Free Realms prospered as never before. Innovation flourished in the absence of restrictive oversight. Disputes were resolved through mutual arbitration rather than imposed judgment. The Nexus System facilitated trade and communication while preserving the independence of all participants. Myrddin, his lifespan extended by the alchemical discoveries his system had made possible, watched with pride as Libertalia became the envy of the known world. But he had made one critical error. --- "You created a system that required vigilance," Thalion said as they descended toward the hidden meeting place. "Perhaps that was the flaw." "No," Myrddin replied. "The flaw was in believing that making something difficult would make it impossible. I should have made centralization not merely hard, but unachievable by any means." They reached the abandoned mill that served as the Council's current hiding place. Inside, two dozen faces turned toward them—the last free thinkers in a land that once celebrated independence above all else. Myrddin took his seat at the rough-hewn table. "Tell me," he said without preamble, "how much worse has it become since we last met?" A woman named Sera, who had once been the foremost architect in the Eastern District, spoke first. "The Authority has implemented the Unified Identification Protocol. No citizen may trade, travel, or even purchase food without presenting their Authority Crystal for scanning." "And these crystals track their movements?" Myrddin asked, though he already knew the answer. "Every step," confirmed Sera. "Every transaction. Every word spoken near an Echo Stone." Myrddin closed his eyes briefly. Echo Stones—his invention, meant to record important discoveries and preserve the wisdom of the ages. Now perverted into tools of surveillance. "The schools have been consolidated," added a younger man named Ferris. "All children now learn from the same Authority-approved texts. The history of Libertalia is being rewritten. They claim you designed the Nexus System to eventually unite under central guidance." "A lie," Myrddin spat. "But a believable one," Thalion said gently. "You did build the infrastructure that made this possible, however unintentional." Myrddin could not deny it. The Nexus System, designed for voluntary connection, had been gradually modified over the centuries. What began as simple efficiency improvements eventually created vulnerabilities. The Consensus Protocol, once the guardian of decentralization, had been subverted by those who understood its mechanics but not its purpose. "The disease always begins the same way," Myrddin said, addressing the Council. "With promises of efficiency. Of security. Of protection from unseen threats. The centralizers never announce their true intentions. They speak of unity while forging chains." "We know this, Master Myrddin," said Sera impatiently. "What we need is a solution, not a history lesson." Myrddin smiled sadly. "The history is the solution, if only we would heed it. Every great civilization before us fell to centralization. The Aurelian Empire, whose emperors claimed divine right to rule all lands beneath the twin moons. The Dynasty of Eternal Harmony, whose bureaucracy grew so vast it consumed half the realm's production. The Jade Confederation, whose Council of Nine became a single Overlord within three generations." He paused, gathering his thoughts. "In every case, the pattern was identical. Power, once distributed among many, gradually accumulated in the hands of few. Those few, corrupted by their unnatural position, made decisions that benefited themselves rather than the whole. Resources were misallocated. Innovation stagnated. The system became brittle rather than resilient. And when crisis came—whether famine, war, or natural disaster—the centralized structure collapsed under its own weight." "Yet people never learn," said Ferris bitterly. "Because the benefits of centralization are immediate and visible, while its costs are delayed and diffuse," Myrddin replied. "The Authority provides convenience today at the cost of freedom tomorrow. They offer solutions to problems that would resolve themselves naturally in a decentralized system." "What was your mistake, then?" asked Thalion. "Where in your design did you leave the opening for this disease to take hold?" Myrddin's face darkened with regret. "I built a system that was resistant to centralization, but not immune to it. I created tools of such power and efficiency that they became irresistible targets for those who would control others. And most critically, I failed to encode the philosophical foundations of decentralization into the system itself." He looked around at the faces of the Council, seeing in them the last embers of the fire that had once burned so brightly in Libertalia. "I believed that people would choose freedom if given the option. I did not account for how seductive the promises of centralization would be. How easily people would trade liberty for convenience. How willingly they would accept security over sovereignty." --- The decline had been gradual, almost imperceptible at first. It began two centuries after the founding, with the creation of the Coordination Council. "Merely to improve efficiency," its proponents had argued. "To eliminate redundancies in our wonderfully decentralized system." Myrddin, by then well into his second century, had voiced concerns but was overruled by younger generations who found the original Nexus System too cumbersome for their modern needs. The Coordination Council was given limited authority to standardize certain protocols across districts. Within a decade, those standards became requirements. Requirements became regulations. Regulations became laws. The Council, originally composed of representatives who returned to their districts after brief terms of service, gradually transformed into a permanent body of administrators. By the time Myrddin recognized the pattern, the disease had already taken root. The Coordination Council had become the Central Authority. The voluntary associations that once formed the backbone of Libertalian society were now subordinate to its dictates. He had tried to warn them. He had written treatises on the dangers of centralization, had spoken at public forums, had even attempted to modify the Nexus System to restore its decentralizing functions. But he was dismissed as an outdated thinker, unable to appreciate the "improvements" of modern governance. Now, four hundred years after the founding, Libertalia was Libertalia in name only. The Authority controlled all aspects of life. The districts, once proudly independent, were administrative zones whose boundaries could be redrawn at the Authority's whim. The guilds, once self-governing bodies of skilled craftspeople, were now licensing bureaus that enforced Authority standards. And the people—the free, sovereign individuals for whom Myrddin had designed his system—had become subjects. Citizens, they were called, but the word had lost its original meaning of self-governance and had come to signify merely a registered and tracked unit of the Authority. --- "We cannot defeat the Authority directly," Myrddin told the Council of Remnants. "They control too much. The military, the food supply, the Nexus itself. Any direct confrontation would be suicidal." "Then what hope remains?" asked Sera. "We must build anew," Myrddin said, his voice finding strength in purpose. "Not reform, but replace. The old system cannot be saved—it is too thoroughly corrupted. We must create a parallel system that makes centralization not merely difficult, but impossible by its very nature." "How?" several voices asked at once. Myrddin reached into his worn leather satchel and withdrew a small crystal, unlike the Authority Crystals in both color and cut. "I have spent the last fifty years designing what should have been built from the beginning. A truly decentralized system that cannot be subverted because its very operation depends on remaining distributed." He placed the crystal in the center of the table. It pulsed with a soft blue light. "The Arx," he explained. "Each crystal contains the complete system, yet functions as only one node within it. No node can control another. No group of nodes can outvote or overpower the minority. Consensus is achieved not through majority rule, but through voluntary participation." Thalion picked up the crystal, examining it skeptically. "The Authority will never allow this." "They need not allow what they cannot detect," Myrddin replied. "The Arx operates on principles the Authority's systems cannot recognize. It exists alongside their network but remains invisible to it." "And what can this network do?" asked Ferris. "How does it help us against the might of the Authority?" "It allows us to trade without their knowledge. To communicate without their oversight. To organize without their permission. And most importantly, to remember who we truly are—sovereign individuals who require no masters." Myrddin stood, his ancient frame seeming to straighten with the weight of his purpose. "Centralization is not merely inefficient or unjust—it is a disease that infects and ultimately kills any society it touches. It promises order but delivers stagnation. It promises security but creates vulnerability. It promises prosperity but ensures that wealth flows only to those who control the center." He looked each Council member in the eye. "I made a mistake in believing that making centralization difficult would be enough. This time, we will make it impossible. The Arx cannot be centralized because its very operation depends on distribution. Any attempt to control it causes it to fragment and reform beyond the controller's reach." "And if the Authority discovers these crystals?" Sera asked. "They can destroy individual crystals, but the network will continue. They can imprison those who carry them, but more will take their place. The design is now the important thing, not the designer. I have encoded the knowledge of how to create these crystals within the crystals themselves. The idea cannot be killed." Myrddin sat back down, suddenly looking every one of his many years. "I cannot undo the damage my oversight has caused. I cannot restore the Libertalia I helped to build. But I can give you the tools to create something better—something truly resistant to the disease of centralization." The Council members looked at one another, hope kindling in eyes that had known only despair for too long. "How do we begin?" Thalion asked. Myrddin smiled. "We begin by remembering what we have forgotten. That no person has the right to rule another. That voluntary cooperation always outperforms forced compliance. That systems must serve individuals, not the reverse. That decentralization is not merely a technical architecture but a moral imperative." He gestured to the crystal, still glowing in Thalion's palm. "And we begin by building connections that cannot be controlled. Person to person. District to district. Free association by free association. The Authority believes itself invincible because it sits at the center of all things. But when there is no center, there is nothing to seize, nothing to corrupt, nothing to control." As night fell over Libertalia, the Council of Remnants listened as the ancient engineer outlined his vision for a truly decentralized future. Outside, the Authority's patrols marched in perfect order, their uniformity a testament to the disease that had consumed what was once the freest society in the known world. Myrddin knew he would not live to see his new design reach fruition. But for the first time in decades, he felt something like peace. He had identified his error. He had created a solution. And most importantly, he had ensured that the knowledge would outlive him. Centralization was indeed a disease—perhaps the most persistent and destructive disease ever to afflict human societies. But like all diseases, it could be overcome with the right medicine. And the medicine was not more centralization, not better rulers, not wiser authorities. The medicine was decentralization. Complete, uncompromising, and irreversible decentralization. As the meeting concluded and the Council members departed with their crystals, Myrddin remained seated at the table. Thalion lingered behind. "You know they will come for you eventually," his former apprentice said. "You are too significant a symbol to ignore forever." Myrddin nodded. "Let them come. An old man is a small price to pay for the rebirth of freedom." "Your new system," Thalion said hesitantly, "you are certain it cannot be centralized? That we are not simply repeating the cycle?" "Nothing created by human hands can be perfect," Myrddin admitted. "But I have learned from my mistake. The Arx does not merely resist centralization—it actively works against it. The more one tries to control it, the more it disperses. It is not merely a technical solution but a philosophical one." He placed a hand on Thalion's shoulder. "Remember always: centralization benefits only those at the center. For everyone else—the 99.999% who stand at the periphery—it is nothing but chains disguised as safety. Never again can we allow the disease to take root by promising efficiency at the cost of sovereignty." Thalion nodded solemnly. "I will remember." As his former apprentice departed, Myrddin turned to look out the small window at the city below. The Authority's lights blazed from the central towers, pushing back the natural darkness of night. So much power, concentrated in so few hands. So much potential, wasted in the service of control rather than creation. He had lived long enough to see his greatest work corrupted. With what time remained to him, he would ensure that his final creation could not suffer the same fate. The Arx would spread, node by node, person by person, until the very concept of centralized authority became as obsolete as the diseases his earlier inventions had eradicated. Myrddin Myrddin, Master Engineer of the Free Realms, closed his eyes and allowed himself, just for a moment, to imagine a world reborn in true freedom. A world where the disease of centralization had finally been cured. It would not happen in his lifetime. Perhaps not even in Thalion's. But it would happen. Of that, he was certain. For the truth that the Authority and all centralizers before them had never understood was simple: humans were not meant to be controlled. They were meant to be free. And in the end, that natural state would reassert itself, no matter how elaborate the systems of control became. Centralization was a disease. And like all diseases, it would eventually meet a cure.

@ a09fb9cb:83231556

..before the beginning there was nothing and nothing is (god) consciousness... ...nothing is also known as the void of the un-manifested, the abyss, the infinite, the timeless eternal, the formless, the unrealised and un-manifested potential... nothing is consciousness and consciousness is also known as choice. > *To Be, or not to be*\ **-* William Shakespeare In the beginning (god) consciousness chose to give FORM to itself as the "i"... nothing is the canvas of the creator, upon which CREATiON is PAiNTED... consciousness MANiFESTED... | CONSCiOUSNESS The "i" is both the (LiGHT) PARTiCLE & THE WAVE, but which came first I hear you asking... the particle (the one), then, once the particle had been everywhere, covering the void of the un-manifested, the particle had to Begin to avoid itself, and became into BEiNG, for no two THiNGS can occupy the same SPACE and TiME in a single moment. And so the particle began to avoid iTSELF and in so doing became THE WAVE... and thus the dance was born. The YiN and the YANG, DARKNESS & LiGHT. > **Please note:**\ > DARKNESS is not nothing. DARKNESS & LiGHT are both the CREATiON of nothing... nothing is the creator. the creator CREATED DARKNESS & LiGHT in order to EXPERiENCE CREATiON... level 1 "i" (one) & 2 "I" (TWO) of REALiTY or DUALiTY. particle (one) | WAVE (TWO) do You see the crossing of the 2 I's (T) (WAVES), the symmetry and therefore balance (W) and the infinite (O) made MANiFEST? DARKNESS EXiSTS to allow the LiGHT to illuminate... DARKNESS gives LiGHT meaning and vice versa. DARKNESS allows for SPACE and LiGHT allows for TiME. The "i" is the one, but the one is not god. god is nothing and cannot be known WITHiN FORM & TiME. (god) consciousness chose to MANiFEST the "i" and henceforth DUALiTY was given the appearance of FORM WITHiN THE PHYSiCAL UNiVERSE. The more the WAVE travels, the more the WAVE has to avoid iTSELF and thus We come to know FREQUENCiES... and FREQUENCiES create the iLLUSION of MATTER, as WAVE ENERGiES APPEARiNG AS FORM due to WAVE DENSiTY & COMPLEXiTY. We know god because "i AM" CONSCiOUSNESS or "i AM" consciousness MANiFESTED... and this is self-evident because "i AM". I EXiST. ## The Key Here is the key to unlock the DUAL MEANiNG of lower case and UPPER CASE: - "i AM". I EXiST. - i = nothing = consciousness = choice = infinity = eternity = here = (k)now(ing)... - I = CONSEQUENCE = AWARENESS = consciousness MANiFESTED... = CONSCiOUSNESS = SOMETHiNG = LiGHT = MiND = (IDENTiTY = iLLUSION = (THOUGHT = (CONCEPTS + CONSTRUCTS)) = PERSONALiTY) = Ego = (i + I = we = You) - YOU = U = OTHER = (IDENTiTY = REFLECTiON = iLLUSION) = THERE = THEN = EGO - We = i + I + YOU - When "We" become fully present in the moment of ENLiGHTENMENT YOU vanish and i + I = EVERYTHiNG (THE END), but then what comes next... - You = u = Enlightened Self = Present Moment Awareness = Now (in this moment) "We" understand each other... because "I" now know who "You" are, and "YOU" now know who "i" am... ## ...and finally All this is meaningless, unless We ask ourselves ...what is the meaning of acceptance? 

@ 23a2c1c3:8a8bfa1f

testoooooo

@ 23a2c1c3:8a8bfa1f

# prova articolo 01 contenuto Verum sine mendacio, certum et verissimum. Quod est inferius est sicut quod est superius, et quod est superius est sicut quod est inferius ad perpetranda miracola Rei Unius. Et sicut omnes res fuerunt Uno, meditatione Unius: sic omnes res natae fuerunt ab hac Una re adaptatione. Pater eius est Sol, mater eius Luna. Portavit illud ventus in ventre suo. Nutrix eius terra est. Pater omnis telesmi totius mundi est hic. Vis eius integra est, si versa fuerit in terram. Separabis terram ab igne, subtile a spisso, suaviter cum magno ingenio. Ascendit a terra in coelum, iterumque descendit in terram, et recipit vim superiorum et inferiorum. Sic habes gloriam totius mundi. Ideo fugiet a te omnis obscuritas. Hic est totius fortitudinis fortitudo fortis, quia vincet omnem rem subtilem; omnemque solidam penetrabit: Sic mundus creatus EST. Hinc erunt adaptationes mirabiles, quarum modus hic est. Itaque vocatus sum Hermes Trismegistus, habens tres partes philosophiae totius mundi. Completum est quod dixi de operatione solis.

@ 866e0139:6a9334e5

*Autor:* ***[Milosz Matuschek](https://www.freischwebende-intelligenz.org/p/kein-krieg-ohne-lugen-wenn-es-um).*** *Dieser Beitrag wurde mit dem* *[Pareto-Client](https://pareto.space/read)* *geschrieben.*&#x20; *** *Seit Sonntag (zu allem Glück auch noch meinem 45. Geburtstag) ist bei mir noch ein bisschen mehr los als sonst – und das liegt an Ihnen.* ***[Der Aufruf zur Gründung der „Friedenstaube“](https://www.freischwebende-intelligenz.org/p/lassen-wir-die-friedenstaube-fliegen),*** *einer unzensierbaren Friedenspublikation mit bekannten Stimmen aus der kritischen Szene, der Friedensbewegung und von Bürgerjournalisten ist bei Ihnen auf mehr als nur offene Ohren gestoßen! Ich bin regelrecht geplättet von den vielen Reaktionen, die ich noch gar nicht alle beantworten konnte.* *Ich danke Ihnen herzlich für das Vertrauen in mich (auch wenn ich natürlich stark auf die Autoren angewiesen bin) und die überwältigenden Reaktionen: Es sind hunderte Abonnements für den Newsletter eingegangen, darunter einige bezahlte Abos und Förderabos und auch die ersten Genossenschaftsanteile wurden gezeichnet! Was mich besonders freut: Gut zehn weitere freiwillige Autoren wollen mitmachen und arbeiten bereits an den ersten Texten. Damit darf ich schon jetzt verkünden, dass die Genossenschaft definitiv gegründet werden kann, die Friedenstaube wird fliegen. Wie hoch und wie weit, das liegt dann nun nur noch in unser aller Hände.* *Der Anfang ist jedenfalls gemacht. Die nächsten Wochen werden besonders arbeitsintensiv, ich bitte Sie um etwas Geduld: Aufbau einer Kernredaktion, Organisation der Abläufe, technologische Entwicklungsarbeiten, Genossenschaftsgründung etc. stehen jetzt auf der Agenda. Mit Tom-Oliver Regenauer darf ich den ersten Autor im redaktionellen Kernteam verkünden, der sich nicht nur große Verdienste im Schreiben erarbeitet hat (siehe u.a. sein Buch* *[Hopium](https://shop.tredition.com/booktitle/HOPIUM/W-647-217-513)) sondern auch über Managementerfahrung verfügt; mit weiteren helfenden Händen bin ich im Gespräch.* *Ich freue mich auf die (auch für mich) neue Erfahrung, quasi aus dem Nichts eine Publikation mit Redaktionsbetrieb und freien Autoren auf einer gänzlich neuen technologischen Infrastruktur aufzubauen. Es wäre illusorisch zu glauben, dass alles glatt gehen wird, denn wir starten quasi „on the go“, aber im Fall von Frieden oder Krieg gilt es, keine Zeit verstreichen zu lassen. Ich arbeite nach dem Motto „Tun, statt reden; zeigen, statt ankündigen; liefern, statt versprechen“.* *[Die ersten Texte zum Thema Frieden sind bereits publiziert](https://pareto.space/read?category=friedenstaube), ein halbwegs geordneter Betrieb sollte ab April realistisch sein. Die Liste der Autoren wird regelmäßig aktualisiert, schauen Sie gerne* ***[hier](https://www.freischwebende-intelligenz.org/p/lassen-wir-die-friedenstaube-fliegen)*** *(oder noch besser:* ***[hier](https://pareto.space/u/friedenstaube@pareto.space)**) immer wieder herein. Dort finden Sie auch noch mal alle Infos, wenn Sie die Friedenstaube unterstützen wollen.* ***Ab 1000 Euro/CHF werden Sie Genossenschafter, also Verleger!*** *Auch an die bisherigen Unterstützer des Pareto-Projekts, der technologischen Basis der Friedenstaube, will ich hiermit schon etwas zurückgeben: Alle Spender für Pareto werden die Friedenstaube immer kostenlos lesen können. Sie, die Leser dieser Publikation haben die technologische Basis mit aufgebaut, die uns zur weltweit ersten, zensursicheren Friedenspublikation macht. Uns Autoren steht damit ein kompetentes Support-Team von inzwischen über zehn Entwicklern (und weiteren Helfern) an der Seite, welche die Friedenstaube am Fliegen halten werden.* Kontaktieren Sie mich gerne zu allen Fragen (je kürzer die Mail, desto früher kommt die Antwort): **milosz\@pareto.space** oder **kontakt\@idw-europe.org** *** JETZT ABONNIEREN: ***[Hier](https://pareto.space/u/friedenstaube@pareto.space)*** *können Sie die Friedenstaube abonnieren und bekommen die Artikel in Ihr Postfach, vorerst für alle kostenfrei, wir starten gänzlich ohne Paywall. (Die Bezahlabos fangen erst zu laufen an, wenn ein Monetarisierungskonzept für die Inhalte steht).* *** * Für **50 CHF/EURO** bekommen Sie ein Jahresabo der Friedenstaube. * Für **120 CHF/EURO** bekommen Sie ein Jahresabo und ein T-Shirt/Hoodie mit der Friedenstaube. * Für **500 CHF/EURO** werden Sie Förderer und bekommen ein lebenslanges Abo sowie ein T-Shirt/Hoodie mit der Friedenstaube. * Ab **1000 CHF/EURO** werden Sie Genossenschafter der Friedenstaube mit Stimmrecht (und bekommen lebenslanges Abo, T-Shirt/Hoodie). **Für Einzahlungen in CHF (Betreff: Friedenstaube):** [](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F3fdee17a-c22f-404e-a10c-7f87a7b8182a_2176x998.png) **Für Einzahlungen in Euro:** Milosz Matuschek IBAN DE 53710520500000814137 BYLADEM1TST Sparkasse Traunstein-Trostberg **Betreff: Friedenstaube** Wenn Sie auf anderem Wege beitragen wollen, schreiben Sie mich an: <milosz@pareto.space> oder <kontakt@idw-europe.org>. *** ### Was bewegt mich beim Thema Krieg und Frieden? Erlauben Sie mir einen kurzen persönlichen Prolog: Ich stamme aus Schlesien. Mein Urgroßvater kämpfte im I. Weltkrieg bei Verdun. Mein Großvater wurde in die Wehrmacht eingezogen, kämpfte im Partisanenkrieg in Jugoslawien, verlor Hand und Auge. Ein Bruder meiner Großmutter entzog sich und landete in Dachau. Ich kenne meine Familiengeschichte nur in groben Umrissen, vielen wird es ähnlich gehen. Einige meiner schlesischen Vorfahren waren später vor allem Lokführer. Aufgrund der bewegten schlesischen Geschichte wechselten sie mehrfach die Uniform. Die Tätigkeit und Fahrstrecke blieb die gleiche. Für wen oder was kämpften sie in Kriegen in welchen Uniformen? Vermutlich wussten sie es selbst nicht. Auch ich könnte heute nicht genau sagen, welche Interessen und Mächte die Kriegsmaschinerie bedienen. Doch ich wüsste es gerne und Sie vielleicht auch. Kämpfen ohne letztlich zu wissen für wen und warum: Wozu? Krieg simuliert Sinn und Notwendigkeit und lässt einen am Ende mit den großen Fragen allein, ahnungslos gestorben im Schützengraben. Zivilisatorisch ist das ein Offenbarungseid. Bin ich ein totaler Anti-Militarist? Ich glaube nicht. Ich habe nichts gegen die Idee privaten Waffenbesitzes. Ich kann der Idee der Landesverteidigung durchaus etwas abgewinnen. Den Wehrdienst habe ich bewusst nicht verweigert. Ich wollte die Erfahrung machen. Hier schreibt also auch ein Obergefreiter a. D. eines bayerischen Gebirgspionierbataillons bei Rosenheim mit bronzener Schützenschnur, der am MG durchaus treffsicher war. Aber eben auch jemand, den der Wehrdienst zum Teil-Pazifisten gemacht hat. Mir war nach dem Grundwehrdienst klar: Wir sind eine Gurkentruppe, reines Kanonenfutter. 20-jährige Grünschnäbel mit zu viel Testosteron und Hollywood in den Gliedern, aber wenig Ahnung. Ich war also einer, der sich verlässlich mit anderen beim Orientierungslauf im Wald verirrte; einer, der mit anderen übermüdet beim ersten Wachdienst einpennte (und damit im Ernstfall den Tod im Schlaf kennengelernt hätte, denn just erfolgte ein simulierter „Angriff“); einer, der auch mal übernächtigt sein Gewehr vor dem Zelt vergaß (wir sollten dem G3 den Namen unserer damaligen Freundin geben – wie pervers – ich vergaß also „Petra“ vor dem Zelt) und schließlich einer, der die meiste Zeit des Dienstes fürs Vaterland letztlich mit dem Servieren von Getränken und Schinkennudeln im Offizierskasino verbrachte und die institutionalisierten Alkoholiker der Bundeswehr bei Laune hielt („it ain’t much, but it was honest work“). Anders gesagt: Krieg – spätestens seitdem: ohne mich. Auch wenn ich gerne Ernst Jünger lese und zitiere (er war einfach ein großartiger Chronist und lebendiger Geist), seinen abenteuerlustigen Militarismus kreide ich ihm an und rufe ihm posthum hinterher: man muss nicht erst einen Sohn im Krieg verloren haben, um zum Pazifisten zu werden. Weitere Störgefühle tauchten auf: In meiner Dissertation durfte ich mich u.a. mit philosophischen Theorien zum Gesellschaftsvertrag (u.a. Kant, Rousseau, Locke und Hobbes sind hier zu nennen) beschäftigen. Dies brachte mein Staatsverständnis gerade bei der Kriegsfrage noch mehr durcheinander. Wenn Mindestziel der Staatsgründung innere und äußere Sicherheit sind, aber letztlich nicht der Staat den Bürger, sondern der Bürger den Staat schützt, wozu sich dann eine Schutzmacht erfinden, die einen am Ende durch den Fleischwolf jagt? Hobbes setzte zumindest auf Söldner. Kriege werden mit Lügen begonnen, wusste Julian Assange. Können Sie mit Wahrheit beendet oder gar verhindert werden? Seit [Walter Lippmanns „Liberty and the News“](https://archive.org/details/oapen-20.500.12657-45896/page/n5/mode/2up) von 1920 weiß man spätestens, dass gesicherte Information im Krieg das seltenste Gut ist. Sagt Lippmann als oberster Mainstream-Journalist und Einflüsterer der Mächtigen. Jeder Journalist muss hier ein Störgefühl entwickeln, der Leser noch mehr. Der Journalist der Nachrichtenagentur ist selten im Geschehen sondern wird vom heimischen Militär gebrieft, sein Bericht landet dann in den Newstickern und Redaktionen. Die Kriegsmaschinerie produziert also auch ihre eigene Sicht auf die Dinge, die sie den Bürgern als die Realität verkauft. Kein Wunder, dass jede abweichende Information massiv bekämpft werden muss. Im Krieg ist Zweifel gleich Verrat, quasi unsolidarisches Sektierertum und Wehrkraftzersetzung, wenn nicht Feindbegünstigung. Der kritische Journalist steht in Ausnahmezuständen, wie man schon bei Corona sehen konnte, automatisch aus Staatssicht im Lager des Feindes und wird entsprechend behandelt. Zensursicheres Publizieren ist dann nicht nur ein nettes feature, sondern notwendige Basisvoraussetzung. Vor kurzem war Twitter/X nicht mehr zugänglich wegen massiven Cyberattacken. Wenn dann noch Rundfunk und Presse auf der Propagandawelle surfen und die Plattformzensur wieder zuschlägt, wird das Angebot schnell dünn. Wem aber dient Zensur und Propaganda? Die aktuelle Lage im Russland-Ukraine-Konflikt ist auch Gelegenheit, um zu zeigen: Es sind eben nicht nur staatliche Interessen, die hier verhandelt werden, sondern es muss (wieder mal) eine andere Entität mit am Tisch sitzen, man nenne sie Deep State oder wie auch immer. Europäische Eliten dienen offensichtlich Fremdinteressen, wenn sie mit Aufrüstungsplänen Volksvermögen verspekulieren oder darin (wie von der Leyen) ein notwendiges „Investment“ sehen. Von wem werden wir letztlich regiert? Auch diesem Themen-Komplex werde ich mich in der Friedenstaube nähern. Es gibt viel zu tun, aber für mich ist klar: Frieden ist ohne Wahrheit nicht zu bekommen, deshalb ist Wahrheitssuche auch immer Friedenssuche, wie Wahrheitsliebe letztlich Friedensliebe ist. Gerade fallen auch im Mainstream die Corona-Lügen zur Labortheorie in sich zusammen, fünf Jahre nach Ausrufung der Pandemie. Der Frieden hat nur eine Chance, wenn es uns gelingt, die Lügen nun möglichst synchron zu den Geschehnissen aufzudecken und zu dokumentieren. Das ist mein persönlicher Wunsch, mit dem ich die Friedenstaube fliegen lasse. Was ist Ihrer? Schreiben Sie es gerne in die Kommentare. Welche Erwartungen, Wünsche haben Sie an uns? Liebe Autoren: Was ist euer Beweggrund, für den Frieden zur Feder zu greifen? *** ***Zeichnen Sie jetzt “Friedensanleihen”.*** *Werden Sie Genossenschafter und Verleger der Friedenstaube ab 1000 Euro/CHF. Es können mehrere Anteile pro Person gezeichnet werden, es bleibt bei einem Stimmrecht pro Kopf.* ***milosz\@pareto.space*** *** **P.S: Mit diesem Text testen wir die Newsletterfunktion erstmals an mehrere Hundert Mailadressen. Wenn Sie die Friedenstaube abonniert haben, sollten Sie diesen Artikel per Mail bekommen haben.**&#x20; ANZEIGE: **Sie suchen nach dem einfachsten Weg, Bitcoin zu kaufen und selbst zu verwahren?******** *Die* ***[Relai-App](https://relai.app/de/?af_xp=custom\&source_caller=ui\&pid=INFLUENCER\&is_retargeting=true\&af_click_lookback=7d\&shortlink=eo5zpzew\&af_channel=branded_url\&af_inactivity_window=30d\&c=Milosz%20Matuszek)*** *ist Europas erfolgreichste Bitcoin-App.* ***[Hier](https://relai.app/de/?af_xp=custom\&source_caller=ui\&pid=INFLUENCER\&is_retargeting=true\&af_click_lookback=7d\&shortlink=eo5zpzew\&af_channel=branded_url\&af_inactivity_window=30d\&c=Milosz%20Matuszek)*** *kaufen Sie Bitcoin in wenigen Schritten und können auch Sparpläne einrichten. Niemand hat Zugriff auf Ihre Bitcoin, außer Sie selbst.* ***Relai senkt jetzt die Gebühr auf 1%**, mit dem Referral-Code* ***MILOSZ*** *sparen Sie weitere 10%. (keine Finanzberatung). Disclaimer wg. EU-Mica-Regulierung: Die Dienste von Relai werden ausschließlich für Einwohner der Schweiz und Italiens empfohlen.* *** ***Join the marketplace of ideas!** We are building a publishing ecosystem on Nostr for citizen-journalism, starting with a client for blogging and newsletter distribution. Sound money and sound information should finally be in the hands of the people, right? Want to learn more about the [Pareto Project](https://pareto.space/en)? Zap me, if you want to contribute (all Zaps go to the project).* *Are you a publication or journalist and want to be part of it, test us, migrate your content to Nostr? Write to **<team@pareto.space>*** **Not yet on** **[Nostr](https://nostr.com/)** **and want the full experience?** Easy onboarding via **[Start.](https://start.njump.me/)** Pareto has started a crowdfunding campaign on **[Geyser.](https://geyser.fund/project/pareto?hero=geyser)** **We were in the Top 3 in February, thank you for the support!**

@ 3eba5ef4:751f23ae

The CKB blockchain is taking a significant leap forward with the introduction of the `Spawn` syscall in its [upcoming Meepo hardfork.](https://docs.nervos.org/docs/history-and-hard-forks/ckb-hard-fork-history) Think of Spawn as a bridge that enables different CKB Scripts to talk to each other securely and efficiently—much like how programs communicate in modern operating systems. However, building Spawn from scratch represents a significant development effort, which is why we’ve developed `ckb-script-ipc` libraries to simplify this process. Together, `Spawn` and the `ckb-script-ipc` library transform how on-chain scripts communicate and share functionality, offering developers a streamlined solution for creating modular and reusable on-chain applications. In this deep dive, we’ll explore: * How the new `Spawn` syscall overcomes the limitations of existing code reuse methods * The `ckb-script-ipc` library and how it simplifies complex IPC (Inter-Process Communication) implementations * Practical examples of building client-server communication between scripts * The technical details of the wire format protocol that makes it all possible * Future possibilities, including developments in bridging on-chain scripts with native machine code Whether you’re a blockchain developer looking to leverage these new capabilities or a technical enthusiast interested in understanding CKB’s evolution, this guide will provide you with both the conceptual framework and practical knowledge needed to work with CKB’s new IPC features. Let’s dive in and explore how these new tools can transform the way we build on CKB. ## Why Spawn The upcoming [CKB hardfork Meepo](https://docs.nervos.org/docs/history-and-hard-forks/ckb-hard-fork-history) introduces a new syscall called `Spawn`. This feature draws inspiration from the Unix/Linux operating system, functioning similarly to a combined `fork` and `exec` operation. Along with `Spawn`, related syscalls such as `pipe`, `read`, and `write` are also implemented, following Unix/Linux conventions. For detailed specifications, refer to the [RFC documentation](https://github.com/nervosnetwork/rfcs/blob/master/rfcs/0050-vm-syscalls-3/0050-vm-syscalls-3.md#spawn). ### Overcoming Previous Challenges with Spawn Prior to `Spawn`, CKB supported three primary methods for code reuse: * Static linking * Dynamic linking * [`exec`](https://github.com/nervosnetwork/rfcs/blob/master/rfcs/0034-vm-syscalls-2/0034-vm-syscalls-2.md#exec) Each of these methods has distinct limitations. Static linking, while straightforward, only enables code reuse at the source code level, making binary-level reuse impossible. Both dynamic linking and `exec` offer binary-level reuse but come with significant drawbacks. Dynamic linking faces several challenges: * Security Vulnerabilities: Called functions can access and modify the caller’s memory space, creating potential security risks * Resource Constraints: The shared memory space architecture can lead to memory resource limitations * Language Restrictions: Current implementation primarily supports C, with incomplete support for other languages like Rust The `exec` syscall also has notable limitations: * Context Loss: Execution resets the current context information, making state preservation impossible * Communication Barriers: No built-in mechanism for inter-process communication The new `Spawn` syscall addresses these limitations, offering a more robust and flexible solution for code reuse in CKB by: * **Providing isolated memory spaces** to improve security * **Preserving context information** to enable state preservation * **Enabling inter-process communication** while **maintaining security boundaries** ### IPC vs RPC In computer science, Inter-Process Communication (IPC) refers to the mechanisms that allow processes to share data and communicate with each other within a computer system. With the introduction of `Spawn` syscalls in CKB, we can now implement IPC functionality in CKB scripts. You might wonder why we refer to this as IPC rather than RPC (Remote Procedure Call). The key distinction lies in the execution context: * **IPC**: The script processes, where the code is executed, are part of a single transaction, all running locally on the same machine. * **RPC**: RPC systems are designed for distributed computing and include sophisticated features, such as encryption and authentication, comprehensive error handling and propagation, retry mechanisms and timeout management, horizontal scaling capabilities, and network transport protocols. Our implementation focuses specifically on the core IPC features needed for efficient process-to-process communication within CKB’s transaction context. This targeted approach keeps the system lightweight and appropriate for its use case. ### Challenges of Developing with Spawn Implementing IPC using `Spawn` requires a series of steps. Here’s a comprehensive overview of what developers need to consider: 1. Interface Definition: Design and define the service interfaces and methods that will be exposed. 2. Channel Establishment: Create communication channels between processes using pipes. 3. Parameter Serialization: Encode method parameters into a standardized format. 4. Wire Format Conversion: Transform the serialized parameters into a binary blob suitable for transmission. 5. Data Transmission: Send the encoded data blob to the target process. 6. Data Reception and Parsing: Receive and decode the transmitted data blob. 7. Method Dispatch: Route the decoded request to the appropriate function handler. 8. Response Handling: Encode the return values into a transmissible format. 9. Response Transmission: Send the encoded response back to the calling process. It’s important to note that implementing a robust IPC system requires additional consideration for error handling and exception management. Building such a system from scratch represents a significant development effort, which is why we’ve developed libraries to simplify this process. ## A Simplified IPC Solution: `ckb-script-ipc` To streamline the implementation of IPC from scratch, we’ve developed [ckb-script-ipc](https://github.com/XuJiandong/ckb-script-ipc), a library that significantly simplifies the process. Inspired by Google’s [tarpc](https://github.com/google/tarpc), this library provides a straightforward, easy-to-use interface for IPC implementation. It abstracts away the complexities of serialization, message passing, and error management internally. Developers can focus on defining their service interfaces and implementing business logic rather than dealing with low-level IPC details. Let’s walk through the implementation process step by step. **Step 1 Add required dependencies** Add the required dependencies to your `Cargo.toml` ```toml ckb-script-ipc = { version = "..." } ckb-script-ipc-common = { version = "..." } serde = { version = "...", default-features = false, features = ["derive"] } ``` Remember to replace `“…”` with the latest available versions of these crates. **Step 2 Define the IPC interface** Define the IPC interface using a trait decorated with our service attribute: ```rust #[ckb_script_ipc::service] pub trait World { fn hello(name: String) -> Result<String, u64>; } ``` This trait should be placed in a shared library accessible to both client and server scripts. The `#[ckb_script_ipc::service]` attribute macro automatically generates the necessary implementations for IPC communication. **Step 3 Initialize the server** Initialize the server by creating communication pipes: ```rust use ckb_script_ipc_common::spawn::spawn_server; let (read_pipe, write_pipe) = spawn_server( 0, Source::CellDep, &[CString::new("demo").unwrap().as_ref()], )?; ``` **Step 4 Implement the service logic and start the server** ```rust use crate::def::World; use ckb_script_ipc_common::spawn::run_server; struct WorldServer; impl World for WorldServer { fn hello(&mut self, name: String) -> Result<String, u64> { if name == "error" { Err(1) } else { Ok(format!("hello, {}", name)) } } } run_server(WorldServer.server()).map_err(|_| Error::ServerError) ``` Note that `run_server` operates as an infinite loop to handle incoming requests. The `server()` method is automatically implemented by our proc-macro. **Step 5 Set up and interact with the client** ```rust use crate::def::WorldClient; let mut client = WorldClient::new(read_pipe, write_pipe); let ret = client.hello("world".into()).unwrap(); ``` The client uses the pipe handles obtained during server initialization to communicate with the server. For a complete working example, you can explore our [ckb-script-ipc-demo](https://github.com/XuJiandong/ckb-script-ipc/tree/main/contracts/ckb-script-ipc-demo) repository. ## Key Components: Procedural Macros and Wire Format ### Procedural Macros The implementation of client-server communication in `ckb-script-ipc` heavily relies on Rust’s procedural macros to eliminate boilerplate code. The `#[ckb_script_ipc::service]` attribute macro is particularly powerful, automatically generating the necessary code for client, server, and communication handling. Let’s examine how this macro transforms a simple service definition into production-ready code: First, define your service interface: ```rust #[ckb_script_ipc::service] pub trait World { fn hello(name: String) -> Result<String, u64>; } ``` The macro then generates the required implementation code, including client-side methods, request and response types, and communication handling. Here’s a simplified version of the generated client code: ```rust impl<R, W> WorldClient<R, W> where R: ckb_script_ipc_common::io::Read, W: ckb_script_ipc_common::io::Write, { pub fn hello(&mut self, name: String) -> Result<String, u64> { let request = WorldRequest::Hello { name }; let resp: Result<_, ckb_script_ipc_common::error::IpcError> = self .channel .call::<_, WorldResponse>("World.hello", request); match resp { Ok(WorldResponse::Hello(ret)) => ret, Err(e) => { // Error handling code } } } } ``` Here is a simplified version of generated server code: ```rust impl<S> ckb_script_ipc_common::ipc::Serve for ServeWorld<S> where S: World, { type Req = WorldRequest; type Resp = WorldResponse; fn serve( &mut self, req: WorldRequest, ) -> ::core::result::Result< WorldResponse, ckb_script_ipc_common::error::IpcError, > { match req { WorldRequest::Hello { name } => { let ret = self.service.hello(name); Ok(WorldResponse::Hello(ret)) } } } } ``` The generated code handles several aspects: * Type-safe request and response structures * Proper error handling and propagation * Serialization and deserialization of parameters * Method routing and dispatch This automatic code generation significantly reduces development time and potential errors while ensuring consistent implementation patterns across different services. ### Wire Format Another key component of `ckb-script-ipc` is its wire format, which defines how data is transmitted between processes. While the `spawn` syscall provides basic `read`/`write` stream operations, we needed a more structured approach to handle complex inter-process communications. This led us to implement a packet-based protocol. We use [Variable-length quantity (VLQ)](https://en.wikipedia.org/wiki/Variable-length_quantity) to define the length information in the packet header. Compared to fixed-length representations, VLQ is more compact and suitable for this scenario. Packets are divided into the following two categories: Request and Response. The `Request` contains the following fields without any format. That is, all fields are directly arranged without any additional header. Therefore, in the shortest case, version + method id + length only occupies 3 bytes. The complete structure includes: * version (VLQ) * method id (VLQ) * length (VLQ) * payload (variable length data) The `Response` contains the following fields: * version (VLQ) * error code (VLQ) * length (VLQ) * payload (variable length data) Let’s examine each field in detail:  All numeric fields (version, length, method\_id, error\_code) use VLQ encoding for efficient space utilization while supporting values up to 2^64. This provides a good balance between compact representation for common small values while maintaining support for larger values when needed. For serialization and deserialization, we utilize `serde_json` as our primary library. This means any Rust structure that implements the `Serialize` and `Deserialize` traits (which can be automatically derived using the `#[derive(Serialize, Deserialize)]` attribute macro) can be seamlessly used as parameters and return values in your IPC communications. This provides great flexibility in the types of data you can transmit between processes while maintaining type safety. JSON is not the only option—any Serde framework that supports the `Serialize` and `Deserialize` traits can be used. ## Potentiality Beyond On-Chain Communication While the primary focus of `ckb-script-ipc` has been facilitating communication between on-chain scripts, its potential extends beyond that. One exciting development direction is bridging the gap between on-chain scripts and native off-chain machine code, enabling off-chain services to interact with on-chain functionality. Let’s explore how this works. To interact with on-chain services from native code, follow these steps: **Step 1. Enable the** `std` **feature in** `ckb-script-ipc-common` **Step 2. Initialize the server:** ```rust let script_binary = std::fs::read("path/to/on-chain-script-binary").unwrap();let (read_pipe, write_pipe) = ckb_script_ipc_common::native::spawn_server(&script_binary, &[]).unwrap(); ``` **Step 3. Create and interact with the client:** ```rust let mut client = UnitTestsClient::new(read_pipe, write_pipe);client.test_primitive_types(1, 2, 3, 4, 5, 6, 7, 8, 9, 10, true); ``` These operations are executed on the native machine (off-chain), providing a bridge between off-chain applications and on-chain scripts. The current implementation has two main limitations: 1. **Transaction Context**: The CKB-VM machine running in this mode cannot access transaction context data, as this information isn’t currently provided to the VM. 2. **Integration Complexity**: Integration with off-chain projects requires manual setup since the functionality is provided as a library rather than a complete solution. We have a plans to enhance this functionality with two key features: 1. **Native Node Integration**: We’ll integrate the functionality directly into CKB nodes as an HTTP service, providing a “batteries included” solution that’s ready to use out of the box. 2. **Context-Aware Execution**: Future updates will enable access to transaction context data, allowing for more sophisticated interactions between off-chain and on-chain components. These improvements will significantly expand the utility of `ckb-script-ipc`, making it a more powerful tool for bridging across on-chain and off-chain systems. ## Final remarks The introduction of `Spawn` and `ckb-script-ipc` marks a significant advancement in CKB’s script development capabilities. By providing robust IPC functionality and simplifying complex implementation details, these tools enable developers to build more sophisticated and modular on-chain applications. We encourage developers to explore these new capabilities and contribute to the growing ecosystem of CKB applications. --- *✍🏻 Written by Jiandong Xu* *His previous posts include:* * [Enable Bitcoin Taproot on CKB (Part I)](https://blog.cryptape.com/enable-bitcoin-taproot-on-ckb-part-i) * [Enable Bitcoin Taproot on CKB (Part II)](https://blog.cryptape.com/enable-bitcoin-taproot-on-ckb-part-ii) * [Omnilock, a Universal Lock that Powers Interoperability](https://blog.cryptape.com/omnilock-a-universal-lock-that-powers-interoperability-1)