Official Documentation¶
Contents:
Applications¶
Jeshka Desktop¶
Getting Started¶
Jeshka Desktop is an interactive experience for all resources available to us in the network. The application seeks to deliver a fresh perspective on life, no matter where you’re coming from.
The application is highly gamified, all aspects of life are abstracted to a decentralized and distributed digital consciousness. You can choose to encrypt your interactions.
The entry into the application creates a fictional situation where the user keeps forgetting that life used to be very different with an advanced version of Jeshka, but there was a terrible global disaster and almost all of Jeshka was removed from the knowledge of humanity. Now it’s on us, the population of the planet, to rebuild it. The participants only saved a piece of paper with their address and whistle from the disaster.
Release: December 1st, 2018
Control Center¶
We can skip to other plugins and apps from here. We can start, search or track Quests. We can change account and application preferences and settings.
Quest Machine¶
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 the best. If you can think of a better one, please let me know! ;-)
The Quest Machine is a Jeshka Desktop App feature that interactively allows peers to start Quests on the network. It’s the core functionality that all the other functionality on Jeshka seeks to support.
The Quest Machine covers the entire flow of dialogs for the creation and management of Quests. It includes the Quest Manager and the Quest Explorer to hunt after unresolving Quests.
Multi Wallet¶
This feature is an easy to use space that shows our full balances for all currencies that we have registered on Jeshka. Internally manages the resource type / contract group finc and emits audiovisual events on changes.
This feature is available on almost every screen of the App in some shape or form.
Jeshka Quest Explorer¶
Search and track Quests, check on their status, location, explore streams in certain channels, etc.
Text Channels¶
Decentralized IRC chat, we can import channel specific plugins. Domains can choose Roles for specific addresses and group their channels.
Internally manages the resource type text and emits audiovisual events on changes.
The main Jeshka Desktop App uses components to group user activity. This feature is available on almost every screen of the App.
Media Browser¶
For streaming and archived media objects, images, video, audio.
Consensus Module¶
Front End qManager
We can use the consensus plugin for a variety of Assembly activities. As a component, it is visible across the application.
Research Center¶
We can use Jeshka to power our research projects.
Jeshka Desktop Plugins¶
While the plugins and libraries might seem isolated, they all contact each other and exchange information within your system. So every part of the Jeshka application knows exactly what’s relevant for them.
Unlocking achievements of multiple achievements together can create meta combinations of achievements.
Sponsorships¶
Sponsor projects on the network with rewards you don’t need. Think decentralized crowdfund.
Distributed Git Explorer and Editor¶
Virtual Space¶
The virtual Reward Space allows most virtual interactions, for example streaming of oracles, unlocking achievements for particular resources, inter-human communication, etc.
Plugin enters with earth view of live network activity.
There are no old-timey prices on Jeshka, we have Rewards in our system the total amount of which is the equivalent to the total estimated energy that is needed to resolve all Quests on the network in a given timeframe. The rewards are calculated by assemblies and all relevant peers on the network, they keep changing.
Material Space¶
A multi-purpose open space for new and past physical objects (including grocery items) that as part of the specific Quest can also be physically delivered to us. Achievements of individual resources can be autonomously unlocked by the Quest Machine if needed for another Quest.
The nature of the Quests behind these interactions dictates that you can not set old-timey prices to individual goods, you can set a minimum conversation result, but the final exchange rate will be a consensus result with everyone who is offering the same resource under the same conditions and the relevant people who are interested in achieving/unlocking this resource!
Capabilities¶
An interactive explorer for our currently calculated individual capabilities, which leads to a portal to the Jeshka University module, where we can expand our capabilities while resolving Quests on the Quest Machine.
Combinations¶
An interactive explorer for combinations of the above, these are meta types and no actual resources, they’re for example being used for a Quest that would read “Get me from here to here in less than 20 minutes.”
JesHub¶
A simple platform for sharing of physical spaces. A JesHub domain keeps track of details about their location, their devices and such, also offers JesHub internal encrypted text message channels.
We get dialogs for Quests from others who are looking either to visit or stay at a JesHub or who need storage space, we can set our Jeshka domain to decide about matters in this domain on a detailed level or in full consensus with all peers in this domain.
Internally a JesHub is a resource.
Health¶
An interactive space for health related subjects. All features currently undisclosed.
Headless JDK Node¶
Currently only serves assembly functions. Contact the community if you are interested in this project.
Libraries¶
Jeshka JS Lib¶
Release Date: December 1st, 2018.
If you want to build an app for Jeshka, don’t think twice! We’re maintaining a JavaScript library that enables you to start a Quest in 5 easy steps. Just use:
jeshka = new JeshkaNode(); jeshka.startQManager(); jeshka.unlockWallet(seed Whistle); quest = new JeshkaQuest(); and put together your quest with easy setters and getters.
When you’re ready, let Jeshka whistle it jeshka.whistle(quest) for you, if you use this method, Jeshka will automatically sign and distribute the Quest. Jeshka is asynchronous, you can await jeshka.whistle(quest). You can also build a Quest that listens to a resource (stream) on the network!
Jeshka is non-profit and makes life hard for commercial enterprises. Jeshka is a non-profit organization; we’re currently in the process of registering Jeshka as a Foundation in the Netherlands. All parts of Jeshka are released under the AGPL v3.0 license, that means any service that uses Jeshka has to publish the relevant source code.
Devices¶
Jeshka Mesh Router¶
The Jeshka Mesh Router creates an access point to the Jeshka Quest Network, routes and resolves incoming Quests.
Build yourself or order from https://store.jeshka.io/jmr-1
Jeshka Smart Card¶
Use the Jeshka Smart Card to store your whistle(s).
Build yourself or order from https://store.jeshka.io/jsc-1
Jeshka Whistle Chip¶
Opt in for the fabulous Jeshka Whistle Chip to store your whistle(s).
Warning: Chip implants could cause infections or reactions in the body’s immune system.
Build yourself or order from https://store.jeshka.io/jw-1
Jeshka Animal Chip¶
Build yourself or order from https://store.jeshka.io/ja-1
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¶
