The image below represents a group of connected friends.
- The peers in green (A,B,C,H,I and J) are subscribed to a chat lobby.
- Each peer of this group is receiving all messages of every other peer in this group.
- Messages are relayed by peers subscribed to this lobby only along the red connections.
Two types of lobbies
The design concept allows to have two types of lobbies:
- Public lobbies: Public lobbies are advertised to friends, and friends can join them by double-clicking on the lobby. A chat window appears and the user can participate in the lobby. The image below shows an example of a lobby list advertised by direct friends:
- Private lobbies: Private lobbies are not advertised to friends. They require a peer to be explicitly invited to a lobby to be able to access it. That makes the private lobbies totally impossible to spy on from outside the lobby, including direct friends who are not yet in the lobby.
Inside libretroshare, a lobby object cache contains the IDs of lobby objects that have been seen in the last 20 minutes, to only show and forward each of them once.
New RsItems have been designed:
- lobby management items. Such items are sent to friends to manage lobbies. Typically invitations, advertisement of lobby lists, etc.
- lobby object items. These items all derive from the same class that make them broadcast-able through a lobby. A routine function forwards items to other friends in the lobby and updates the lobby object cache.
For each peer, a chat lobby is just another virtual peer to chat to, just as in normal private chat. The GUI side of RetroShare therefore makes little difference between a chat lobby and a friend to talk to.
Lobby connection challenges
Every 20 messages, the lobby tries to add new connections: if two peers are subscribed to the same lobby, but not registered as direct participants, they make known to each other that they can forward messages directly. This is done in a way that prevents unwanted peers to spy on a lobby, using a system of connection challenge:
Peer B and C have roughly the same lobby message IDs, since they are subscribed to a common lobby, without actually knowing it. Peer C computes a non reversible hash from:
- the lobby ID,
- one of the recent message IDs of this lobby,
- B's SSL id,
and sends this hash into a connection challenge packet to B (C repeats the operation for all his friends, but the hash will be different).
B receives a connection challenge with code C. It tries all possible combinations of known lobby ID and lobby messages ID in cache. If a match is found, B knows that C participates in the matching lobby, and sends back an invitation to C to join the lobby. C receives the invitation and directly connects B (without GUI notice).
This protocol ensures that if C knows nothing about the lobby B tries to challenge, he cannot find out what the ID of this lobby actually is.
If a peer unsubscribes from a lobby, he can be responsible for splitting the lobby into two separated components. The connection challenges help preventing that, but this situation can still happen. Once disconnected, the lobby will be able to reconnect using challenges for a limited time period (while caches from both sides still share some message IDs). After that, the lobby can be connected manually by inviting a friend on the other side.
Lobbies with a very large number of people will probably not be able to propagate messages from end to end. While there is QoS on the leaving side of the packet transmission, there's no QoS on the incoming side. This means that if a peer is performing heavy file transfer for instance, it might slow down lobby traffic significantly. Across multiple hops, it's possible that messages take more time to travel than what the lobby cache can handle.
Chat lobbies are volatile objects. They are not saved. If a large number of persons is using a lobby, there is very little chance that the lobby will eventually disappear. On the contrary, a lobby that nobody uses will disappear by itself. This strategy promotes active lobbies.
It is possible to insert pictures in a chat lobby.
From RetroShare v0.5.5c (2014) the maximum file size of the pictures has been reduced (to avoid crash attempts by hackers). The maximum size of a file is around 4100 bytes (despite the "6000 characters" error message), the other bytes are used by Base64 and HTML datas.
If you insert a bigger file, the other users will only get this error message:
"**** Security warning: Message bigger than 6000 characters, forwarded to you by FRIENDNAME (FRIENDLOCATION), dropped. ****".
As of 2014-09-21 (v0.5.5c), from the tests of a user, the specifications are :
- PNG file format: work if size < 4156 bytes, and resolution < 221x127.
- JPG file format: none work.
Software recommended to reduce the file size of a picture:
- GIMP, for the feature that reduce the number of colors (menu Image > Mode > Indexed colors). You should reduce the picture pixels size (menu Image > Scale Image). You will have to save the file several times before to manage to get the right PNG file size.
- This page on Wikia list others softwares, and web applications.
The original functionality requirements list
Wrote in 2011. Moved here from the page Groups.
- We could call that 'conversation lobby'.
- In the GUI, one clicks on a group and asks 'start lobby'. An invitation is sent to all participants of the group.
- The GUI displays a list of nearby group chats the user is invited to, and allows participation to them.
- For each lobby, a chat window appears, with the names of the participants (basically who sent messages) and collects messages from the user.
- Invitations are sent to direct friends only.
- We need a lobby service to broadcast and relay messages, and notify the GUI.
- Each lobby has an ID, that identifies messages to belong to this lobby. Appart from that, messages have a time stamp used for sorting/display them, and a peer name (not an ID) of who posted the msg.
- Each node knows the list of his direct friends who participate in the conversation.
- When chatting in a group, messages to friends which will relay them to the entire group, using a cache system to avoid duplicates, and insert messages in the correct order.
- The msg broadcasting must only use people participating in the conversation to relay messages, to prevent evesdropping.
- The lobby finishes when all peers have disconnected. A big lobby can split into separate ones because of connection issues. Do we cache messages and re-send them as the connection re-establishes? Possibly. On the point of view of the user, the lobby exists while participating friends are connected and haven't sent a "lobby disconnect" packet. Such a packet is sent when the user closes the lobby window.
- (en) Distributed chat (a.k.a. Chat Lobbies) (november 2012).
- (en) Personally identifiable information (Wikipedia). Be careful with yours when chatting.
|This page is part of RetroShare Documentation|
|Permission is granted to copy, distribute and/or modify this document under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.|