When running Xeres, you definitely need to connect to some friends. Either try with someone online, but if you want, you can also use an automated ChatServer.
The main concept is to exchange IDs. You give your ID to your friend and your friend gives his ID to you. Only if you do this exchange, you can connect.
There are 2 menus which are useful for this. The first one is Peers / Copy own ID to Clipboard which will make your ID ready to paste to your friend. The other menu is Peers / Add Peer… where you can paste your friend”s ID.
Once those 2 steps are done, the software will connect directly and securely, without using any 3rd party or server.
--no-gui: start without an UI. Can be used to run Xeres in headless mode. Use another instance with
--remote-connectto connect to it.
--iconified: start iconified into the tray. This is useful for auto startup.
--data-dir=<path>: specify the data directory. This is where Xeres stores all its user files. If you want to run several instances, they each need to have a different data directory.
--control-port=<port>: specify the control port for remote access. This is the port the UI will connect to. If you want to run several instances, they each need to have a different control port, but Xeres will try to find a free slot automatically (starting from 1066) so this argument is rarely needed.
--server-address=<host>: specify a local address to bind to (if not specified, binds to all interfaces).
--server-port=<port>: specify the local port to bind to for incoming connections. By default, Xeres choses a random port and uses it forever for the same instance.
--fast-shutdown: ignore proper shutdown procedure. This is mostly useful for testing when you need to quickly run/shutdown Xeres instances. Not needed for normal usage.
--server-only: only accepts incoming connections, do not make outgoing ones. Mostly useful for chat servers.
--remote-connect:<host>[:<port>]: starts as an UI client and connects to the specified node. You can also do this across machines on a LAN. Be wary that the connection is not encrypted. Use SSH tunnels if you want to overcome that limitation.
--version: print the version of the software
--help: print the help message
Will something else than Chat and Forums be supported?
Yes. It is planned to support most of the Retroshare feature set, eventually.
Which Retroshare services are implemented?
Why this project, if Retroshare exists?
Xeres is not meant to compete against Retroshare but to advance the P2P platform. By having several implementations, more bugs can be found and documentation can be written. Experiments can also be made in one implementation without disturbing the other, then the results can be shared and discussed. Finally, it also leaves users with more options to choose from.
Xeres itself is focusing on the following points:
- Java is a managed language, unlike C++, which should make it more stable. I dare you to crash Xeres by sending some crafted packets. The worst you will get is a disconnection.
- The user interface is designed as a client/server model because I believe effective P2P requires an instance that is always running yet easily accessible from anywhere. Mobile devices and their limited battery are ill advised for running a full node. Instead the mobile client (once available) will connect directly to the instance running at home.
- The UI should be lean, non blocking and easy to use. It should also make content creation a breeze because there’s no corporation to “curate” (and censor) anything.
Is Xeres compatible with Retroshare?
Yes. You just need Retroshare 0.6.6 or higher.
Are there other projects compatible with the Retroshare protocol?
There’s Rustyshare by sehraf, written in Rust.
Is it a good idea to add as much random users as possible to improve connectivity?
First, although Xeres was designed to scale well, having many friends won’t necessarily improve the experience because of the way the protocol works (simply put: streamed and smart). It’s better to have a few reliable and fast connections than many spotty ones.
Second, the security model of the RS protocol is based around being connected to “trusted nodes”. For example it is very easy to crash a connected Retroshare node by sending in crafted packets. Xeres won’t crash but will log some error or disconnect the peer, though no notification will be made of any hacking attempt.
Third, there’s a frequent misunderstanding on how the protocol works. If for example you look for a file that your friends don’t have, the search will go beyond them, to their friends, friends of friends and so on, with a depth of 7. The file will then get to you through their connections.
And lastly, a friend can roughly discover your areas of interests and activities like subscribed chat rooms, time online and so on. Recent versions of Xeres allow to set a trust level to connected profiles and while this is not being taken advantage of right now, it might be used for a few improvements in that area later on.
Can Xeres be censored?
By using peer to peer connections, there’s no centralized endpoint. Nobody can impose its viewpoint on the whole network. For maximum efficacy, make sure you connect to actual friends and don’t hesitate to disconnect from someone whose content you don’t tolerate. All the power is in your hands.
Why is the MacOS version gone?
Because of some (currently non resolved) problems with the packaged version failing to run. It can still run on MacOS if you compile from source directly. See the instructions.
I get an error while installing the package in Debian 11 about some unknown compression.
This is caused by older Debian not supporting zstd. Check this stack overflow thread.