AOSSIE-Org/OpenPeerChat-flutter
go to github downloadPeer-to-Peer Messaging Application
GSoC pitch 2021.
Chosen Idea:
A message sending/relaying messages to nearby devices until the destination is reached, instead of relying on a central server. GPS positioning could be used to route messages along the shortest path. Right now, despite the use of end-to-end encryption, our best and most popular messaging apps still rely on central servers to intermediate the communication. This has disadvantages such as:
- Authorities can censor the use of the messaging application by targeting the operator of the servers.
- The operator of the servers can know who is talking to whom, even if it can’t know exactly what they are talking about.
- An internet connection is needed to communicate with the server.
- A messaging app that enables peer-to-peer communication would be a very interesting app where the issues above are relevant.
The app will provide extra resilience, censorship resistance and privacy is, of course, communication efficiency. Messages would be transmitted more slowly. And, if there is not a path of users geographically between two users A and B to relay the message, a message from A to B might never arrive.
Mentors: Bruno, Thuvarakan
Proposal Description:
- Proposing to build a Chat app for Android and IOS in flutter/dart which sends messages Using Bluetooth & wifi-direct.
- Each device has a UUID to identify it and optionally the user’s name.
- Each account is linked to a username(can be authenticated using OAuth) and each message is directed to another username which is mapped to all devices logged in with that username.
- Users can choose to be anonymous as well.
- Using Bluetooth and wifi direct eliminates the use of a central server.
- The app scans for nearby devices which are discoverable and connects to them allowing messages to be relayed through each device(a node in a network)
- The messages will be transferred using an optimal path using underlying network protocols.
- Protocol to be used: for hops, I will be using the gossip protocol, as it works even when devices are removed and added frequently.
the way the protocol works is:
The following have been implemented
- Discover nearby devices
- Connect to nearby devices
- Send messages to multiple devices
- Receive messages form mutliple devices
- Normal chat interface built
- Designed the hop architecture (Push gossip protocol)
- each message has a unique ID
- Each message should be transmitted to other nodes using the above described gossip protocol
- For this Each device on the network must be able to “gossip” and transmit the message to the destination
- Offline storage of undelivered messages:
- If a ‘delivered’ callback is not received from the recipient the, the message is marked as undelivered, and its put in a local SQLite database(because SQLite has native support for android)
the sender device will ping for the recipient in small regular intervals thereafter and if it finds the device ‘online’ on the network then it’ll retry to send the message.
Once the message has been delivered, it’ll be marked as delivered. - RSA encryption has been implemented. The user can upload public keys of their friends and the message will be encypted using that. Thus messages are end to end encypted
Gossip Protocol
- Multicast sender
Push gossip protocol
- When a node receives a message or gossip, it periodically passes it on to other nodes, and that node is said to be infected
- all infected nodes periodically multicast to other nodes
Pull gossip protocol
- Periodically poll a few randomly selected processes for new multicast messages that you haven’t received and gets those messages
- If there are multiple such messages, it polls a few of them randomly
Hybrid variant
- Mix of both push and pull types
The push protocol is lightweight in large groups, spreads quickly and is highly fault-tolerant. Let us see why.
Analysis of the Gossip Protocol
Interestingly the analysis of the protocol is similar to the analysis of epidemic disease spread (cough cough covid)
So,
- If we have a population of n+1 individuals mixing homogeneously
- If the contact rate between any individual pair is denoted to by B
- At any time, each individual is either uninfected (numbering x) or infected (numbering y),
- Then x+y is a constant equaling to n+1
- Intuitively, we can say that if an infected and uninfected node communicate, the latter obviously turns infected.
After solving a couple of differential equations, we get
-
x=n(n+1)/(n+e^(B(n+1)t)) as t goes to infinity we can see this approaches 0, thus all of the nodes are infected. The next equation collaborates this.
-
y=n(n+1)/(n+e^(-B(n+1)t))
-
Taking B=b/n we end up with y=(n+1)-1/(n^(cb-2)) in log(n) time.
Wow, that’s pretty fast, right?
That explains why COVID spread so quickly!
Analysis of pull protocol
-
As a fact, all gossip protocols take O(log n) rounds before half of them get to gossip.
-
This is because it’s the fastest way to send a message. Construct a spanning tree with a constant degree of every node is O(log n).
-
Once this point is achieved, we find that the pull protocol is faster than the push protocol.
-
Let p(i) be the fraction of non-infected processes, after ith round, then
p(i+1)=(p(i))^(k+1)
-
This is super-exponential.
-
Thus the second half of the gossip protocol finishes in O(log(log n))
Mixing pull and push in both halves gives rise to a hybrid version.
- The messages need to be compressed
- The message can be broken into many pieces during transmission and rebuilt at the destination. This helps in maintaining security as each node will never have the complete message
- If the receiver is not online in the network then the sender’s device must have the ability to store it and ping the receiver in regular intervals and when it finds it online again, it should resend the message.
- such unsent messages will be stored in a local database
- Use Case of such a p2p system: complete disruption of internet and phone services in case of natural disasters.
Implementation
There are 6 main parts the above idea can be broken into,
- Build a android/IOS app that can,
- Discover nearby devices
- Connect to nearby devices
- Send messages to multiple devices
- Have a Normal chat interface
- use the ‘hopping message’ architecture to relay messages
- offline storage of undelivered messages
excellent projects related to AOSSIE-Org/OpenPeerChat-flutter recommend downloading
AppFlowy
47859
AppFlowy is an open-source alternative to Notion. You are in charge of your data and customizations. Built with Flutter and Rust.
localsend
33797
An open-source cross-platform alternative to AirDrop
spotube
23772
🎧 Open source Spotify client that doesn't require Premium nor uses Electron! Available for both desktop & mobile!
revanced-manager
15035
💊 Application to use ReVanced on Android
gsy_github_app_flutter
14559
Flutter 超完整的开源项目,功能丰富,适合学习和日常使用。GSYGithubApp系列的优势:我们目前已经拥有Flutter、Weex、ReactNative、kotlin 四个版本。 功能齐全,项目框架内技术涉及面广,完成度高,持续维护,配套文章,适合全面学习,对比参考。跨平台的开源Github客户端App,更好的体验,更丰富的功能,旨在更好的日常管理和维护个人Github,提供更好更方便的驾车体验Σ( ̄。 ̄ノ)ノ。同款Weex版本 : https://github.com/CarGuo/GSYGithubAppWeex 、同款React Native版本 : https://github.com/CarGuo/GSYGithubApp 、原生 kotlin 版本 https://github.com/CarGuo/GSYGithubAppKotlin
dio
12249
A powerful HTTP client for Dart and Flutter, which supports global settings, Interceptors, FormData, aborting and canceling a request, files uploading and downloading, requests timeout, custom adapters, etc.
gopeed
11832
A modern download manager that supports all platforms. Built with Golang and Flutter.
bloc
11441
A predictable state management library that helps implement the BLoC design pattern
getx
9899
Open screens/snackbars/dialogs/bottomSheets without context, manage states and inject dependencies easily with Get.
flame
8846
A Flutter based game engine.
flutter_deer
7595
🦌 Flutter 练习项目(包括集成测试、可访问性测试)。内含完整UI设计图,更贴近真实项目的练习。Flutter practice project (including integration testing and accessibility testing). Contains complete UI design drawings for a more realistic practice project.
fish-redux
7343
An assembled flutter application framework.
hiddify-next
7232
Multi-platform auto-proxy client, supporting Sing-box, X-ray, TUIC, Hysteria, Reality, Trojan, SSH etc. It’s an open-source, secure and ad-free.
ente
6686
Fully open source, End to End Encrypted alternative to Google Photos and Apple Photos
fl_chart
6451
FL Chart is a highly customizable Flutter chart library that supports Line Chart, Bar Chart, Pie Chart, Scatter Chart, and Radar Chart.
pixez-flutter
6360
一个支持免代理直连及查看动图的第三方Pixiv flutter客户端
Flutter-Responsive-Admin-Panel-or-Dashboard
6355
Responsive Admin Panel or Dashboard using Flutter
aidea
6021
AIdea 是一款支持 GPT 以及国产大语言模型通义千问、文心一言等,支持 Stable Diffusion 文生图、图生图、 SDXL1.0、超分辨率、图片上色的全能型 APP。
riverpod
5828
A reactive caching and data-binding framework. Riverpod makes working with asynchronous code a breeze.
pikapika
5463
美观易用且无广告的漫画和游戏客户端,同时支持MacOS,Windows,Android,iOS。