berty / go-libtor

Self-contained Tor from Go

Berty is an open, secure, offline-first, peer-to-peer and zero trust messaging app

---

TLDR : Install it!

Mobile

To use the latest released version, install it from Google Play or Apple App Store.

To compile and run the mobile application on your device, see js/README.md.

CLI

You can go run or go install the CLI tool located in go/cmd/berty. The two main command line utilities are:

• berty mini: a CLI messaging app using the Wesh Protocol.
• berty daemon: a full node manageable through the Wesh Protocol API.

Introduction

Warning: Berty is still under active development and should not yet be used to exchange sensitive data.

Berty is a privacy-first messaging application built on top of the Wesh Protocol.

• Secure and private :
  • Messages are end-to-end encrypted by default
  • Metadata is kept to a minimum
  • No phone number or email address is required to create an account
  • Built to retain its properties even when used on adversarial networks
• Censorship-resilient
  • Decentralized, distributed, peer-to-peer and serverless
  • No internet connection is required, thanks to BLE technology and mDNS.
• Open :
  • Free forever and open-source

Berty is designed to be used as a communication tool when all other traditional messengers fail. Berty Messenger serves the following use cases:

• When you need to share sensitive information over untrusted networks, for instance while traveling
• If you want to communicate anonymously
• If you want full control over your data and thus don't want to rely on third-party servers
• In countries that actively monitor and temper with their network, restricting its use and censoring some of its contents
• In areas with weak or no connection at all

Berty is currently developed by Berty Technologies, a French nonprofit organization.

Note: this project is led by a small team made of humans, who make mistakes. Please do not hesitate to point out bugs or missing features. See the contribute section below.

We cannot promise we will offer you the best application, but we dedicate ourselves to doing our best to create a great one.

The philosophy behind Berty

We want to contribute to a world where free and secure communications are common and fear of censorship or surveillance are not.

We believe that open-source is more secure, as anyone can examine the code and improve it: this is why we rely on and build open and free software.

As the founding team, our ultimate goal is to progressively relinquish control over Berty and to make it become a truly global community project.

More info on berty/community.

Development Status

The current Berty implementation is using the Wesh Protocol, which means the encryption technique is safe, and it works as a peer-to-peer app!

Alas, Berty has not yet been hardened, so please avoid using it on devices with weak sandboxes, such as unpatchable devices that use old Android versions.

The current Wesh Protocol is partially implemented.

The API will continue to evolve in the near future. As such, we cannot yet guarantee none-breaking changes, or any kind of API stability. Be prepared for a rough ride if you start rolling the Wesh Protocol in your application.

Subscribe to our newsletter if you wish to be notified about the latest features and releases.

Note: The repositories are being opened progressively, and there will be additional modifications and updates soon.

Under the hood

Wesh Protocol

The Wesh Protocol comes with a generic, but full-featured SDK allowing developers to write peer-to-peer applications. You can just focus on high-level features for your app, we will take care of the rest (encryption, identities, network routing, group management, account management, device management, application lifecycle).

The main concept of the Wesh Protocol is called the "group", a virtual place where multiple devices can share messages and metadata using OrbitDB, which itself relies on the InterPlanetary File System (IPFS)

Get it:

git clone https://github.com/berty/berty

The Berty Messenger

The Berty Messenger, or simply Berty, is a messaging application written in React Native, that uses the Wesh Protocol through gomobile-ipfs, which, in turns, is using gomobile.

Main items in the repo

• ./go: Where all the Golang code lies.
  • ./go/framework/bertybridge: The gomobile entrypoint.
  • ./go/cmd/berty: The main Berty CLI:
    • berty daemon: Runs the whole Wesh Protocol instance.
    • berty mini: Simple CLI messenger application using Wesh Protocol.
  • ./go/cmd/rdvp: A Rendez-Vous Point server.
  • ./go/cmd/welcomebot: An onboarding bot used during the early phase.
  • ./go/cmd/testbot: A bot used by integration tests and developers.
• ./js: Where all the Javascript/Typescript code lies:
  • The Berty Messenger application, written in React Native.
• ./docs: Mostly auto-generated documentation.

Contributing

We welcome contributions! Your input is deeply appreciated and extremely valuable to us. We thank you in advance for it.

There is no small feat: everyone is encouraged to do what they can to help, based on their ability and interest.

There are plenty of ways to get involved and to help our community, which can roughly be divided in two distinct parts: everything that is related to the code and everything that is not.

To put it simply:

• Code-related = GitHub
• Not code-related = Open a task

Everything about contribution is summed up here: CONTRIBUTING.MD

Stargazers over time

Other resources

• Official website: https://berty.tech
• Assets: https://assets.berty.tech/
• Application assets & mockups: https://assets.berty.tech/categories/app__v2.4/

Contact

For a direct contact, see our contact page of our website. Alternatively, take a look at our community repository.

Licensing

© 2018-2023 Berty Technologies

Licensed under the Apache License, Version 2.0 (LICENSE-APACHE) or the MIT license (LICENSE-MIT), at your discretion. See the COPYRIGHT file for more details.

go-libtor's Issues

gomobile aar package build problemas

# berty.tech/go-libtor/libtor
In file included from ../pkg/mod/berty.tech/[email protected]/libtor/linux_tor_src_app_config_config.go:10:
In file included from ../pkg/mod/berty.tech/[email protected]/libtor/../linux/tor/src/../src/app/config/config.c:71:
In file included from ../pkg/mod/berty.tech/[email protected]/libtor/../linux/tor/src/core/or/channel.h:15:
In file included from ../pkg/mod/berty.tech/[email protected]/libtor/../linux/tor/src/lib/crypt_ops/crypto_ed25519.h:14:
In file included from ../pkg/mod/berty.tech/[email protected]/libtor/../linux/tor/src/lib/crypt_ops/crypto_curve25519.h:15:
../pkg/mod/berty.tech/[email protected]/libtor/../linux/tor/src/lib/crypt_ops/crypto_openssl_mgt.h:19:10: fatal error: 'openssl/opensslv.h' file not found
#include <openssl/opensslv.h>
         ^~~~~~~~~~~~~~~~~~~~
1 error generated.

Problems building sample with https://github.com/AgregoreWeb/gomobile-android-docker.
Tried to install apt-get install -y libssl-devwhat is most popular solution found about this , but did not work.

Any suggestion ?

Build is broken

The build here has been broken for a while and your Tor version is pretty old. Any interest in reviving this?

I managed to get it working again with current patched Tor at https://github.com/cmars/go-libtor/actions/runs/1901538112. In the process I did some extensive refactoring of the build process to use Mage, modularizing the build in the process. Doesn't support the lockfile thing, but that'd be easy enough to add.

No idea if iOS support still works but it could probably be revived. I don't have an iPhone, nor interest in supporting them at this time. I'd rather work on adding Windows msys support.

Should I propose a PR here at some point?

Linking problem with dynamic libs on iOS

We have a problem linking the different dynamic libs (libssl, libcrypto, libevent, zlib) required by the go-libtor package with our iOS app (arm64/iphoneos and amd64/iphonesimulator).

We lack time to investigate more and as we say in French: "Better one who knows than ten who are trying to find a solution".

To help find the problem, we have created a separate repo to do sanity checks, there are several branches:

1. This one contains a simple iOS app calling a go package compiled with gomobile calling itself functions from different libs (openssl, libevent, etc...).
2. This one is similar but uses a React-Native app.
3. The last one contains a React-Native app calling the libtor package compiled with gomobile.

The dynamic libs are the same on every branches, the first two work properly and the last one doesn't work (build ok, linking ok but crash during call to an openssl function). This suggests that the problem is probably due to an incompatibility between the dynamic libs and the go-libtor package.

@Jorropo will maybe continue to investigate on this issue, in any case, he can detail the steps he used to compile the dynamic libs. On my side I took care of:

• merging the arm64 and amd64 versions using lipo. e.g:

for lib in arm64/*.dylib; do
    lipo "arm64/${lib##*/}.dylib" "amd64/${lib##*/}.dylib" -create -output "fat/${lib##*/}.dylib"
done

• setting the correct rpath using install_name_tool. e.g:

for lib in *.dylib; do
    install_name_tool -id "@rpath/$lib" $lib
done

install_name_tool -change /tmp/torpref/lib/libcrypto.1.1.dylib "@rpath/libcrypto.1.1.dylib" libssl.1.1.dylib`
etc...

Note: these steps are not problematic as it works well on both targeted architectures and the linker is able to load the dylibs during runtime.

The following error occurs when pressing the Test button which trigger a call to a go-libtor test function (sorted from the bottom to the top of the stack, see left panel):

Steps to reproduce the problem on third branch:

• run make RNApp/node_modules RNApp/ios/Pods framework/Cgo.framework
• open RNApp/ios/RNApp.xcworkspace with XCode
• run app in XCode

Consider upstreaming iOS and macOS support to ipasn/go-libtor

First, thanks so much for putting in the effort to add support for iOS and macOS it's very much appreciated!

We are considering using this library for integrating tor into our own app (ooni/probe) and stumbled into this.

I noticed in the readme you mentioned that you decided to just fork the project because ipasn/go-libtor looked abbandoned, but I see that there is some recent activity over there.

There is also clearly interest in having iOS and macOS support in the upstream version of the library too.

Would you consider contributing the changes back to the upstream so the maintenance effort can be consolidated in a single repo?

@karalabe do you see any issues with upstreaming the changes from this library?

Build Fail

# berty.tech/go-libtor/libtor
In file included from /go/pkg/mod/berty.tech/[email protected]/libtor/linux_tor_src_app_main_main.go:10:
/go/pkg/mod/berty.tech/[email protected]/libtor/../linux/tor/src/../src/app/main/main.c:87:10: fatal error: event2/event.h: No such file or directory
   87 | #include <event2/event.h>
      |          ^~~~~~~~~~~~~~~~
compilation terminated.