I am reviving a topic that received some attention about a year ago, regarding building a messaging system on Autonomi. At that time, @Toivo and others were looking at registers and I think some simple messages were sent through the network that way, although I can’t find the Alice/Bob examples I am recalling seeing.
Recently, I stumbled across an open source communication system called Trystero, created by Dan Motzenbecker. See:
You may have seen the chat web page example I created with it using @Traktion 's sn_httpd.
It relies on Bittorrent, Nostr, IPFS, MQTT, Supabase, as well as others, as options for peer discovery and connection for encrypted, decentralized, peer-to-peer communication. I became curious about whether Trystero could be modified to work with Autonomi as the basis for peer discovery and connections.
I wanted to check in with developers to see if there are any messaging apps currently in the works. I also wanted to check to see if there is interest in exploring this avenue. I do have an email out to Dan Motzenbecker to investigate the feasibility of modifying Trystero for use with Autonomi.
As far as connecting peers goes, what is in place on Autonomi currently for peer discovery? I found the bootstrap cache here, but haven’t studied it, as that would take some time.
It was great to try this chat app working the other day. It would be great if Autonomi could do the peer discovery.
Another option could be to use the new LinkedList data type recently discussed on this pages. A chain of messages between multiple parties could be represented as a chain of messages on a LinkedList. I understand these can also be private or public.
Ofc, you may want chat to be more ephemeral, in which case perhaps the LinkedList could be used to add users (and some connection details, presumably) when they join the chat. It looks like the javascript app can take it from there then.
There might be a way to adapt what Savoir Faire Linux (Montreal) is doing to evolve the old RING project now called JAMI, it can be setup to be completely peer2peer. I have been using it for awhile for another small project and it really is quite good now…
What I am thinking is forking JAMI and adapting the comms setup to work with XOR so as to use of secure comms channels of the Autonomi Network Kademlia style , its a pipe dream of mine right now, but maybe others are interested too?
Yes, @Helen it looks in theory to be adaptable to Autonomi Network, of course success in integrating is always deep in the details.
I am going to keep digging a bit on this, to see what amount of work would be needed to pull this off. I work with a really good event driven architecture person who can help look into this , so I am thinking an application might be to stick some open source pub sub broker apps in between running on the autonomi network to get this type of traffic to scale with low latency, which is what JAMI does now…, they have hi performance relay nodes that can be plugged in optionally…,
my spidey sense it yelling at me
“it makes no sense re-inventing the wheel if we can adapt this properly… with out too much work…”
A bit more on this via Brave AI Assisted Search Summary
TURN Server Functionality
In Jami, which is developed by Savoir-Faire Linux and uses a Distributed Hash Table (DHT) network, TURN servers play a crucial role in facilitating peer-to-peer communication for multi-party audio, video, and chat sessions. Here’s how the TURN server function works in this context:
Peer-to-Peer Communication: Jami operates on a peer-to-peer (P2P) model, meaning that direct connections between devices are preferred for communication. However, due to Network Address Translation (NAT) and firewalls, direct connections are not always possible.
STUN and TURN: Jami uses both STUN (Session Traversal Utilities for NAT) and TURN (Traversal Using Relays around NAT) protocols to manage NAT traversal. STUN helps devices discover their public IP addresses and port numbers, but when direct peer-to-peer connections cannot be established, TURN comes into play.
TURN Server Function: A TURN server acts as an intermediary when direct connections between peers are blocked by NAT or firewalls. It relays media packets from one device to another, ensuring that communication can still occur even when direct peer-to-peer connections are not possible.
Relaying Media: In multi-party audio, video, and chat sessions, TURN servers relay media packets between participants. This is particularly useful for large groups where direct connections between all participants might be impractical or impossible due to network constraints.
Scalability and Reliability: The DHT network used by Jami allows for efficient and scalable distribution of communication data. TURN servers enhance this by providing a reliable fallback mechanism when direct peer-to-peer connections cannot be established, ensuring that multi-party sessions remain functional and high-quality.
Security and Privacy: Jami emphasizes privacy and security, and the use of TURN servers in this context is designed to maintain these principles. Media data are encrypted and stored only on the devices of the participants, with TURN servers only relaying the data as needed.
In summary, the TURN server function in Jami’s DHT network ensures that multi-party audio, video, and chat sessions can be conducted securely and reliably, even in challenging network environments.
“How does JAMI from SAvoir Faire Linux scale multiconference and chat sessions across their DHT network?”
Jami Distributed Network
Jami, developed by Savoir-faire Linux, scales multiconference and chat sessions across its DHT (Distributed Hash Table) network by leveraging a decentralized architecture that ensures robustness and scalability. Here’s how it works:
Decentralized Network: Jami relies on a distributed network, which means there is no single point of failure. Each Jami account runs an OpenDHT node, contributing to the network and enabling Jami to scale efficiently.
Persistent Node Cache: Jami clients use a persistent node cache to reconnect to the network after a first session. This cache helps in maintaining connections even if the network topology changes.
Bootstrap Nodes: A known, stable “bootstrap” node is used for the first connection or if cached nodes do not respond. By default, Jami clients use bootstrap.jami.net:4222 as the bootstrap node and network ID 0, which is the default, public OpenDHT network.
User Independence: Users can have full independence by running their own stable OpenDHT node and configuring it as a bootstrap node in Jami. This not only enhances their own network experience but also contributes to the overall stability and resilience of the public OpenDHT network.
Scalability: The distributed nature of the network allows Jami to handle large numbers of nodes and continuous node arrivals, departures, and failures with minimal disruption. This ensures that the system remains efficient and reliable even as the number of users grows.
By distributing the responsibility for maintaining the mapping from keys to values among the nodes, Jami ensures that the network can scale effectively and handle the demands of multiconference and chat sessions without compromising performance or reliability.
Jami, developed by Savoir-faire Linux, uses a distributed hash table (DHT) technology to deliver reachable public addresses to all users. This DHT is similar to the one used in BitTorrent and IPFS, allowing nodes on the network to find and connect to each other. When a Jami user connects to the network for the first time, the software uses an OpenDHT node maintained by Savoir-faire Linux to join the network. However, users have the option to run this through their own bootstrap server in the advanced settings.
In Jami, your account is stored locally on your device, and your public address is derived from your public key. When you create a Jami account, you don’t need to provide personal information such as an email or phone number. Instead, your account is identified by a Jami ID, which is a fingerprint of your public key. This ID is used to establish connections with other Jami users.
For users to communicate, Jami relies on a decentralized network structure that does not require central servers. When you send a message, it is encrypted and sent directly to the recipient’s device through the DHT network. This peer-to-peer approach ensures that messages can be delivered even when users are offline, though the app stores messages locally to wait for the contact to return online.
In summary, Jami delivers reachable public addresses to users through a decentralized DHT network, ensuring privacy and security by not relying on central servers for relaying data between users.
I’m investigating this more… Jami is well documented. What do we need to know on the Autonomi end that is not yet available to us? I don’t have enough expertise to take a lead role on this project, but have some programming background, and the ability to learn and dive deep… I’ll continue learning about Jami for now.
@Helen Based on what I know about Kademlia between peers their are two bi-directional connections, one for meta data exchange (ie setup/teardown, heartbeat, error, warning stuff) and one for the actual data flow. JAMI has multiple dataflow types it supports for most popular mixes of audio//voice/chat… you can update/morph the metadata channel to a regular data channel, and visa versa.
I dont think in principle a TURN server is required given Autonomi current capabilities, but you do need to implement a bootstrap server on your JAMI client to get the service going to make your JAMI named client visible to other nodes you might have shared your ‘JAMI name’ with, or if you want the group/swarm you create to be a public one if its a multi-party persistent swarm you are creating…, at least that is my understanding at this point reading the JAMI docs,
I think doing any sort of integration means waiting to see first what DAVE ends up looking like from cli API perspective to see what is possible, ie- to map JAMI comms port connects to DAVE comms connects and prescribed port #s ?
Just thinking out loud here, and still studying JAMI docs…
Autonomi uses libp2p (Rust implementation). It seems libp2p capabilities could replace TURN. Another feature of libp2p is publish/subscribe. I was reading up on that here:
Thank you Helen, you are a most welcome addition to the community here. You are going over stuff we looked at some time ago and providing a fresh perspective and encouragement to the rest of us. The links are great, some we have seen, others are new (to me) and deserve review.
Another possibility for Instant Messaging is SimpleX chat-- @dirvine found this a while back (2023?) , it worked out of the box and in less than 2 mins we were chatting by voice. It got used for a while by me and a couple of others and IIRC the general impression was that it worked OK and could/should be integrated when feasible.
Python is not ideal for frontends and dirvine is working on the python libs but they’re not working yet - the solution with tauri app does make a ton of sense because they can use Javascript as ideal frontend tool and combine it with rust (tauri is written in rust and can execute additional rust functions easily) to use the maidsafe libraries that of course do work because everything is written in rust here…
(so doing it like this makes dave independent of api developments - which is a pretty powerful approach for working at the api in parallel to delivering the first app)
Ok I did a side by side compare of Simplex and JAMI, its pretty clear JAMI has way more knobs for nerds in the video codex space so quite tunable,
Simplex, well I am no expert but was well ‘spartan’ by comparison, in other words, you get what they throw at you,
Both have quirky left side UI/UX orientations , on both its not readily apparent where to start, both are turn everything on first before anything works permissioned, but I got over that after clicking around a bit, ‘clicktard style’
Both miss the mark on testing if the software installed actually works (lack of test server some where on the net) , zoom is much better at that , as are some others, even skype…
Is it just me , or is Simplex really pushing ‘man in the middle’ server setups with their own servers and some company named Flux?
Anyone else check either JAMI or Simplex out? I have not yet checked @TylerAbeoJordan 's suggestion, will take a look at that too…
ok a quick look @berty ran into no support for Desktop, and android apk is M-I-A… to I have parked that exercise for now…
Yes I get the rust thing, I was pushing that back in 2018 , that said if Python is being used as Prototype Client dev/test environ, then I’m game to help create it as an alternative upload client build, Python gets the AI crowd excited… and the NetOps/ DevOps types engaged too, and out of that comes weird and wonderful (and often useful) creativity that can be rust-ified later selectively in the main branch.
my thought is that you’re triggering discussions and binding energy in a moment where we should just invest time into developing apps and not into discussions and comparisons (but ofc the api is still missing so we can’t to the latter one which makes plans for apps somewhat useful xD)
…
my thought is that you’re triggering discussions and binding energy in a moment where we should just invest time into developing apps and not into discussions and comparisons