The Cyberspace Meta-Protocol: An Extension of Reality

arkinox

Hello all,

I'd like to announce some big changes to ONOSENDAI. I'm sharing it publicly here for the first time.

ONOSENDAI has successfully proven that you can effectively visualize the nostr protocol into a 3D space. This was the first step in opening the door to cyberspace.

I have been designing the cyberspace meta-protocol (a protocol on top of the nostr protocol) and am ready to reveal it.

The goal of the cyberspace meta-protocol is to create an extension of reality in digital space. This is accomplished by combining the properties of the permissionless nostr protocol and proof-of-work.

In reality, we are able to do anything that we have the thermodynamic energy to do (this doesn't mean that all actions are acceptable or legal, but you can still do them). You can expend energy to move, communicate, build, etc. without any permission and the only way someone can stop you is by spending energy to oppose you. Reality is a permissionless thermodynamic protocol.

This is what makes doing these things in real life different from doing them in a video game.

A video game is not permissionless. You need permission to do actions in a video game. Furthermore, the video game has no thermodynamic constraints on the virtual actions you can take. The actions you take are abstract, and governed by an abstract set of rules enforced by a centralized controller, which is subject to bias and can be tricked with clever actions (hacked). Abstract actions you take in a video game have little value or impact on reality (aside from how people feel about those actions.)

This is why I have decided that all actions in cyberspace will be constrained by thermodynamics via proof-of-work.

A permissionless virtual action with a thermodynamic cost is effectively as real as any action in the real world, except the consequences of the action happen in cyberspace rather than physical space. All actions in cyberspace will have a thermodynamic cost, and therefore cyberspace will be an extension of reality itself.

Here are the initial actions I have defined for cyberspace. All actions require the publishing of an event with at least 1 unit of NIP-13 proof-of-work (PoW) except for constructs which use a special kind of proof-of-work.

Cyberspace Meta-Protocol

Building

Constructs. A construct is a zappable portion of cyberspace that you own. You obtain a construct by publishing a kind 33333 "Construct" event. The 256-bit event ID is used to determine the coordinates of your construct. The first 85 bits is the X coordinate. The second 85 bits is the Y coordinate. The third 85 bits is the Z coordinate. The last bit (the least significant bit) is ignored.

You can mine this event ID to get the desired coordinates with a nonce and a target coordinate in the form of a 256-bit hex string (although the lsb is ignored). Unlike NIP-13 PoW, there is no invalidation for this coordinate proof-of-work. You simply hash until you get "close enough" to your target coordinate for your own satisfaction.

The construct's valid PoW determines its bounding box size. This is calculated by taking 255 minus the Hamming distance between the event ID and the target coordinate.

Shards. Once you've gotten your construct published, you will be able to put 3D objects into it. I am still working on the spec for the 3D format, but you will be able to publish a kind 33334 "Shard" event and set the e tag to reference your construct. The coordinates of the Shard will be relative to the construct's origin; Shards outside of the bounding box will simply be invisible. Shards will require proof-of-work but I am still working on the mechanics. Shards will be zappable and may represent purchasable goods or services.

Overwriting

If someone else publishes a construct that overlaps with yours, only the construct with the most proof-of-work will be visible. Therefore, it is in your best interest to continually hash higher proof-of-work versions of your constructs and be ready to publish them should your real estate ever be overwritten.

In this way, nobody can lay claim to a space forever, all space is scarce, and all space is tied to real-world costs.

Operators

Operators are a zappable presence in cyberspace controlled by a human or AI agent in reality.

The home coordinate is the spawning location for an operator. It is first derived from the simhash of the operator's NIP-05 identity, such as adam@jensen.dx. This means there will be clusters of operators belonging to the same NIP-05 identity server such as nostrplebs.com, and in turn high-traffic/high-value real-estate for constructs near these clusters.

If the operator does not have a NIP-05 identity, their home coordinate will default to a coordinate derived from their pubkey (85 bits for x, y, then z, discarding the least significant bit).

Movement

To move your operator in cyberspace, you must publish a kind 333 "Drift" PoW event and specify your current coordinates, your direction, and your previous 333 event (if it exists) in the e tag.

The amount of valid PoW in the event is your acceleration you gain from your current coordinate in the direction specified.
Since all Drift events must reference a previous Drift event, this forms a continuous movement chain that can be independently verified.
There will be a standard equation governing movement physics such that your Drift values can be tested and verified/rejected by any observer.

If you publish invalid values or break your movement chain (which indicates foul play) then the tip of your previous movement chain will be vulnerable to other operator's actions just like the tip of your current movement chain. This effectively leaves a "copy" of yourself stuck at a location that others can exploit.

Aggression

Derezz. To keep operators honest in their movement chains and to allow the thermodynamic resolution of disputes, aggressive actions are enabled by proof-of-work.

An attacker may attempt to Derezz a victim by publishing a kind 86 "Derezz" PoW event and specify the victim's pubkey (only 1 allowed), an e tag to the tip of your movement chain, and an e tag to the tip of any of their movement chains; this is where a broken movement chain is vulnerable to attack. The valid PoW is the range and power of the attack. If the PoW is 10 and the victim is 7 units away from the attacker, they receive 3 units of Derezz; 1 Derezz is enough to successfully teleport the victim back to their home coordinate and nullify all of their PoW action events (excluding constructs and shards).

The movement chain references in the Derezz event tags allow anyone to independently verify whether the attack was successful or not.

Armor. An operator may publish a kind 10087 "Armor" PoW event. The valid PoW in this event is subtracted from any incoming Derezz as a defensive measure.

Defenders against Derezz have an asymmetric advantage because they can generate Armor PoW any time before they encounter an attacker, whereas the attacker must generate enough Derezz to overcome their victim's Armor in a very short period of time. Therefore, an additional aggressive action is available to balance out this defender's advantage...

Vortex. A Vortex exerts a constant gravitational force that pulls a victim toward it while the attacker can generate higher PoW for a Derezz, as an example. An attacker may publish a kind 88 "Vortex" PoW event and specify the victim's pubkey (only 1 allowed) and e tag the respective movement chains. The content of the event should specify the coordinates where the Vortex should appear; if omitted it should appear at the victim's location. If the Vortex's PoW is 10 and the victim is 7 units away from it, 3 units of acceleration are applied to pull the victim toward the center.

Defense

Bubble. Securing one's property is a human right, and so it is necessary to provide tools for operators to defend their cyber property. Bubble is an event kind 90 that represents the creation of a constant anti-gravitational force that pushes an aggressor away from it. It functions as the exact opposite to a Vortex. The range and force of repulsion is constant regardless of the aggressor's distance from the origin.

Stealth. The state of the nostr network does not reflect whether an operator is actively controlling their Presence or not. Your latest Drift event determines where you are located. If you close your cyberspace client, other operators will still see you in that location and you are still vulnerable to attack. Therefore, it is important to be able to conceal one's location so that when the human controller is not present the operator is less vulnerable.

Stealth is an event kind 10085 that simply publishes proof-of-work to define a stealth boundary. Each unit of proof-of-work results in a stealth radius = 4096 / (POW+1). A smaller stealth radius is better. 4096 is the length of 1 sector.

When an operator has published a valid Stealth event, they may publish their Drift events differently without breaking their movement chain. Instead of publishing their coordinates directly in the Drift event, they may publish a zk-snark that will only reveal their coordinates if the input to the zk-snark is a coordinate within the boundary radius. This is called a Stealth Drift event.

Someone hunting this stealth operator may see their Stealth Drift events and input their own coordinates into the zk-snark. If they are not within the stealth boundary radius, they will simply receive a rejection. If they are within the stealth boundary radius, they will receive the actual coordinates of the operator.

Communication

Shout. You may publish an event of kind 20333 "Shout" (ephemeral) with PoW to broadcast a public message to nearby operators. The more proof-of-work the event has, the larger the broadcast radius. The event must reference in its e tag the tip of the Shouting operator's movement chain; this is the coordinate from which the Shout emanates. Operators will ignore Shouts whose radius they do not fall within.

The Shout may have an optional parameter to be broadcast as voice or text. Text shouts show up in a chat box on the interface, while voice Shouts will be heard via text-to-speech engines built into the web browser. This, of course, can be muted globally on the receiving operator's interface, which will force the speech to the text chat box.

ONOSENDAI will have optional speech-to-text via the web browser too so that a human controller can speak naturally to broadcast a Shout without typing.

Coming Soon

I haven't implemented all of the discussed features yet in ONOSENDAI but I'm working on it as fast as I can. I felt as though it was important to establish a strong conceptual basis for a proof-of-work-anchored digital world before I began implementing features.

I'd appreciate feedback and collaboration on this meta-protocol to refine and improve it and my cyberspace client implementation.

📜 If you found this article interesting, I have a longer more detailed version here: https://telegra.ph/Cyberspace-A-Real-Digital-Place-04-13

If you'd like to financially support development, please get in touch! I am looking for opportunities to pursue cyberspace development full-time.

Check out the cyberspace spec and contribute: https://github.com/arkin0x/cyberspace

Try out ONOSENDAI, the first cyberspace client at https://onosendai.tech

Github: https://github.com/arkin0x/ONOSENDAI

Telegram: https://t.me/ONOSENDAITECH