DEV Community: Berty Technologies

Wesh: Flight of a Byte

Berty Technologies — Thu, 07 Sep 2023 15:17:19 +0000

In the previous blog post, we made an example app where the Wesh user account of “client2” sends a message “Hello” to a Contact group which is received by the other user account of “client1”. You can use the example to start building your Wesh app, but for development and debugging it helps to understand more about how it works. So this blog post will be a theory dive into some of the details of Wesh communication.

When the Wesh app on the computer for client2 sends the bytes of a message, what is the “flight path” of the bytes of “Hello” as they travel to the computer of client1? It's different from “traditional” networking where, for example, a computer sends the message in a UDP packet to the IP address of the other computer, as described in this Wikipedia article. Instead of a specific IP address, Wesh communication happens between libp2p peers, where the client's PeerID is the value that we've seen in previous examples and is the same no matter how the client is connected to the network.

Peer discovery

The “glue” between a libp2p peers and a more traditional network address is peer discovery. There are a lot of details that we won't go into regarding types of discovery, peer authentication, etc. In this blog post, we just describe the minimal steps for how client1 receives the message from client2. When the libp2p service of client1 discovers the computer of** client2**, it opens a network connection (code) and reads from it using a traditional byte stream (code). (We give links to code for curious readers, but this isn't a code tutorial and you can skip the code links.) We've mentioned the traditional networking code “under the hood” to remove some of the mystery. But that code doesn't immediately read the message from client2. Instead, there are some communication steps which allow Wesh to use libp2p to operate in a peer-to-peer environment.

Message log and “head”

To send a message in traditional networking, one user connects to the network address of the other user and transmits the message. Or the user connects to a central server and appends to the message log there, while the other user connects to the same central server and reads the message log. But this doesn't work in a peer-to-peer environment. Instead, the goal is for each group member to have a copy of the message log, where there is a “head” (the latest message) which refers to all the previous messages in a chain. To send a message to the group, a member adds to the local copy of the message log and updates the “head”. This will be synchronized with the other members.

Without a central server, each group member may add to the message log and receive updates from others in a different order. But the synchronization algorithm ensures “eventual consistency”: after exchanging enough messages, eventually all the users will have the same message log in the same order. At that point they will all have the same “head” message, which refers to all the previous messages in a chain. Wesh currently uses OrbitDB for this, and you can read the details in their manual. (In the future, Wesh may use a simpler library but it will still have the same concept of a synchronized message log with a head.)

As mentioned, client2 doesn't send the message “Hello” directly to the other group members. Instead, it puts the message in its own message log and updates the head. The other members learn about the new head which means there is a new message to fetch.

libp2p pubsub

So now the question is, how does client1 learn that **client2 **says there is a new message log head? This uses libp2p pubsub where peers can subscribe to a topic and publish a pubsub message to that topic, or receive pubsub messages. (We say “pubsub message” to not confuse with the ordinary messages in the log which we'll discuss below.)

libp2p pubsub is a powerful tool with algorithms which allow it to scale to many peers and to make sure they all get the pubsub message. You can read more in its documentation, but for this blog post we only need to say that the Wesh group has a libp2p topic name like /orbitdb/bafyreihpdptqwgpuwu4ob6nusxebmdx6fm6mq5pma5hva6eu5u74pflo7e/2ac4e88c5272f900c76fd36989f9780e5b2c95d75d38fe5bcef0345b34bc4806_wesh_group_messages.
Client2 publishes a pubsub message to this topic that contains the message log head. The libp2p on client1 receives this pubsub message and sends it (code) internally to all processes which are subscribed to the topic. The Wesh application of client1 has used ActivateGroup and is therefore subscribed to this topic and receives the pubsub message (code).

IPFS to fetch the message

libp2p pubsub doesn't care about the meaning of a pubsub message. It only makes sure that all subscribers get it. Remember that the next step is to synchronize the message log, which is handled by the local message store of client1. After checking that it's not a repeat, the pubsub message is forwarded (code) as an EventPubSubMessage to the message store which receives it (code). This confirms that the type of pubsub message is to update the message log head, and it checks to make sure the head was not already processed. (If client1 has already received the same message log head, maybe from another peer, then it doesn't need to do more processing. This may seem trivial, but it's important because it's efficient to exchange these small “head” messages frequently between peers.)

The message store receives (code) the event for a new head which contains the CID of the message. The message (which may be large) is fetched with IPFS, not with libp2p pubsub (which is better for small messages). If you don't know what a CID is and how IPFS uses it to fetch content, then you can read all about it. Notice that using a CID to fetch the message (code) like “Hello” is a separate process from synchronizing heads. Maybe IPFS has already fetched the same CID, or maybe it can be fetched from another group member that is not client2. Wesh takes advantage of the efficient IPFS algorithms.

Decrypting and finishing

We're almost done! When the “Hello” message is fetched, it's placed in the local copy of the message log in the correct order. (Messages in the device's storage remain encrypted.) This internally sends the EventReplicated event which is received (code) by the Wesh message monitor. We started at the libp2p “level” which doesn't care about the meaning of pubsub messages, up through the message log level which only cares about the correct order of messages. Now at the “top” level, Wesh must use client1's cryptographic keys to decrypt (code) the message.

The decrypted message is sent internally (code) to all monitoring processes, including the GroupMessageList service (code). The client1 application has called GroupMessageList, so the “Hello” message is sent (code) to the application which prints the message.

Flight of a Byte

In summary, the flight of a message from client2 to client1 starts when the client2 peer is discovered, subscribes to the libp2p pubsub topic for the group messages and publishes its message log head. client1 doesn't have this head yet, so it uses the CID to fetch the message using IPFS. When the message arrives, it is added to client1's copy of the message log in the correct order. Wesh sends this new message to processes using the GroupMessageList service, such as the sample application which receives it and prints “Hello”. Easy, right? Each of these steps is needed to make sure communication can still happen even if a peer disconnects or reconnects at a different network address.

Now that you know what to expect when your Wesh application communicates, we'll return to some more examples in future blog posts.

Wesh App: Share Contact and Send Message

Berty Technologies — Tue, 05 Sep 2023 15:26:34 +0000

We continue to use the Wesh API to build more capable apps. In the previous blog post, we made an example app which creates an account using persistent on-disk storage, and we discussed the types of information in Wesh. This includes a Contact group where two user accounts can communicate. In this blog post we will make an example app to share contact and send a message in the Contact group. (This is a longer blog post because we’re building a running app.)

As before, we write an app similar to the Go tutorial. In a terminal enter:

cd
mkdir contact
cd contact
go mod init example/contact

The main function

In your text editor, create a file contact.go in which to write your code. Paste the following code into your contact.go file.

package main

import (
    "context"
    "fmt"
    "io"
    "os"
    "time"

    "berty.tech/weshnet"
    "berty.tech/weshnet/pkg/protocoltypes"
    "github.com/mr-tron/base58"
  )

(See the first example app blog post for explanation.) To continue the example, paste the following main function.

func main() {

    ctx, cancel := context.WithCancel(context.Background())
    defer cancel()

    client1, err := weshnet.NewPersistentServiceClient("data1")
    if err != nil {
        panic(err)
    }
    defer client1.Close()

    // client1 shares contact with client2.
    binaryContact, err := client1.ShareContact(ctx,
        &protocoltypes.ShareContact_Request{})
    if err != nil {
        panic(err)
    }
    fmt.Println(base58.Encode(binaryContact.EncodedContact))

    // client1 receives the contact request from client2.
    request, err := receiveContactRequest(ctx, client1)
    if err != nil {
        panic(err)
    }
    if request == nil {
        fmt.Println("Error: Did not receive the contact request")
        return
    }

    // client1 accepts the contact request from client2.
    _, err = client1.ContactRequestAccept(ctx,
        &protocoltypes.ContactRequestAccept_Request{
            ContactPK: request.ContactPK,
        })
    if err != nil {
        panic(err)
    }

    // Activate the contact group.
    groupInfo, err := client1.GroupInfo(ctx, &protocoltypes.GroupInfo_Request{
        ContactPK: request.ContactPK,
    })
    if err != nil {
        panic(err)
    }
    _, err = client1.ActivateGroup(ctx, &protocoltypes.ActivateGroup_Request{
        GroupPK: groupInfo.Group.PublicKey,
    })
    if err != nil {
        panic(err)
    }

    // Receive a message from the group.
    message, err := receiveMessage(ctx, client1, groupInfo)
    if err != nil {
        panic(err)
    }
    if message == nil {
        fmt.Print("End of stream without receiving message")
        return
    }

    fmt.Println("client2:", string(message.Message))
}

This uses some helper functions which we will define below. As in the previous example, we call NewPersistentServiceClient("data1") to create a client with persistent storage on-disk. We name the folder “data1” because this is client1. It will communicate with client2 which we create below.

Next we call the Wesh API function ShareContact which is documented here. It returns an encoded byte array with the information that client2 needs to make a contact request. We use base58.Encode to make it a shareable string and print it to the console. (The Wesh API leaves it up to the application developer to decide how to encode the byte array. You may use base58, or make a QR code, or a URI, etc.) This string is used by client2, as we will see.

Let’s imagine that client2 has sent the contact request, so we call receiveContactRequest which we will define below. It returns request which has the account public key of client2, so we call ContactRequestAccept (docs) to accept the contact request and create the Contact group.

Now we need to activate this group. We use the same account public key of client2 to identify the Contact group and call GroupInfo (docs) to get the group’s public key, and then call ActivateGroup (docs) to activate it.

Finally, let’s imagine that client2 has sent a message to the group, so we call receiveMessage which we will define below. This returns the message (or nil if end of stream) which we print to the console.

Helper functions

That’s it for main! Now we need to define the helper functions receiveContactRequest and receiveMessage. These both follow the pattern of subscribing to an event stream and waiting for the desired event type. Paste the following function to the file contact.go.

func receiveContactRequest(ctx context.Context, client weshnet.ServiceClient) (*protocoltypes.AccountContactRequestIncomingReceived, error) {
    // Get the client's AccountGroupPK from the configuration.
    config, err := client.ServiceGetConfiguration(ctx, &protocoltypes.ServiceGetConfiguration_Request{})
    if err != nil {
        return nil, err
    }

    // Subscribe to metadata events. ("sub" means "subscription".)
    subCtx, subCancel := context.WithCancel(ctx)
    defer subCancel()
    subMetadata, err := client.GroupMetadataList(subCtx, &protocoltypes.GroupMetadataList_Request{
            GroupPK: config.AccountGroupPK,
        })
    if err != nil {
        return nil, err
    }

    for {
        metadata, err := subMetadata.Recv()
        if err == io.EOF || subMetadata.Context().Err() != nil {
            // Not received.
            return nil, nil
        }
        if err != nil {
            return nil, err
        }

        if metadata == nil || metadata.Metadata.EventType !=
                protocoltypes.EventTypeAccountContactRequestIncomingReceived {
            continue
        }

        request := &protocoltypes.AccountContactRequestIncomingReceived{}
        if err = request.Unmarshal(metadata.Event); err != nil {
            return nil, err
        }

        return request, nil
    }
}

This function takes the client1 which we created in main and calls ServiceGetConfiguration (docs). Instead of getting the configuration’s peer ID as in previous examples, we get the public key of client1’s Account group. This public key is also in the shared contact, and is used by client2 to send a contact request to client1. To receive it, we call *GroupMetadataList *(docs) with the Account group public key.

Most API functions return a data structure, but a few like GroupMetadataList return a subscription stream like subMetadata. We use a for loop and call subMetadata.Recv() which blocks until it receives an event (or end of stream). As you build more complex apps, an event loop like this may handle more event types and operations. For now, we just check that the event type is the one we’re waiting for, EventTypeAccountContactRequestIncomingReceived.

Now we can use Unmarshal to convert the metadata event to the specific AccountContactRequestIncomingReceived event. (Unmarshal is part of the Protobuf interface. For more details, see the docs). This is the contact request that we return from the function.

Now we need to define receiveMessage which waits for the message. Paste the following function to the file contact.go. (This one is shorter!)

func receiveMessage(ctx context.Context, client weshnet.ServiceClient, groupInfo *protocoltypes.GroupInfo_Reply) (*protocoltypes.GroupMessageEvent, error) {
    // Subscribe to message events.
    subCtx, subCancel := context.WithCancel(ctx)
    defer subCancel()
    subMessages, err := client.GroupMessageList(subCtx, &protocoltypes.GroupMessageList_Request{
        GroupPK: groupInfo.Group.PublicKey,
    })
    if err != nil {
        panic(err)
    }

    // client waits to receive the message.
    for {
        message, err := subMessages.Recv()
        if err == io.EOF {
            // Not received.
            return nil, nil
        }
        if err != nil {
            return nil, err
        }

        return message, nil
    }
}

Similar to the previous function, this function takes the client1 which we created in main. It also takes the groupInfo object of the Contact group. (The main function already used this to activate the group.)

As in the previous function, we want to subscribe to events. In the previous blog post, we briefly discussed the difference between the Metadata log and the Message log. A contact request is an event in the Metadata log, so receiveContactRequest called GroupMetadataList. But now we want to receive a “normal” message when it is added to the Message log.

We call the API method GroupMessageList (docs) which returns the subscription stream subMessages. We use a for loop and call subMetadata.Recv() which blocks until it receives an event (or end of stream). Finally, the function returns message which is a GroupMessageEvent so that the main function can print the message from client2.

Client 2

Wait a moment (you may be thinking). We don’t have the code where client2 sends the message. We will add it to this same file and you will run the app in two terminals. Remember that the code for client1 prints the contact string to the terminal. When we run the app for client2, we’ll add this string as a command-line parameter. At the very beginning of the main function, insert this code:

if len(os.Args) == 2 {
doClient2(os.Args[1])
return
}

Now we can define the function **doClient2** which is called if we run using the contact string. Paste the following function to the file **contact.go** and save it.

func doClient2(encodedContact string) {
    ctx, cancel := context.WithCancel(context.Background())
    defer cancel()

    client2, err := weshnet.NewPersistentServiceClient("data2")
    if err != nil {
        panic(err)
    }
    defer client2.Close()

    contactBinary, err := base58.Decode(encodedContact)
    if err != nil {
        panic(err)
    }
    contact, err := client2.DecodeContact(ctx,
        &protocoltypes.DecodeContact_Request{
            EncodedContact: contactBinary,
        })
    if err != nil {
        panic(err)
    }

    // Send the contact request.
    _, err = client2.ContactRequestSend(ctx,
        &protocoltypes.ContactRequestSend_Request{
            Contact: contact.Contact,
        })
    if err != nil {
        panic(err)
    }

    // Activate the contact group.
    groupInfo, err := client2.GroupInfo(ctx, &protocoltypes.GroupInfo_Request{
        ContactPK: contact.Contact.PK,
    })
    if err != nil {
        panic(err)
    }
    _, err = client2.ActivateGroup(ctx, &protocoltypes.ActivateGroup_Request{
        GroupPK: groupInfo.Group.PublicKey,
    })
    if err != nil {
        panic(err)
    }

    // Send a message to the contact group.
    _, err = client2.AppMessageSend(ctx, &protocoltypes.AppMessageSend_Request{
        GroupPK: groupInfo.Group.PublicKey,
        Payload: []byte("Hello"),
    })
    if err != nil {
        panic(err)
    }

    fmt.Println("Sending message...")
    time.Sleep(time.Second * 5)
}

This function takes the encodedContact from the command line. It runs as a separate process, so we need to use NewPersistentServiceClient to create a separate client2 with persistent data stored in a separate folder, “data2”.

Next we use base58.Decode to recover the encoded byte array with client1’s contact info, and use DecodeContact (docs) to extract the contact info. Now client2 can call ContactRequestSend (docs) to send this to client1 as a contact request. You may be thinking, “client1 just sent this info to client2, so why does client2 need to send it back?” This is part of the secure handshake. client2 needs to make sure that the shared contact really came from client1, and needs to decide if creating a contact is actually desired.

Similar to the code above, client2 needs to activate the Contact group using GroupInfo **and **ActivateGroup. (In this case, client2 has client1’s account public key from the shared contact in contact.Contact.PK.)

We’re almost done! Client2 calls AppMessageSend (docs) to use the Contact group public key to send a “Hello” message to the Contact group. (For generality, a message is any byte array. In this case we simply store the message string in it.) For efficiency, the AppMessageSend function queues the message to be sent and returns immediately. If we exit the application too soon, then the Wesh services won’t have time to actually send the message. Therefore, we sleep this function for 5 seconds so that the service threads can complete.

Run the app

That’s all the code! It’s time to run the app. In a terminal enter:

go mod tidy
go run .

(You only need to do go mod tidy the first time.) It should print the contact string from client1, something like 2KqzJQpZ2Y7EDaep6CnceT6ozqy1Ss6qJV8tsN59QSBejfa4TiYjMr8Z9PjHr1D2bYa4EozWudwaWMwB5jXqb5gRLj2bX. Copy this to the clipboard.

Leave this app running. Now, in a separate terminal we run as client2. cd to the same directory and enter:

go run . <contact-string>

where is the contact string from client1. It should print Sending message.... Now look at the terminal for client1. It should print client2: Hello.

You have established Wesh communication! You can use this example app as a basis for more sophisticated Wesh apps. Overall, this simply creates a Contact group and calls AppMessageSend. But you may understand that Wesh communicates differently than using a traditional network connection. How does the message actually get from client2 to client1? In the next blog post, we’ll do a theory dive into how Wesh’s asynchronous communication works.

Wesh App with Persistent Storage

Berty Technologies — Fri, 01 Sep 2023 13:03:18 +0000

In the previous blog post, we made an example “Hello world” app using the Wesh API. But it used in-memory storage for the keys and messages, which are lost when the app closes. It's possible to export the data to a file before closing, and re-import it when the in-memory app stars again. But in this blog post we will make an example app to use a persistent storage on disk. We'll also use this to explain some details of what is in the key store and libp2p node.

As before, we write an app similar to the Go tutorial. In a terminal enter:

cd
mkdir persistent
cd persistent
go mod init example/persistent

As in the previous blog post, paste the following code into your persistent.go file.

package main

import (
    "context"
    "fmt"

    "berty.tech/weshnet"
    "berty.tech/weshnet/pkg/protocoltypes"
)

(See the previous blog post for explanation.) To complete the example, paste the following main function and save the file.

func main() {
    ctx, cancel := context.WithCancel(context.Background())
    defer cancel()

    path := "data"
        client, err := weshnet.NewPersistentServiceClient(path)
    if err != nil {
        panic(err)
    }
    defer client.Close()

    config, err := client.ServiceGetConfiguration(ctx,
            &protocoltypes.ServiceGetConfiguration_Request{})
    if err != nil {
        panic(err)
    }

    fmt.Println("Hello, world! My peer ID is", config.PeerID)
}

This is similar to the previous example, except that we change NewInMemoryServiceClient() to NewPersistentServiceClient(path) , where path is the directory for the persistent storage. When we run for the first time, Wesh will create the directory and the storage files for a new peer identity. To run, in a terminal enter:

go mod tidy
go run .

(You only need to do go mod tidy the first time.) It should print something like “Hello, world! My peer ID is 12D3KooWJeVb4rbDisCgmUQQxtzNRikgcQxXzSodoy2AyNCdTEWr” . Now, enter the run command again:

go run .

This time, NewPersistentServiceClient(path) uses the storage files that we created the first time. It should print exactly the same peer ID, meaning that the same identity is persistent on disk. To see the storage files, enter:

ls data

You should see something like:

000000.vlog 000002.sst  MANIFEST    config      datastore_spec  repo.lock
000001.sst  KEYREGISTRY blocks      datastore   keystore          version

Much of the content of these files is encrypted. They are only meant to be accessed through the Wesh API. We aren't going to look at all of these files or describe their format, but seeing them gives us a chance to discuss the basic types of information in Wesh.

The most important to discuss are the three types of information associated with your identity:

The libp2p host Peer ID is what the example prints. It identifies your computer as a node in libp2p communication.
The Account key pair holds the primary identity that you use to connect to other Wesh users and to join a group.
A Device key pair is created on each computer or mobile device where you use Wesh, and is connected cryptographically to your Account key pair.

In Wesh, communication is based on the “group” where messages are secure between group members. For each new group, the Wesh service generates a Metadata log (with info like members joining), a Message log (which we'll explore in a future blog post), and cryptographic secrets (your own secrets and secrets received from other group members). There are three types of groups:

Your Account group stores all the secrets and metadata of your account and allows the devices linked to it to sync with each other, as explained above. So, when the example first calls NewPersistentServiceClient, Wesh creates one Account key pair, one Device key pair for your computer, and the Account group for it.
When you add another Wesh user as a contact, you are both in a Contact group where just the two of you can communicate securely. No other users can join this group.
Finally, you can create or join a Multi-member group. This is what people normally think of when they hear about Wesh, but it's useful to mention the other types of groups and their purpose.

Among other maintenance files, the persistent storage has a Network config file with info on how libp2p makes connections. And there is a block store which is part of the peer-to-peer network and stores information you have received or may be useful to other users that your device connects to.

That's enough for now! For more details, see the links in the text above. Now that we see how to create an account, in the next blog post we'll look at how to use Wesh to add a contact and send a message.

Wesh “Hello World” App

Berty Technologies — Mon, 28 Aug 2023 15:56:10 +0000

Now that you have been introduced to Wesh in the previous blog post, it’s time to explore the code. We will write a “Hello World” app, similar to the Go tutorial which you can read to set up Go on your computer and for other details. (This has been tested with Go 1.19 on macOS and Ubuntu.) This example app will connect to the Wesh service and call a function. When finished, you will be confident that you can use Wesh on your platform.

Similar to the Go tutorial, in a terminal enter:

cd
mkdir hello
cd hello
go mod init example/hello

In your text editor, create a file hello.go in which to write your code. Paste the following code into your hello.go file.

package main

import (
    "context"
    "fmt"

    "berty.tech/weshnet"
    "berty.tech/weshnet/pkg/protocoltypes"
)

We import fmt as usual in Go code so that we can print a message. We import berty.tech/weshnet so that we can call the Go function to initialize the Wesh service (explained below). Finally, your app interacts with the Wesh service through gRPC which uses Protobuf messages. Therefore, we import the Wesh API Protobuf types with berty.tech/weshnet/pkg/protocoltypes, and we import context because all of the gRPC calls use a Go context object (explained below).

To complete the example, paste the following main function and save the file.

func main() {
    ctx, cancel := context.WithCancel(context.Background())
    defer cancel()

    client, err := weshnet.NewInMemoryServiceClient()
    if err != nil {
        panic(err)
    }
    defer client.Close()

    config, err := client.ServiceGetConfiguration(ctx,
            &protocoltypes.ServiceGetConfiguration_Request{})
    if err != nil {
        panic(err)
    }

    fmt.Println("Hello, world! My peer ID is", config.PeerID)
}

First we use context.WithCancel to create a ctx object which is used in the gRPC calls, and a cancel function to call when the app exits. The Context type is part of the Go standard library and you can read its documentation for more details.

Next we call weshnet.NewInMemoryServiceClient to initialize the Wesh service and create a gRPC client that we use to interact with it. Wesh has many init functions for different configurations. A Wesh service can run in memory with a direct connection, or as a separate process with communication through an open socket. We will discuss these options in future blog posts. In this example, we initialize a Wesh service which runs in application memory with a direct connection, and creates a new in-memory user account and data store. If your app doesn’t export the data, then it is lost when the app exits. (It’s also possible to create a persistent data store, which we will explore later.)

Finally, we interact with the Wesh service by calling client.ServiceGetConfiguration , passing the ctx that we created. This method gets the current configuration of the service and is documented here, along with all the other API calls. Each API call takes a Protobuf request message. In this case there are no parameters, so we create an empty protocoltypes.ServiceGetConfiguration_Request. (We will see more complex examples later.) And each API call returns a Protobuf reply message, or sometimes a stream object. In this case it is a ServiceGetConfiguration.Reply. So to finish, we print a happy message with the PeerID of the in-memory IPFS node.

To see the result, in a terminal enter:

go mod tidy
go run .

(You only need to do go mod tidy the first time.) It should print something like “Hello, world! My peer ID is 12D3KooWGVMm5mum6qMtwbReiD9Aa93WTuTT2hTHsYxQASTzYUfs”.

In this example, you can now see how the Wesh API can be used with other programming languages. The gRPC support provides helper functions for each language to create the Protobuf messages like ServiceGetConfiguration_Request. And the API calls like ServiceGetConfiguration only need these Protobuf messages which are language-independent.

Congratulations on your first Wesh app! This one kept all the data in memory. In the next blog post, we’ll see how to create a persistent key store and IPFS node (and talk more about what these are).

Introducing the Wesh Network Toolkit

Berty Technologies — Fri, 25 Aug 2023 13:34:21 +0000

Welcome to Wesh!

If you have an Internet connection, then there are many tools to communicate with others. But if you’re off grid or the Internet is down, then those tools can’t help you. To solve this and other problems, in 2018 Berty Technologies created a protocol to let you create an identity, join a group and exchange messages all without needing an Internet connection or a central service provider.

Thanks to strong encryption, you control your own identity without needing permission. You can set up or participate in ad-hoc groups while preserving privacy. And data is encrypted as it moves between users through an untrusted environment, whether device-to-device or over the Internet when available.

This protocol powers Berty Messenger which brings these features to mobile phone users. But the need for reliable, privacy-based off-grid communication goes beyond a messaging app. That’s why we’re introducing the open-source Wesh Network Toolkit so you can take advantage of the Wesh protocol in your own application.

How will you use Wesh?

For maximum flexibility, your application interfaces to Wesh based on gRPC, a well-supported framework which sends and receives Google Protobuf messages.
Even though the core Wesh code is written in Go, gRPC messages are language-independent. So, Wesh works with your existing application written in Go, Python, Java, C++ or other supported languages.
gRPC works with the Buf schema registry where we publish the Wesh API. For example, this documents the request and reply to retrieve information about a group.
gRPC allows different calling interfaces. The messages can be sent as if Wesh is a library linked directly to your application. Or if your application environment requires it, then API messages can be sent over TCP to a Wesh toolkit running on a local or remote server.

The “Wesh” name

You may be wondering what “Wesh” means. It’s a variant of “mesh” to highlight its asynchronous mesh communication which can use any device to securely store a message for a disconnected group member and deliver it when they connect again. (”Wesh” is also slang for “hi” in the French hip hop scene.)
What’s next?
This was a short and sweet introduction to Wesh. In future posts, we’ll dive into how Wesh is organized by users and groups, how to get started with the code, some example applications and more. Stay tuned!

Links
https://wesh.network The main Wesh Network Toolkit web page
https://github.com/berty/weshnet The Wesh GitHub repo for code and issues
https://berty.tech/docs/protocol The Wesh protocol white paper
https://buf.build/berty/weshnet The Wesh API at the Buf schema registry
https://berty.tech/about About Berty Technologies, the NGO working with the open-source community to make all this real