The recommended Berty in this issue is an open, secure, offline first, peer-to-peer, and zero trust messaging application.

Berty’s characteristics

• Security and Privacy: By default, messages are end-to-end encrypted metadata kept to a minimum. Creating an account does not require a phone number or email address, and its attributes can be preserved even when used on adversarial networks
• Review elastic decentralization, distribution, point-to-point and serverless. With the help of BLE technology and mDNS, no Internet connection is required.
• Open: Forever Free and Open Source

require

General React Native Requirements

• Homemade or selected package manager
• Node>=12. x
• The yarn manager

IOS development requirements

• Mac OS X
• XCode(Latest stable version)

Android development requirements

• Android application development environment, such as Android Studio
• Android SDK，Enable the following feature (Tools –>SDK Manager in Android Studio code): SDK platform “Android 11.0 (R)” Android SDK build tool LLDBNDK version 23.1.7779620 (export ANDROID-NDK_COME=”$ANDROID_COME/ndk/23.1.7779620″) Create Android SDK command-line tool

Berty Intended for use as a daily messaging application. Nevertheless, its construction primarily serves the following use cases:

• When you need to share sensitive information through untrusted networks, such as while traveling
• If you want to communicate anonymously
• If you want complete control over your data and therefore do not want to rely on third-party servers
• In countries/regions that actively monitor and adjust their networks, restrict their use and review certain content
• In areas with weak or no connection at all

Under the hood

The Berty protocol comes with a universal but fully functional SDK that allows developers to write peer-to-peer applications. You can focus only on the advanced features of your application, and we will handle the rest (encryption, identity, network routing, group management, account management, device management, application lifecycle).

The main concept of the Berty protocol is called “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

Anti censorship and anti surveillance communication protocol

Berty is an anonymous, secure point-to-point protocol that can run without an Internet connection.

There is a protocol that uses advanced cryptography and a messenger application built on top of it.

• Creating an account does not require a phone number or email
• End to end encryption used to encrypt all conversations
• Focus on leaking as little metadata as possible
• Decentralized, distributed, and serverless
• No consensus, no blockchain
• No internet connection (using BLE technology and mDNS)
• Forever free, no data storage, transparent code, open source

Purpose:

• When you need to share sensitive information.
• If you want to communicate with good anonymity.
• If you don’t want to use the server because you want complete control over your data.
• In countries with censorship and restrictions on internet access and use.
• In areas where the connection or cellular reception signal is weak or non-existent.
• When you travel and wish to communicate securely through insecure public connections.

Go-IPFS-Log

IPFS log was originally created for distributed peer-to-peer databases on orbit db IPFS. This library aims to provide fully compatible ports for JavaScript versions in Go.

Most of this code comes from the IPFS log library in JavaScript.

Gomobile-IPFS

This repo aims to provide packages for Android, iOS, and React Native, allowing people to run and use IPFS nodes on mobile devices. It is also a place to discuss the limitations of running IPFS on mobile devices in order to find solutions and communicate skills.

road map

• Basic Java/Swift<->go ipfs binding
• InputStream as request body and request response IN PROCESS
• Unit testing using Android/iOS testing framework
• SetStreamHandler(protocolID, handler) and NewStream(peerID, protocolID) binding
• Packages built and published using CI
• Android/iOS lifecycle management
• React -Native Module in progress
• Improve this self description file

Berty Agreement

This document provides a technical description of the Berty protocol. The Berty protocol provides secure communication between devices owned by the same account, communication between contacts in one-on-one conversations, and communication between multiple users in multi member groups. This article will explain how these points are implemented in a distributed and asynchronous manner, regardless of whether IPFS and direct transport (such as BLE) are used to access the Internet. It will also describe how the Berty protocol provides end-to-end encryption and perfect forward secrecy for all exchanged messages.

influence

Berty uses IPFS for specific purposes of instant messaging. There are two main advantages of using peer-to-peer networks for instant messaging:

• It is almost impossible to stop or cancel it: anyone can start a node on their computer within a few seconds, and two nodes in the same LAN can still communicate and operate without Internet access. In the centralized model, it is easier to block access to related company servers, or even force them to shut down their servers and stop their activities.
• Difficult to monitor: There is no central server that can be monitored, nor is there a central directory that can be destroyed, so metadata collection is greatly reduced. The Berty protocol is not a directory that links public keys with personal data such as phone numbers, but uses a combination of TOTP and public keys to generate a collection point address and register its users on IPFS, which can then be contacted with peers who wish to communicate.

However, it also brings some technical limitations:

• Content availability: Due to the lack of central storage, all messages are stored on user devices and cannot be accessed from devices that are offline or inaccessible from a given network.
• Asynchronous: There is no central server to govern the timeline, so timestamps cannot be used for any purpose other than critical tasks (such as displaying messages in a specific order). For example, expiration time cannot be used to revoke access to resources, and the order in which operations occur in a set of peers cannot be determined with certainty……
• Permission: There is no central authority to arbitrate operations and any resulting conflicts or manage user identities and permissions.

Marshal Point

A collection point is a volatile address on a peer-to-peer network where two devices can meet. Peers can register their peer IDs and/or obtain a list of registered peers on a given set of points. In this way, for example, peers who need to connect together to exchange messages in a conversation can find each other.

Peers need to be able to generate the same address for a given set point using previously shared secrets.

In the Berty protocol, the address of a collection point is generated by two values:

• Resource ID
• Time based token generated from a 32 byte seed

The generation of time-based tokens follows the core principles of RFC 6238.

// golang
func rendezvousPoint(id, seed []byte, date time.Time) []byte {
    buf := make([]byte, 32)
    mac := hmac.New(sha256.New, seed)
    binary.BigEndian.PutUint64(buf, uint64(date.Unix()))

    mac.Write(buf)
    sum := mac.Sum(nil)

    rendezvousPoint := sha256.Sum256(append(id, sum...))

    return rendezvousPoint[:]
}

There are two types of collection points in the Berty protocol:

• Public Collection Point: Accounts use this collection point to receive contact requests. The resource ID used here is the Account ID, and the seed can be updated by the user at will, so the ability to send contact requests to users with only the previous seed can be revoked.
• Group collection point: This collection point is used to exchange messages within a group. The resource ID used here is the Group ID, and the seed cannot be changed.

—END—

Open source protocol:Apache-2.0, MIT