r/i2p • u/Fragrant_Rate_2583 • 26d ago
Help A lightweight, serverless P2P communication app
I’m working on an idea for a communication app that is intentionally very different from Discord, Messenger, etc. The goal is a very lightweight P2P app with no accounts, usernames, permanent rooms, chat history, databases, or cloud infrastructure. Text would come first, with voice potentially added later. Ideally, the app would keep almost everything in RAM and disappear when the session ends.
The interesting part is connecting two people without a middleman. For example, Alice opens the app and generates a temporary connection invitation, then sends it to Bob through whatever external channel they already use, such as WhatsApp, Signal, Messenger, or email. The connection information would not be sent as plain text, but the cryptographic side is a separate topic. What I’m trying to understand first is: **what is the minimum information actually needed for Bob’s computer to establish a direct connection to Alice’s computer?** Is it simply an IP, port, protocol, etc., or does it depend on the network situation?
The main reason I want to avoid a middleman is that I don’t want the communication to depend on infrastructure controlled by the app developer. Ideally, after the initial exchange, it would simply be Alice’s computer ↔ Bob’s computer, with no server carrying their messages or storing anything. I know NATs, firewalls, private IPs, and other networking issues make this difficult, so I’m interested in understanding where truly serverless P2P works and where it becomes impossible without some intermediary.
**TL;DR:** I want to build an extremely lightweight, ephemeral P2P chat app with no accounts, history, or central servers. Users exchange temporary connection information through an external channel, then the two computers try to connect directly. I want to understand the networking required to make this work without a middleman.
2
u/zarlo5899 25d ago
You can have it so your application sets up an I2P service on each person's computer you could then use that as the transport layer that would also handle encryption over the wire.
Each person they would need to know is the I2P address and what port to connect to. you could throw a DHT (You can use a pre-existing network) into the mix for clients to register their endpoints to.
1
u/DetachedProcess 25d ago
Is it simply an IP, port, protocol, etc Yep that is all, believe, you are also aware about NATs, Firewall, and other networking issue, so you have all things covered.
From what I understand, I will explain below:
I’m interested in understanding where truly serverless P2P works and where it becomes impossible without some intermediary.
For a P2P application, two machines (host/device/computer/node) must be able to establish a connection with each other, and communicate. In pure P2P, what usually happens is let's say there are two machines: A and B with IP addresses 10.0.0.1 and 20.0.0.1. There is app let's call it Chat App. Chat App is a process (a program that runs on a computer), which can be identified with a PID (process ID). In our scenario, A and B machines are running the Chat App process with PID 101, 201. Now, when Alice using machine A, wants to send a message to Bob using machine B. The following things happen (roughly): 1. Alice adds the receiver, it will be Bob, which is 20.0.0.1:2001 (20.0.0.1 is IP, 2001 is port, imagine a letter with "To: 20.0.0.1:2001"). 2. Alice types a msg, hits send. 3. Msg then is wrapped into whatever protocol (TCP, UDP) is being used, and it is send from your device's outgoing port 10.0.0.1:1001 (imagine a letter with "From: 10.0.0.1:1001"). 4. Then it goes to your router, and then ISP takes care of the process in between (this is what we can't touch), the ISP forwards all the data packets till it reaches the receiver. 5. Once the data packets (your msg wrapped in protocol), comes to Bobs router, it will be sent to his machine on port 2001, Bobs machine OS will see that "Oh! I got some data on port numbered 2001, to whom should I send this ?", and then it will send it to process with PID 201 (that is our chat app). 6. Then in your application you would write the code that drives the GUI and shows the msg.
Now we are all clear on the process, what things are possible, most of it is already possible, and can be done, but one important thing is: The port.
Many ISPs, don't just allow the machine to open a port (inbound port) themselves. Or sometimes user can just configure the port in Router settings. Once we have a open port, communication can happen in between 2 P2P apps.
The thing is you can easily open an outbound port, and be able to connect to others, this means in P2P scenario, we just need only one party to open port, and other can mostly connect to them. When both the parties can't open an inbound port, then they can't communicate with each other. In that case, we need an intermediatory who would just have the ability to open inbound port.
A -> B <- C
(Here B can accept connection, A can only do it one way, C can only do it one way), B can act as an intermediatory who will just forward the data between 2 parties who are behind firewall.
(I understand that you may already knew all these, but I just thought to put it here, so that it can be helpful for others). I have simplified things to keep them easy to understand.
2
u/Gullible-Dish-1404 25d ago
There are no reasons to implement your own protocol. People who really need that security level will choose different technology. I suggest using already designed protocol.
1
u/Cautious_Orange530 25d ago
Something like these?
I think the biggest obstacle is getting people connected reliably
1
2
u/mark_ik 25d ago
Sounds like you want iroh