Protocol¶
This proposed solution makes use of peer to peer networking, cryptographic capabilities and machine learning technologies to create a feeless, trustless and fully decentralized ecosystem of services that enables optimal fragmentation and reuse of work performed by humans and machines across projects and departments. While providing a constantly optimized incentive for fair compensation, allowing for voluntarily unpaid participation and embedded learning experiences. The computer can be used as a tool to teach and reward people, rather than to exploit them.
Quest¶
Every piece of information that leaves our devices is wrapped up in something we call a Quest. This can be a simple text message, a financial transaction or references to an extremely complicated problem with many different moving parts that you are looking to get solved. Not just theoretical problems that is, we can even start Quests to build and furnish houses! Imagine a Quest like a box with a set of instructions and in some cases with many different (financial) rewards that whoever helps to resolve this Quest or parts of it will be able to remove from my box. Well, maybe this example is not that great. If you can think of a better one, please let me know! ;-)
A regular financial transaction on Jeshka, “bring this amount of this currency that I own to this other person” is always a Quest signed with a unique one time whistle and your unique and permanent address.
We call the entire existence of information that gets passed on to other peers in a single call a Quest Bundle.
Representatives should check if the quest will get resolved, i.e. if we have permission to listen on a certain channel, request a certain type of information or commit a certain transaction into a channel before routing our quest. It guards the other domains from spam traffic, requesting information that’s not available. If a representative doesn’t check and blindly forwards the request, the representative in the other domain might tell all the representatives on our domain that he is not doing his job and our representative might lose its representative role on the network.
The five-second rule.¶
If you start a Quest with a target that’s accessible within your economic cluster/domain, and a financial transaction or text message hasn’t resolved (is not confirmed) within 5 seconds*, we consider it failed or rejected. With a modern laptop, a Quest for a financial transaction usually resolves within 500–2500ms within a given domain/economic cluster.
* refers to the timeframe during which a Quest is considered hot. A Quest is considered hot, starting when it has reached the first peer we connect to. We expect simple Quests to resolve within a maximum of 5000ms from now. Once a Quest has resolved anywhere on the Quest Network it is considered resolved and the countdown stops. It may still take some time until we are informed that it was resolved.
If for some reason a Basic Quest keeps getting rejected because it exceeds the five seconds, please contact us, this is likely a bug.
Whistles¶
WhistleID¶
Our WhistleID is a collection of important data about us. It is connected to all the whistles we generate to sign Quests on network. While we interact on Jeshka, we collect signatures that prove our WhistleID is indeed ours. The most important piece of data in our WhistleID is our unique and human readable permanent address.
Our address inherently describes how we can be found if someone loses sight of us and helps to verify our unique one time whistle. Our addresses start with a list of all the parent domains down to our Home Domain from left to right.
Seed Whistle¶
Our signature scheme is inspired by the way dolphins identify each other. Whistles are the core for authentication and authorization on Jeshka. We all have different seed whistles that nobody else in this universe can ever forge. A seed whistle on Jeshka is a 174 character string of random letters A-Z and the number 9. We can derive everything we’ll ever need to participate in the network from this seed whistle. For instance, we sign Quests with quest specific private whistles that we derive from our original seed whistle. It is the first thing we do to prove to everyone in the universe that our signatures are authentic and that by consensus on the network the author of the Quest has to be the WhistleID connected to our permanent address, i.e. us. We can also derive whistles that help us decrypt messages and files. The seed whistle is in the same format as IOTA seeds, so the first 81 characters can just be my IOTA seed, etc, etc. Literally every key we’ll ever need can be derived from this seed whistle.
174 chars:
128 chars crypto seed 6 chars pin 28 chars my aes pass (for example to decrypt my ssl whistles for other domains that we gave to our individual home domains) 12 chars home whistle (to get ssl keys from home domain)
Private Whistle¶
Quests are signed with unique asymmetric one time private whistles that we derive from our seed whistle.
qWhistle¶
Quests contain a field to announce one upcoming unique asymmetric one time public quest whistle. It is the public counterpart of the private whistle that is used to sign a Quest/transaction.
It can be used to verify the authenticity and origin of an upcoming Quest.
If a Quest is signed with a whistle/key that hasn’t been announced in a qWhistle field before, it’s invalid.
In other words, the qWhistle field contains the public whistle (key) that has to be used to verify the next or another upcoming Quest in this specific channel or zone.
Home Whistle¶
A home whistle is used by members of a given domain to roughly identify the origin of an incoming connection, of course this home whistle can be intercepted and used by others, who will then be rejected by the server, because they can’t produce the right public whistles. It serves as a good first gateway mechanism, helps others to get a rough idea of who we are and can be changed per our request. For example if it has gotten compromised.
SSL Whistle¶
OTP to establish SSL connections.
Join Whistle¶
When connecting to a new flow, we tell our swarm that we are joining this new flow with a Join Quest. If anyone asks around in our swarm, our Join Whistle holds a public whistle as content that other flows are asking about. If unsuccessful the logical conclusion is that the public whistle in combination with the address does not exist, very likely that the particular Quest Bundle is a forgery.
Addresses¶
We all identify with a unique permanent address and a unique one time whistle that changes with every Quest. Our address describes how we can be found if someone loses sight of us and helps to verify our unique one time whistle. Our addresses start with a list of all the parent domains down to our Home Domain from left to right. For me this is:
jeshka://universe.vec1.sol1.earth.jeshka.collective.rainbow
and since we are all on the same planet here, most Jeshka apps allow a shorthand version and internally compute the full address, like so: jeshka.collective.rainbow or rainbow@jeshka.collective
This is my receiving address for all Quests directed at me. So people can send anything from encrypted text messages, financial transactions to terabytes of data to my address. It’s not to be mixed up with old-timey email addresses.
protocol part jeshka://
home domain part universe.vec1.sol1.earth.jeshka.collective
peer part .rainbow
To identify resources, for example in the cA field we see addresses that refer to resources more than individuals, let’s say we’re looking up the currency JESH, the full address would be jeshka://universe.vec1.sol1.earth.jeshka:jesh.
Whistleid addresses are relative in places like these, so if I want to look up my balance, I have to: jeshka://universe.vec1.sol1.earth.jeshka:jesh/collective.rainbow (/relative whistle id address)
If we want to look up all balances for JESH, we have to look up the peer map: jeshka://universe.vec1.sol1.earth.jeshka:jesh.p
If we want to look up a specific Quest in a specific channel, we have to look up: jeshka://universe.vec1.sol1.earth.jeshka:jesh::7382e3a8932eb (::qHash)
If we want to look up all Quests in a specific channel, we have to go through the Quest log: jeshka://universe.vec1.sol1.earth.jeshka:jesh.qlog
Domains¶
Domains can only be upper and lowercase characters. Minimum 5 Characters. 4 Characters reserved for network functionalities. Once a domain is registered on the network, it’s yours.
Domains can also keep track of their resources and respond to Quests automatically, manually or let Jeshka decide on a detailed level, i.e. we can request a collection of Jeshka domains to make certain decisions, we can choose our own software to come to individual certain decisions for resources in our domain or we can even manually handle all Quests ourselves.
Domain Peers¶
A peer in a given domain connects to their domain assembly.
Their domain assembly will relay all the information from the domain they represent through the JeshkaNet and the Internet.
When a peer connects to its domain representatives through the internet, they have to trust that behind the https address they find current representative
Consensus¶
Every domain can choose their own consensus strategies for different resources and change them over time.
Strong Consistency: Strong consistency means that the transactions in a given resource channel are only considered confirmed, once every representative confirmed them.
In centralized networks the central authority owns or controls all representatives.
Assemblies¶
How do peers on Jeshka reach consensus? While Jeshka allows us to establish blazing fast and highly secure peer to peer connections that can not be intercepted, a Quest is never resolved by just one person. We want to make sure the result is what we wanted, that our Quest hasn’t been altered and that nobody is trying to remove a reward from the box without having done their part correctly. Some people are better at some things than others and for some parts of our specific Quest, AI may be more suitable. If it doesn’t take the entire reward to resolve our Quest, we’re always happy to get some back and if the result exceeds all of our expectations, we’re free to tip the remainder to the people who did the best job on the entire Quest.
For all of that Jeshka uses Assemblies. The dictionary definition of an Assembly is “a group of people gathered together in one place for a common purpose.” and that’s just what an Assembly is on Jeshka. An Assembly is a very diverse group of participants, some who are proven to be very good at what they are doing, some have just started out and are resolving parts of our Quest as they are advancing on their learning curve. A Quest can be resolved by different Assemblies for different parts of it or if it involves moving objects across a large geographical distance, for different legs of the journey. An Assembly is a group of people, who are helping us assemble whatever our Quest is about on whichever network is the most suitable.
Every domain and resource has their own quorum strategy and is represented by a series of quorum decisions. The domain assemblies are usually elected from the pool of all peers in a given domain.
A domain representative has to keep records of all of the domain’s and it’s subdomains and peers resources.
The representatives can choose their own software to connect to the network as long as they follow the communication and encryption protocols.
Load Balancing¶
If we are not invited to open connection channels with the representatives in a domain, we are accessing the resources of, we can ask our domain representatives to relay the information for us. They will for example listen on all changes there and update us and all the others who are listening from them about a given resource. These representatives are usually the members of a dynamically formed Assembly for this purpose.
Connection Channels¶
Jeshka is available on the internet, to establish a trusted connection, the Jeshka node uses a list of sources (that we can edit) to achieve consensus over who is representative for what domain at the moment.
Initialization¶
We connect to all the representatives in our home domain, requesting our SSL Whistle keychain, using our peer address and the Home Whistle. The keychain is an aes encrypted JSON Object that holds all of our personal SSL Whistles for different domains. It’s on us to keep it updated.
Port 442
Keychain Access¶
If we have the fitting SSL Whistle, we can use it to establish a direct connection channel with either the representatives of a given domain we are trying to access or with the representatives from our home domain.
Distributed Gateways¶
If a given resource domain or domain is not available for us to connect to directly, we ask a dynamically formed assembly of peers to relay the information for us.
What we want these representatives to route to a different network, we call a Quest.
Network Plugins¶
Jeshka is network and consensus agnostic. We’re aiming to make use of IOTA’s capabilities. But really almost every network that meets our security and energy standards can be plugged into Jeshka and Quests as well as Resource Streams can leave the core networks and may get transported in ways we can’t even imagine right now. For example, a group of people in Cuba has recently resolved a Jeshka Quest only by using their own physical USB flash drive exchange network. Usually, the first Assembly or Assemblies that receive(s) your Quest decide(s) where and how to transport it from there.
Meta Conecpts¶
On a meta layer we can observe many concepts that are emerging from the network as it was theorized by the Jeshka Collective in the original Jeshka Whitepaper.
Proof-of-Reputation¶
Transactions - NN, EDAS & EDAM¶
