You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our current stack for group messaging, from the top of the stack down, is:
orbitdb (ipfs + pubsub + ipfs-log) for broadcasting new messages to all users in the network and making sure each user's transcript of a group chat stays in sync, e.g. when users go offline and return.
libp2p connecting via websockets (i.e. libp2p's mode when connecting to a typical website) to Tor onion addresses of users in the chat.
Tor.
But right now, direct messages in Zbay don't use any of the libp2p / ipfs / orbitdb layers. They just use the Tor + websockets layer, and work like a very naive implementation of Ricochet over websockets, i.e.:
Both parties run Tor.
Both parties run an onion service.
Both parties know each others' onion addresses.
Connections are not full duplex, so both sides need to connect to each other.
Messages are sent in the default websockets way.
We do this in the most naive possible way.
Messages are signed (but we don't have to worry about that for this POC.)
REQUIREMENTS
One valuable milestone in a full proof of concept would be to build a basic Android app with this basic Tor + websockets support. This would show us that at least Tor + websockets layer in our stack works correctly and can reliably receive messages. It would meet the following requirements:
We can provide it with key material for a Tor onion service (e.g. by pasting it in)
It runs Tor persistently in the background
It runs an onion service corresponding to the key material we provided.
It can receive websocket connections at this onion service.
It displays the raw message JSON it receives over websocket connections.
It triggers an OS-level notification when it loses its connection to the Tor network (so we can keep the phone in our pockets and receive a notification when it loses the connection, so we can get a sense of reliability.)
It triggers a notification when it receives a new message, and (optionally, if this is easy to do) displays the message text.
We don't have to receive actual messages from a Zbay client. Being able to send any kind of test messages over ws:// over Tor is enough.
Messages are signed with the key of the sender, but for the purposes here we just need to prove that we can receive the raw message data and not check signatures. We just want to make sure the network layer is working.
The text was updated successfully, but these errors were encountered:
@vinkabuki@kowalski anything to add here? would you simplify this in any way?
should we try to get full Zbay DMs working? Or should we just get something that can reliably run in the background and receive whatever kind of message via websocket-over-tor on Android?
holmesworcester
changed the title
A user can receive a direct message from Zbay
An Android user can reliably receive direct messages via websocket over Tor when app is running in background
Mar 8, 2021
holmesworcester
changed the title
An Android user can reliably receive direct messages via websocket over Tor when app is running in background
An Android user can reliably receive direct messages via websocket over Tor (including when app is running in background)
Mar 8, 2021
holmesworcester
changed the title
An Android user can reliably receive direct messages via websocket over Tor (including when app is running in background)
An Android user can reliably receive direct messages via websocket over Tor
Mar 8, 2021
BACKGROUND
Our current stack for group messaging, from the top of the stack down, is:
But right now, direct messages in Zbay don't use any of the libp2p / ipfs / orbitdb layers. They just use the Tor + websockets layer, and work like a very naive implementation of Ricochet over websockets, i.e.:
REQUIREMENTS
One valuable milestone in a full proof of concept would be to build a basic Android app with this basic Tor + websockets support. This would show us that at least Tor + websockets layer in our stack works correctly and can reliably receive messages. It would meet the following requirements:
The text was updated successfully, but these errors were encountered: