-
Notifications
You must be signed in to change notification settings - Fork 6
Home
ASAP/Shark is routing protocol and developer framework to build most resilient and secure decentralized mobile applications.
ASAP is a P2P protocol for mobile devices and ad-hoc networks. ASAP/Shark is a developer framework for mobile decentralized applications.
It is far more lightweight as a blockchain but we can do similar things with it. We implemented a Public Key Infrastructure (PKI) and an E-Cash system with ASAP/Shark.
It is more resilient than Distributed Hash Tables (DHT) and similar approaches. ASAP is a routing protocol for them realm of mobile devices.
ASAP works fine without any infrastructure. It can work faster with Internet access but does not rely on it as nearly any other P2P system.
ASAP/Shark supports point-to-point and end-to-end-encryption and security levels which we consider to be close to paranoia. We like it. ASAP/Shark shares features with onion networks like TOR. We like that even more.
ASAP/Shark is a basis for application most people would call a P2P system. An IT system that works if peers are willing to exchange anything regardless of Internet access or not.
Most P2P systems do not work like this. They cannot work without Internet access. ASAP does. We call it resilience.
There is a video 25' video that tries to explain the core developers concept.
All P2P systems are about data. Their are two major classes of P2P system with very different goals.
DHT, Chord, Pastry, Kademlia are created to optimized network throughput. Huge data (like a video) are split into pieces and distributed over several peers instead of a single server. Application would reassemble this huge resource by its pieces. Network throughput if optimzed if pieces take different ways through the network. That is what those P2P system to: data allocation. Kademlia introduced even means to duplicate resources.
Blockchains are different. All peers need all information to produce a consensus, e.g. if financial transaction is valid. It is not about network throughput but consensus in a group of peers.
Both P2P system classes use IP network, most likely the Internet. That's an interesting fact since P2P is often associated with resilience. That is only partly true. A blockchain can work if a number of peers are offline. DHT would not. No blockchain based application would work without Internet access.
Internet was build to avoid a loss of communication after a large scale nuclear strike. Internet is a decentralized adaptive network. It is not about data or application logic. Internet can route data over a world-wide network. There is no such thing as an Internet application. There are applications using the Internet, like a lot of P2P systems.
The worldwide Internet can hardly be shut down. Internet access can get lost or can deliberately be restricted. A natural disaster can have same effect as a dictatorship: Limited or lost Internet connectivity. Applications need a way to access a router in Internet. There is no Internet access if that last mile is gone or restricted.
We all know at least since 2014 that Internet traffic is constantly and world-wide watched.
Human society is a different kind of P2P system. Humans meet, share their thoughts and information. Each encounter is a chance to communicate. Human interaction worked great without a centralized network over thousands of years and still works fine of no communication infrastructure is available. It works even better with Internet.
That is what we do. That is Shared Knowledge (Shark).
It is about data sharing between autonomous mobile peers with or without a network infrastructure. We use Internet but do not rely on it. That is resilence.
ASAP is a routing protocol on ISO/OSI layer 3. ASAP uses and requires a layer 2 protocol but differs fundamentaly from IP. ASAP is explicitly defined and implemented to work on unreliable, even short-time connections, especially ad-hoc networks.
ASAP supports large scale but loosely coupled mobile networks. It is assumed that devices establish a connection from time to time. It is not assumed that those connections are stable or can be re-established. ASAP apps run on mobile devices which cannot guide its bearer (probably a human) in any direction.
If you want to implement a mobile app for smartphones using e.g. Bluetooth, Wifi-direct - ASAP will most probably fit. IoT systems that harvest data from a bunch of sensors can be an efficient ASAP application.
ASAP supports address- but even more content based routing. IP routing is address based. Data packages are transmitted towards an address regardless of its content. Data are routed based on a semantic content description with content based routing networks.
ASAP is not an ad-hoc routing protocol like DSDV or DSR. Those protocols refuse routing whenever no connection between nodes exists in any given moment. ASAP is a store and forward protocol. It can run as pure gossip protocol. It is an asynchronous protocol.
ASAP has some small similarities to software agents. ASAP is not an agent language nor protocol. ASAP would be a suitable basis of an agent protocol for mobile decentralized ad-hoc networks, though.
ASAP has similar goals as JXTA. It focuses on decentralized communication but in mobile ad-hoc networks. ASAP is not an overlay network of an IP network. It has less requirements.
That is the basis of Shark: The Asynchronous Semantic Ad-hoc Protocol (ASAP).