Lets redecentralize the web
TRUE P2P CONCEPT -This repo is just conceptual. Active development of the endproduct (TRUE P2P) happens here https://github.com/worldpeaceenginelabs/TRUE-P2P-MISHMESH
TRUE P2P CLIENT CONCEPT
This is a high level abstraction of a true-p2p client, which is basically your existing or next website/app and Mishmesh with all the listed adapters installed.
My definition of True P2P
"A swarm of P2P clients, independent of any dedicated servers, not even dedicated signaling servers" (but using everything available is allowed, like nanites would do)
or different said: "Todays systems are centralized instances, connecting peers. This will not change, but as soon as the swarm is online, centralized instances are becoming the fallback only. Thats the difference!"
"Kind of, in the past we used candles only. Today, we only use candles, when the light is off, to find the switch in the dark, to get the light back on. So candles are still neccessary, but we do not depend on them anymore." (candles are not even neccessary anymore, we have flashlights and bright mobile screens today, but we were only able to figure this technologies out, because we were not sticking to candles anymore)
Introduction
This is the sourcecode of True P2P in development. The endgoal is to connect peers through multiple protocols, no matter what. At the end, its just all about reconnecting.
The finish will be a set of modules in a priority list.
- direct connection via WebRTC
- if that doesnt work, reconnect via Bittorrent/Webtorrent
- if that doesnt work, reconnect via IPFS
- if that doesnt work, reconnect via Hypercore Protocol
- if that doesnt work, reconnect via Hyperswarm
- if that doesnt work, reconnect via AXE
- if that doesnt work, reconnect via updated lists of free stun and turn servers
- if that doesnt work, reconnect via DHT lists, saved everywhere its possible (websites, blogs, github, social media, forums, etc.), without stressing free tiers
- if that doesnt work, reconnect via DYNDNS
- if that doesnt work, reconnect via AD HOC (same LAN, same WIFI, Bluetooth, Direct Wifi, QR-Code)
- if that doesnt work, reconnect via Instant Message from a friend who uses the app too.
- if that doesnt work, reconnect via free hosted website with updated DHT list (last Fallback)
STATUS
For now its a plain https://github.com/dmotz/trystero clone, which works.
This repo is just conceptual. Active development of the endproduct (TRUE P2P) happens here https://github.com/worldpeaceenginelabs/TRUE-P2P-MISHMESH
Whats already working (all thanks to Trystero)
- Webtorrent/Bittorent
- IPFS
- WebRTC
- AD HOC(LAN, same WIFI)
- Use of a torrent as a beacon. Everybody who is interested in this torrent (people with your app), is potentially one of your users, so you connect to them. (done)
- Encryption. Only your app (with the right password) is able to connect. Data is end-to-end encrypted.
Suggested protocols/technologies
(used all together in combination to achieve True P2P)
done
- Webtorrent (done)
- Bittorrent (done)
- IPFS (done)
- WebRTC (done)
- AD HOC(LAN, same WIFI) (done)
- Use of a torrent as a beacon. Everybody who is interested in this torrent (people with your app), is potentially one of your users, so you connect to them. (done)
- Encryption. Only your app (with the right password) is able to connect. Data is end-to-end encrypted. (done)
coming
- Priority mechanism (priotizing strategy 1, then checking for reconnect via strategy 2-11)
- IP/entrypoint exchange strategies
- Torrent/entrypoint exchange strategies
- DHT/entrypoint exchange strategies
- Updated lists of free stun and turn servers
- free hosted website with updated DHT list (last Fallback)
- posting DHT lists everywhere its possible (websites, blogs, github, social media, forums, etc.), without stressing free tiers
- DYNDNS
- Hypercore Protocol
- Hyperswarm
- AXE
- GunDB
Options
- AD HOC wireless connecting clients (Bluetooth, Wifi-Direct) see https://berty.tech/blog/bluetooth-low-energy/
- AD HOC via Instant Messaging
- AD HOC via QR Code
- volunteers adding nodes for fallback support (for instance downloadable exe with autostart option)
- business model in which users add storage and get crypto in return (like Filecoin/BTT)
- an integrated p2p github for the client (in case of a client/the swarm got hacked/corrupted, it can restore itself from the last confirmed version)
- p2p code collaboration (no central instance anymore, for improving the code of true-p2p AND the app which uses the library)
Suggested repos/libraries
https://github.com/dmotz/trystero
TrysteroServerless WebRTC matchmaking for painless P2P — Make any site multiplayer in a few lines — Use BitTorrent, IPFS, or Firebase
https://github.com/vardius/peer-cdn
Peer-CDN (the PWA itself is cached between peers)Lightweight library providing peer to peer CDN functionality
https://github.com/chr15m/bugout
BugoutBack end web app services over WebRTC.
https://hypercore-protocol.org/
Hypercore (another connecting and streaming channel)Hypercore Protocol is a peer-to-peer data network built on the Hypercore logs. Hypercores are signed, append-only logs. They're like lightweight blockchains without the consensus algorithm. As with BitTorrent, as more people "seed" a dataset it will increase the available bandwidth.
https://github.com/RangerMauve/hyperswarm-web)
Hyperswarm (A distributed networking stack for connecting peers.
https://github.com/amark/gun
Gun (P2P auth, graph, etc.)GUN is an ecosystem of modular tools. Graphs take you beyond just immutable hashes, they let you do realtime multiplayer updates on any type of data. SEA gives you the best local-first secure user accounts, but with normal logins and even p2p password resets using 3FA!
AXE(GunDB)
will let you deploy without clouds to a decentralized edge CDN for your JAMstack apps. It runs everywhere, even via browsers with WebRTC, using the simple yet powerful HAM "CRDT" conflict resolution algorithm. Meanwhile, DAM let's you do offline mesh networking and RAD stores your data.
Not sure if needed, but i list them...
https://github.com/subins2000/p2pt
P2PT (Signaling via Webtorrents)Simple WebRTC Peer 2 Peer connections using WebTorrent trackers as the signalling server. Use WebTorrent trackers for any kind of WebRTC app !
https://github.com/draeder/easypeers
EasypeersEasy serverless swarms of WebRTC peers over WebTorrent
https://github.com/draeder/tracker-swarm
Tracker-swarmA WebRTC tracker server swarm for P2P applications
https://github.com/draeder/webtorrent-beacon
Webtorrent-BeaconGet a beacon when a webtorrent containing your string gets a new peer
https://github.com/draeder/peerservers
Peer-serversConnect peers together no matter which server they join
https://github.com/feross/simple-peer
Simple-PeerSimple WebRTC video, voice, and data channels
https://github.com/webtorrent/webtorrent
WebtorrentStreaming torrent client for the web
DEFINITION OF A DAPP - What is a DAPP?
A dapp has its backend code running on a decentralized peer-to-peer network. Contrast this with an app where the backend code is running on centralized servers. A dapp can have frontend code and user interfaces written in any language (just like an app) that can make calls to its backend. Furthermore, its frontend can be hosted on decentralized storage such as IPFS.
- Decentralized means they are independent, and no one can control them as a group.
- Deterministic i.e., they perform the same function irrespective of the environment they are executed.
- Turing complete, which means given the required resources, the dapp can perform any action.
- Isolated, which means they are executed in a virtual environment known as Ethereum Virtual Machine so that if the smart contract happens to have a bug, it won’t hamper the normal functioning of the blockchain network.
Deployment
Simply store your Websites/Apps sourcecodes on Github. Github serves to Cloudflare's ultra fast CDN's. Lightspeed fast, the lowest vulnerabilities, easy to maintain, for zero cost.
Jamstack Rocks!!!
Back-end Deployment (classic API)
First Option: CockroachDB - Undestructible, self scaling, easy payment concept on demand and simple concept if you take a plan. Get 5GB a lifetime for free!
Second option: I recommend Digitalocean's STRAPI Basic Droplet: 2 CPU, 2 GB RAM, 2 Terabyte traffic included (est. 2 billion API requests) for 10$ a month. Another Terabyte comes for another cheap 10$. (est. 1 billion API requests)
If you need more power, there is a Linux VServer with insane 10 CPU, 48 GB RAM, 800 GB SSD, unlimited traffic for 20€ a month at Strato
From there, if you are growing bigger and bigger, your one and only task is "only" scaling your API server.
That's it. API scaling will become an monetary issue when your business is so already that big that you actually have the funds to solve this problem.
All the other stuff, thats usually connected with running an app or even a platform, is done. You can focus on design and code and nothing else. (...and API server scaling...) ;)
Back-end Deployment (P2P API)
Just by intregrating this repository in your website/app as soon its finished.
Hopefully just by typing "npm install true-p2p" 🙏🏼🙏🏼🙏🏼
Paving the way to True P2P
My goal is independent or minimum quasi independant P2P.
Which means, not dependant on one single network infrastructure, not my own, not a foreign one, but allowed to use every chance to connect as a fallback to reconnect. (in turn using different, already existing network infrastructures as needed. Because at the end of the day, we want the connection to the swarm, to update our DHT trackerlist/peertrackerlist/peerlist, to STAY connected)
MSC MEP concept (Multiple Strategy Concept, Multiple Entry Points)
Having multiple strategies
- jamstack decentralizes the centralized "very first entry" domain
- pwa gives it offline capabilities out of the box
- dht lists saved on free github page, blogs, forums (updated in an interval, automated via script on clients, sharing the updated dht to your page, a free blog for this purpose only, in a forum, etc., everything thats free and allowed, ergo not stresses out the free tier)
PLUS
using multiple entry points
- tracking/signaling (using multiple protocols for entry points) in a priority list with timeout limits (p2p first, then fallback options, worst the "very first entry" domain)
I imagine it happening like this (Cloud Atlas example)
This is the users client on the "very first entry" domain, which is live for demo: https://cloud-atlas.app/ (only the Google Login is active)
The client is a JAMStack website (static html file, which is hydrated via API, stored on GitHub, build and served from Cloudflare Pages(200 CDN server), at zero cost)
Its a PWA, so it can be installed like an app, running your website/app itself even with https://cloud-atlas.app/ offline.
Overall, it behaves like an app, which is accessable through a website.
Every client is also a quasi-tracker itself, so it synchronizes direct connection adresses (WebRTC DHT as first fallback)
- direct via WebRTC (Trystero)
- sync WebRTC DHT (first fallback)
- torrents, IPFS (second fallback) (Trystero reconnects through torrents and ipfs as a fallback)
- if that fails, one of the other 10 fallbacks, than back to 1. (direct)
Summary
So this is taking advantage of the webtorrent/bittorrent network and the IPFS network first, (Trystero) but as soon as you have enough peers continously, these already online peers are becoming the 99% of the time used p2p trackers themselves (some time after their launch, for instance Facebook, had minimum a few users online every second of a 24h day, which is the equivalent to 99,9% server uptime in a p2p network)
Fallback 1
Besides exchanging their DHT steady, they also are able to get their dht via a classic torrent, saved on some torrent websites, or like a post somewhere with a magnet link you save every few hours automated on a/or multiple socialmedia websites, and god knows where else...
Fallback 2 (theoretically) ??? ...and possible "mainnet"??? (here mainnet is the most reliable fallback option, which would equal a centralized server, but which its not)
The swarm always found via dyndns???? Maybe Bugoff as a decentralized P2P API server(appdata & dht), always found via dyndns??????????? Maybe Zerotier concept, making the swarm its own multilayer network???
Fallback 3
Your "very first entry" domain/site gets a 60sec updated dht list. But only used as last last last fallback in case, after everything else what i just wrote failed.
You get the upside down concept, which causes pragmatically what we could call True P2P territory, right? ;)
These beasts (clients) pretty much crawling their options for connections, the opposite way a centralized entity would do.