7 - Research and development perspective: proxifying proxied data (the meta level of Inner Envelopes) and the vision of interoperability of endpoints in communications

The program Tor (Dingledine et al. 2004) well-known for proxy chains has so far only provided the point-to-point respective of peer-to-peer forwarding of websites in the so-called onion routing: Every node can see what through it is forwarded.

A friend-to-friend network with encryption is safer: The Psiphone program enabled the establishment of a user, a friend, in a browser - before taken to further development and commercialization. This friend was able to surf the Internet with his browser via an encrypted connection through the friend's Psiphone instance with the IP-address of the friend (Deibert 2001).

From a proxy with a peer-to-peer respective point-to-point interface, a friend-to-friend architecture will be used here via an authorization concept, but without hiding the content of the accessed websites to the friend.

To define a dedicated friend out of a messenger as a proxy was as well here not possible so far, since it was a node installation - without a list of friends and there was no Inner Envelope that made it possible to encrypt end-to end.

Even the messenger system RetroShare, known for a friend-to-friend architecture, has no continuous end-to-end encryption. A packet is deciphered every time at every node by it. RetroShare is based on the Turtle Hopping protocol presented by Andre Tanenbaum et al. in which a chain of friends (instead of peers) each forward a packet, but also will unpack it, since only a point-to-point encryption is based on every hop (Retroshare 2023, Popescu, Crispo, Tanenbaum 2004).

So far, only the Steam Protocol of the Messenger Smoke has established continuous end-to-end encryption via different friends as well as peers and is therefore considered to be the most extensive new status of end-to-end encryption that can exchange its keys via the network (Smoke Documentation 2020, Moonlander 2020, Tenzer 2022).

End-to-End encrypted networks are the successor of peer-to-peer and friend-to-friend networks. The battle with the question if p2p or f2f is the better architecture for a network has been answered: it is an end-to-end encrypted network (which mostly encrypts a friend-to-friend network laying under it).

So, while the Steam-Protocol (end-to-end encryption via peers and friends) both, the protocol of the onion routing (point to point encryption via peers), also innovates the protocol of the turtle hopping (point-to-point encryption via friends), the protocol for Human Proxies goes one step further: it offers end-to-end encryption with deputies.

Another future perspective in this friend-to-friend continuously end-to-end encrypted chain can already be seen for further research and development: Human Proxies may be further enhanced.

For example, B may transform R'(M) into V(R'(M)) where V is B's proxy. A meta-level to the meta-level: A proxy through a proxy. Proxifying already proxied data describes the meta level of Inner Envelopes. There may exist Inner Inner Inner . Envelopes, all with the same message, but sent from different start-points.

As the Inner Envelope may add infinitely envelopes and each network knot may have an own Human Proxy not only the encryption multiplies, but also the possible amount of sender and route options gets in a high complexity.

This is reminiscent of the Matrjoschka dolls: these are wood-made and colorfully painted, interlockable Russian dolls with a talisman character: there is another wooden doll in every wooden doll and so on. By the way, according to the Guinness Book of Records, the world record is 51 dolls that were stacked together and was set up in the USA in 2003.

So, what happens currently if one chooses within Spot-On two proxies at the same time? Will both proxies send the same message R'(M)?

In a single instance of Spot-On, that's currently not possible: If A sends D a message and B is A's proxy while C is B's proxy, B remains the proxy.

Multiple proxies require P x Q messages. P = participants and Q = proxies. Now, it's just P messages. P x Q is noted in the TO-DO because it's a next step of programming that.

That means: it is a research and development perspective to append proxies, to make a chain of proxies, e.g. in the case if a proxy uses also a proxy.

In TOR, a message is encased with multiple shells. So, suppose a node visits mit.edu. There are N number of shells between the node and mit.edu. The site mit.edu knows of one of the nodes. That node knows there are N - 1 nodes. It's perhaps more complicated.

Already now it is getting clear, in Spot-On, the message isn't shelled like in TOR, known as the onion routing: Instead within the Echo Protocol with Human Proxies B does not know that the message is intended for C. Suppose that B also transfers the message to D (B's proxy). The connection (which can be indirect, direct, or both) between B and D may surmise that B and D are familiar.

In such a Spot-On, one proxy probably de-proxies a message and perhaps re-proxies it. The new message is new. The routes remain unknown - because of the Echo. There is nothing in the proxied and de-proxied message which defines the next node.

The assignment of responsibility alone becomes complex if the second proxy sends an Inner Envelope of a first proxy. Who is then responsible, the original sender, the Human Proxy or the proxy of the proxy?

Conversely, can the proxy be assessed, for example, in terms of legal responsibility than if it is the originator of a message?

Is the first Human Proxy for the second, his own Human Proxy to be evaluated as if it were the original sender?

After all, the (owner of a) proxy can not only say, "I am a deputy", and therefore be not responsible, but he can also tell that he has a power of attorney to act.

What if the owner of a Human Proxy says that he was the last in the chain of proxies? He would be the first original sender, so to speak? (e.g., to protect the actual original sender).

Thus, the first Humane Proxy can, for example, affirm a sent message, because he did not know it in encrypted form. But he can also negate that message just as well. What effects does it have on its own Human Proxy and what effects it has on the original creator of the message?

With a friends-list in a messenger network, everyone can now use any other friend as a proxy. Everyone could be a Human Proxy for the other.

However, the protection or camouflage function of a proxy becomes multiple respective infinite and receives a characterization as you know from the Matrjoschka dolls.

New in this sense of endlessly expandable Inner Envelopes is that with simple means of a friends-list in a messenger the starting points of a graph-chain are redefined.

Another perspective is to turn a Human Proxy into a Zero-Proxy: Imagine, I want to query the URL Database of Spot-On through my node and have it query other nodes and get those results without having to share links.

A Zero-Proxy could work like this:

Query the Zero-Proxy like https://public-server:8085 style. That listener just sends the request on the Echo and other systems process it or don't and return results. Keys? "Public-server:port" is an alias. Doesn't need privacy for such requests as they're public. Want private? Choose a Local Host of course: VPS:8085 is not secret but my-server connected to VPS on 4710 is.

Here you don't need SSH and keys and distributions. You can get data by requesting it. If one would implement it - it would be another implemented idea.

Then your browser gets an answer or multiple answers. You don't know and don't need to know which protocols are in-between or needed to aggregate the data. It's just another type of message. So, who asks, what are Human Proxies? This is another Human Proxy function: a Zero-Proxy.

Let´s think in terms of more generality: Can one do this?

This leads to a general approach of the Spot-On Encryption application: interoperability.

Spot-On introduced the concept of interoperability in communications: In Spot-On we find the vision of zero-specifics. This could be a model for all these other systems of communications too.

What's the goal for a communication app? To share a text message or to share a file like a picture? But where's the interoperability feature? Often None. Often Zero. What's that? Get a committee and agree on a protocol? All these lists and forums and zero push to get a bunch of people to create a protocol for everyone: Some want specifics because they think that creates security and features? It doesn't? Just imagine if TCP was non-interoperable. A City of Babel - that's what platforms and communication applications currently have created: self-contained systems with zero insight of anyone else. Self-censorship and that is loved. And sure, there is encryption, which also requires standardization: For some apps it's easier to copy and paste - in an already existing communication channel - encrypted messages converted by e.g., the Rosetta Encryption Pad, than to use any of these other encryption processes and applications.

Many of these applications: RetroShare, even Shareaza (because of the application and not the protocols), Signal, Telegram and also Tor - they're just open to themselves. No one can connect to these apps and share a file without this app installed.

Even E-Mail is tacky and broken by providers: Google closed...