berty/weshnet

Async Mesh Network Protocol for Extreme Communication -- Innovative, Resilient, and Decentralized

Wesh Network Toolkit

The Wesh network toolkit lets your application use the Wesh protocol to support privacy-based, off-grid, peer-to-peer communication. Wesh powers Berty Messenger, and now you can use the Wesh network toolkit directly.

Your application interfaces to Wesh based on gRPC. So even though the core Wesh code is written in Go, Wesh works with your application written in Go, Python or other languages supported by gRPC.

For details, see the Wesh website at https://wesh.network . The website includes blog tutorials which introduce you to Wesh and walk you through some example applications and background of the Wesh protocol.

Usage

import "berty.tech/weshnet"

Online API documentation is at https://buf.build/berty/weshnet .

Get the code

To get the code and build, see the file INSTALL.md.

Feedback

For bug reports, feature requests or questions, please open a GitHub issue.

weshnet's Issues

Problem compiling as a shared-library on macOS

Is there an existing issue for this?

• I have searched the existing issues

Package version

1.14.0

OS

macOS

Language version and compiler version

go.1.20.8

Bug description

I want to build the weshnet as a shared library so that I can call it from NodeJS.

To do so I create a wrapper file wrapper/wrapper.go

package main

import (
	"C"
	"berty.tech/weshnet"
)

//export NewPersistentServiceClient
func NewPersistentServiceClient() {
	weshnet.NewPersistentServiceClient("data1")
}
func main() {} // Required for c-shared build mode

Then I try to build the package with

go1.20.8 build -o libweshnet.so -buildmode=c-shared wrapper/wrapper.go

it compiles but output warnings

# command-line-arguments
ld: warning: -bind_at_load is deprecated on macOS
ld: warning: ignoring duplicate libraries: '-lobjc'
ld: warning: '/private/var/folders/_9/zt66nrqx6rg37b3mvyxflk740000gn/T/go-link-1036805785/go.o' has malformed LC_DYSYMTAB, expected 140 undefined symbols to start at index 169421, found 237 undefined symbols starting at index 133

When I try to call the function from NodeJS

import ffi from 'ffi-napi';
import ref from 'ref-napi';

const libweshnet = ffi.Library('libweshnet.so.dylib', {
    'NewPersistentServiceClient': ['void', ['string']],
});

libweshnet.NewPersistentServiceClient("data1");

Stanislaws-MacBook-Pro:app stanbar$ yarn start
yarn run v1.22.19
$ npx ts-node ./src/main.ts
unexpected fault address 0x2407ef5512a0
fatal error: fault
[signal SIGSEGV: segmentation violation code=0x2 addr=0x2407ef5512a0 pc=0x1664a551c]

goroutine 17 [running, locked to thread]:
runtime.throw({0x1667604ed?, 0x0?})
        /Users/stanbar/sdk/go1.19.13/src/runtime/panic.go:1047 +0x40 fp=0x1400009eba0 sp=0x1400009eb70 pc=0x165161520
runtime.sigpanic()
        /Users/stanbar/sdk/go1.19.13/src/runtime/signal_unix.go:846 +0x1a0 fp=0x1400009ebd0 sp=0x1400009eba0 pc=0x1651795d0
path/filepath.Split(...)
        /Users/stanbar/sdk/go1.19.13/src/path/filepath/path.go:212
berty.tech/weshnet/pkg/ipfsutil.LoadRepoFromPath({0x11b84ee48?, 0x0?})
        /Users/stanbar/sandbox/weshnet/pkg/ipfsutil/repo.go:62 +0x2c fp=0x1400009ec30 sp=0x1400009ebe0 pc=0x1664a551c
berty.tech/weshnet.NewPersistentServiceClient({0x11b84ee48, 0x2406d3d02459})
        /Users/stanbar/sandbox/weshnet/service_client.go:91 +0x48 fp=0x1400009ede0 sp=0x1400009ec30 pc=0x166595a78
main.NewPersistentServiceClient(...)
        /Users/stanbar/sandbox/weshnet/wrapper/wrapper.go:10
_cgoexp_a96eb3496c92_NewPersistentServiceClient(0x1673dc3e8?)
        _cgo_gotypes.go:40 +0x28 fp=0x1400009ee00 sp=0x1400009ede0 pc=0x1665c2638
runtime.cgocallbackg1(0x1665c2610, 0x0?, 0x0)
        /Users/stanbar/sdk/go1.19.13/src/runtime/cgocall.go:316 +0x244 fp=0x1400009eef0 sp=0x1400009ee00 pc=0x165129c74
runtime.cgocallbackg(0x0?, 0x0?, 0x0?)
        /Users/stanbar/sdk/go1.19.13/src/runtime/cgocall.go:235 +0xd8 fp=0x1400009ef80 sp=0x1400009eef0 pc=0x1651299a8
runtime.cgocallbackg(0x1665c2610, 0x16da530c0, 0x0)
        <autogenerated>:1 +0x1c fp=0x1400009efb0 sp=0x1400009ef80 pc=0x165196a9c
runtime.cgocallback(0x0, 0x0, 0x0)
        /Users/stanbar/sdk/go1.19.13/src/runtime/asm_arm64.s:1094 +0xa0 fp=0x1400009efe0 sp=0x1400009efb0 pc=0x165195220
runtime.goexit()
        /Users/stanbar/sdk/go1.19.13/src/runtime/asm_arm64.s:1172 +0x4 fp=0x1400009efe0 sp=0x1400009efe0 pc=0x1651952f4

goroutine 2 [force gc (idle)]:
runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
        /Users/stanbar/sdk/go1.19.13/src/runtime/proc.go:363 +0xe4 fp=0x1400008cfa0 sp=0x1400008cf80 pc=0x165164124
runtime.goparkunlock(...)
        /Users/stanbar/sdk/go1.19.13/src/runtime/proc.go:369
runtime.forcegchelper()
        /Users/stanbar/sdk/go1.19.13/src/runtime/proc.go:302 +0xb4 fp=0x1400008cfd0 sp=0x1400008cfa0 pc=0x165163fb4
runtime.goexit()
        /Users/stanbar/sdk/go1.19.13/src/runtime/asm_arm64.s:1172 +0x4 fp=0x1400008cfd0 sp=0x1400008cfd0 pc=0x1651952f4
created by runtime.init.6
        /Users/stanbar/sdk/go1.19.13/src/runtime/proc.go:290 +0x24

goroutine 18 [GC sweep wait]:
runtime.gopark(0x1?, 0x0?, 0x0?, 0x0?, 0x0?)
        /Users/stanbar/sdk/go1.19.13/src/runtime/proc.go:363 +0xe4 fp=0x14000088770 sp=0x14000088750 pc=0x165164124
runtime.goparkunlock(...)
        /Users/stanbar/sdk/go1.19.13/src/runtime/proc.go:369
runtime.bgsweep(0x0?)
        /Users/stanbar/sdk/go1.19.13/src/runtime/mgcsweep.go:297 +0x10c fp=0x140000887b0 sp=0x14000088770 pc=0x16514d62c
runtime.gcenable.func1()
        /Users/stanbar/sdk/go1.19.13/src/runtime/mgc.go:178 +0x28 fp=0x140000887d0 sp=0x140000887b0 pc=0x1651418d8
runtime.goexit()
        /Users/stanbar/sdk/go1.19.13/src/runtime/asm_arm64.s:1172 +0x4 fp=0x140000887d0 sp=0x140000887d0 pc=0x1651952f4
created by runtime.gcenable
        /Users/stanbar/sdk/go1.19.13/src/runtime/mgc.go:178 +0x70

goroutine 19 [GC scavenge wait]:
runtime.gopark(0x1400010e000?, 0x166e180a8?, 0x0?, 0x0?, 0x0?)
        /Users/stanbar/sdk/go1.19.13/src/runtime/proc.go:363 +0xe4 fp=0x14000088f50 sp=0x14000088f30 pc=0x165164124
runtime.goparkunlock(...)
        /Users/stanbar/sdk/go1.19.13/src/runtime/proc.go:369
runtime.(*scavengerState).park(0x1686e8b60)
        /Users/stanbar/sdk/go1.19.13/src/runtime/mgcscavenge.go:389 +0x5c fp=0x14000088f80 sp=0x14000088f50 pc=0x16514b4ac
runtime.bgscavenge(0x0?)
        /Users/stanbar/sdk/go1.19.13/src/runtime/mgcscavenge.go:622 +0xac fp=0x14000088fb0 sp=0x14000088f80 pc=0x16514bacc
runtime.gcenable.func2()
        /Users/stanbar/sdk/go1.19.13/src/runtime/mgc.go:179 +0x28 fp=0x14000088fd0 sp=0x14000088fb0 pc=0x165141878
runtime.goexit()
        /Users/stanbar/sdk/go1.19.13/src/runtime/asm_arm64.s:1172 +0x4 fp=0x14000088fd0 sp=0x14000088fd0 pc=0x1651952f4
created by runtime.gcenable
        /Users/stanbar/sdk/go1.19.13/src/runtime/mgc.go:179 +0xb4

goroutine 34 [finalizer wait]:
runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
        /Users/stanbar/sdk/go1.19.13/src/runtime/proc.go:363 +0xe4 fp=0x140001b6580 sp=0x140001b6560 pc=0x165164124
runtime.goparkunlock(...)
        /Users/stanbar/sdk/go1.19.13/src/runtime/proc.go:369
runtime.runfinq()
        /Users/stanbar/sdk/go1.19.13/src/runtime/mfinal.go:180 +0x128 fp=0x140001b67d0 sp=0x140001b6580 pc=0x165140af8
runtime.goexit()
        /Users/stanbar/sdk/go1.19.13/src/runtime/asm_arm64.s:1172 +0x4 fp=0x140001b67d0 sp=0x140001b67d0 pc=0x1651952f4
created by runtime.createfing
        /Users/stanbar/sdk/go1.19.13/src/runtime/mfinal.go:157 +0x94

goroutine 35 [select]:
runtime.gopark(0x140001b6f80?, 0x2?, 0x0?, 0x0?, 0x140001b6f14?)
        /Users/stanbar/sdk/go1.19.13/src/runtime/proc.go:363 +0xe4 fp=0x140001b6d90 sp=0x140001b6d70 pc=0x165164124
runtime.selectgo(0x140001b6f80, 0x140001b6f10, 0x0?, 0x0, 0x0?, 0x1)
        /Users/stanbar/sdk/go1.19.13/src/runtime/select.go:328 +0x6b4 fp=0x140001b6ea0 sp=0x140001b6d90 pc=0x165175414
github.com/ipfs/go-log/writer.(*MirrorWriter).logRoutine(0x140003cc6f0)
        /Users/stanbar/go/pkg/mod/github.com/ipfs/[email protected]/writer/writer.go:71 +0xb4 fp=0x140001b6fb0 sp=0x140001b6ea0 pc=0x165655f24
github.com/ipfs/go-log/writer.NewMirrorWriter.func1()
        /Users/stanbar/go/pkg/mod/github.com/ipfs/[email protected]/writer/writer.go:36 +0x28 fp=0x140001b6fd0 sp=0x140001b6fb0 pc=0x165655ca8
runtime.goexit()
        /Users/stanbar/sdk/go1.19.13/src/runtime/asm_arm64.s:1172 +0x4 fp=0x140001b6fd0 sp=0x140001b6fd0 pc=0x1651952f4
created by github.com/ipfs/go-log/writer.NewMirrorWriter
        /Users/stanbar/go/pkg/mod/github.com/ipfs/[email protected]/writer/writer.go:36 +0xd0

goroutine 20 [GC worker (idle)]:
runtime.gopark(0x140001b0840?, 0x14000185ba0?, 0x98?, 0x77?, 0x1657a6578?)
        /Users/stanbar/sdk/go1.19.13/src/runtime/proc.go:363 +0xe4 fp=0x140001b7740 sp=0x140001b7720 pc=0x165164124
runtime.gcBgMarkWorker()
        /Users/stanbar/sdk/go1.19.13/src/runtime/mgc.go:1235 +0xec fp=0x140001b77d0 sp=0x140001b7740 pc=0x165143d5c
runtime.goexit()
        /Users/stanbar/sdk/go1.19.13/src/runtime/asm_arm64.s:1172 +0x4 fp=0x140001b77d0 sp=0x140001b77d0 pc=0x1651952f4
created by runtime.gcBgMarkStartWorkers
        /Users/stanbar/sdk/go1.19.13/src/runtime/mgc.go:1159 +0x28

goroutine 50 [GC worker (idle)]:
runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
        /Users/stanbar/sdk/go1.19.13/src/runtime/proc.go:363 +0xe4 fp=0x140001b2740 sp=0x140001b2720 pc=0x165164124
runtime.gcBgMarkWorker()
        /Users/stanbar/sdk/go1.19.13/src/runtime/mgc.go:1235 +0xec fp=0x140001b27d0 sp=0x140001b2740 pc=0x165143d5c
runtime.goexit()
        /Users/stanbar/sdk/go1.19.13/src/runtime/asm_arm64.s:1172 +0x4 fp=0x140001b27d0 sp=0x140001b27d0 pc=0x1651952f4
created by runtime.gcBgMarkStartWorkers
        /Users/stanbar/sdk/go1.19.13/src/runtime/mgc.go:1159 +0x28

goroutine 38 [GC worker (idle)]:
runtime.gopark(0x3a9851c75b172?, 0x3?, 0x64?, 0x89?, 0x0?)
        /Users/stanbar/sdk/go1.19.13/src/runtime/proc.go:363 +0xe4 fp=0x140001b7f40 sp=0x140001b7f20 pc=0x165164124
runtime.gcBgMarkWorker()
        /Users/stanbar/sdk/go1.19.13/src/runtime/mgc.go:1235 +0xec fp=0x140001b7fd0 sp=0x140001b7f40 pc=0x165143d5c
runtime.goexit()
        /Users/stanbar/sdk/go1.19.13/src/runtime/asm_arm64.s:1172 +0x4 fp=0x140001b7fd0 sp=0x140001b7fd0 pc=0x1651952f4
created by runtime.gcBgMarkStartWorkers
        /Users/stanbar/sdk/go1.19.13/src/runtime/mgc.go:1159 +0x28

goroutine 21 [GC worker (idle)]:
runtime.gopark(0x3a9851c75d882?, 0x2?, 0x20?, 0x50?, 0x1400010e000?)
        /Users/stanbar/sdk/go1.19.13/src/runtime/proc.go:363 +0xe4 fp=0x1400008c740 sp=0x1400008c720 pc=0x165164124
runtime.gcBgMarkWorker()
        /Users/stanbar/sdk/go1.19.13/src/runtime/mgc.go:1235 +0xec fp=0x1400008c7d0 sp=0x1400008c740 pc=0x165143d5c
runtime.goexit()
        /Users/stanbar/sdk/go1.19.13/src/runtime/asm_arm64.s:1172 +0x4 fp=0x1400008c7d0 sp=0x1400008c7d0 pc=0x1651952f4
created by runtime.gcBgMarkStartWorkers
        /Users/stanbar/sdk/go1.19.13/src/runtime/mgc.go:1159 +0x28

goroutine 51 [GC worker (idle)]:
runtime.gopark(0x1687225c0?, 0x3?, 0x4d?, 0x71?, 0x0?)
        /Users/stanbar/sdk/go1.19.13/src/runtime/proc.go:363 +0xe4 fp=0x140001b2f40 sp=0x140001b2f20 pc=0x165164124
runtime.gcBgMarkWorker()
        /Users/stanbar/sdk/go1.19.13/src/runtime/mgc.go:1235 +0xec fp=0x140001b2fd0 sp=0x140001b2f40 pc=0x165143d5c
runtime.goexit()
        /Users/stanbar/sdk/go1.19.13/src/runtime/asm_arm64.s:1172 +0x4 fp=0x140001b2fd0 sp=0x140001b2fd0 pc=0x1651952f4
created by runtime.gcBgMarkStartWorkers
        /Users/stanbar/sdk/go1.19.13/src/runtime/mgc.go:1159 +0x28

goroutine 39 [GC worker (idle)]:
runtime.gopark(0x3a9851c75f9b6?, 0x0?, 0x0?, 0x0?, 0x0?)
        /Users/stanbar/sdk/go1.19.13/src/runtime/proc.go:363 +0xe4 fp=0x140001b8740 sp=0x140001b8720 pc=0x165164124
runtime.gcBgMarkWorker()
        /Users/stanbar/sdk/go1.19.13/src/runtime/mgc.go:1235 +0xec fp=0x140001b87d0 sp=0x140001b8740 pc=0x165143d5c
runtime.goexit()
        /Users/stanbar/sdk/go1.19.13/src/runtime/asm_arm64.s:1172 +0x4 fp=0x140001b87d0 sp=0x140001b87d0 pc=0x1651952f4
created by runtime.gcBgMarkStartWorkers
        /Users/stanbar/sdk/go1.19.13/src/runtime/mgc.go:1159 +0x28

goroutine 22 [GC worker (idle)]:
runtime.gopark(0x3a9851c75af01?, 0x0?, 0x0?, 0x0?, 0x0?)
        /Users/stanbar/sdk/go1.19.13/src/runtime/proc.go:363 +0xe4 fp=0x14000089740 sp=0x14000089720 pc=0x165164124
runtime.gcBgMarkWorker()
        /Users/stanbar/sdk/go1.19.13/src/runtime/mgc.go:1235 +0xec fp=0x140000897d0 sp=0x14000089740 pc=0x165143d5c
runtime.goexit()
        /Users/stanbar/sdk/go1.19.13/src/runtime/asm_arm64.s:1172 +0x4 fp=0x140000897d0 sp=0x140000897d0 pc=0x1651952f4
created by runtime.gcBgMarkStartWorkers
        /Users/stanbar/sdk/go1.19.13/src/runtime/mgc.go:1159 +0x28

goroutine 52 [GC worker (idle)]:
runtime.gopark(0x1687225c0?, 0x1?, 0xd6?, 0xcf?, 0x0?)
        /Users/stanbar/sdk/go1.19.13/src/runtime/proc.go:363 +0xe4 fp=0x140001b3740 sp=0x140001b3720 pc=0x165164124
runtime.gcBgMarkWorker()
        /Users/stanbar/sdk/go1.19.13/src/runtime/mgc.go:1235 +0xec fp=0x140001b37d0 sp=0x140001b3740 pc=0x165143d5c
runtime.goexit()
        /Users/stanbar/sdk/go1.19.13/src/runtime/asm_arm64.s:1172 +0x4 fp=0x140001b37d0 sp=0x140001b37d0 pc=0x1651952f4
created by runtime.gcBgMarkStartWorkers
        /Users/stanbar/sdk/go1.19.13/src/runtime/mgc.go:1159 +0x28

goroutine 23 [select]:
runtime.gopark(0x1400009bf78?, 0x3?, 0xc6?, 0xa5?, 0x1400009bf62?)
        /Users/stanbar/sdk/go1.19.13/src/runtime/proc.go:363 +0xe4 fp=0x1400009be10 sp=0x1400009bdf0 pc=0x165164124
runtime.selectgo(0x1400009bf78, 0x1400009bf5c, 0x1400004e380?, 0x0, 0x0?, 0x1)
        /Users/stanbar/sdk/go1.19.13/src/runtime/select.go:328 +0x6b4 fp=0x1400009bf20 sp=0x1400009be10 pc=0x165175414
go.opencensus.io/stats/view.(*worker).start(0x1400004e380)
        /Users/stanbar/go/pkg/mod/[email protected]/stats/view/worker.go:292 +0x88 fp=0x1400009bfb0 sp=0x1400009bf20 pc=0x165be1248
go.opencensus.io/stats/view.init.0.func1()
        /Users/stanbar/go/pkg/mod/[email protected]/stats/view/worker.go:34 +0x28 fp=0x1400009bfd0 sp=0x1400009bfb0 pc=0x165be03e8
runtime.goexit()
        /Users/stanbar/sdk/go1.19.13/src/runtime/asm_arm64.s:1172 +0x4 fp=0x1400009bfd0 sp=0x1400009bfd0 pc=0x1651952f4
created by go.opencensus.io/stats/view.init.0
        /Users/stanbar/go/pkg/mod/[email protected]/stats/view/worker.go:34 +0xa4

Current behavior

As described above

Expected behavior

The problem is with macOS (probably only on Apple M1 Pro). The same procedure on Linux machine (x86_64) produces a shared library without any warnings/errors. And invokes the function from NodeJS without any errors.

Environment

macOS 13.5.1 (Apple M1 Pro)

Other

No response

Blockchain network on top of Weshnet?

Asking a question, not reporting a bug

• This question is not about a bug

Is there an existing issue for this?

• I have searched the existing issues

Question

Hello,
I'm building a p2p voting system and found Weshnet to ideally match my network assumptions.
However, in our voting protocol, we have to assume that some nodes are malicious and want to manipulate the voting results. As a result, we need some byzantine fault-tolerant consensus mechanisms (ideally something like blockchain).

You mentioned why you don't need Blockchain for Berty app. But for the voting protocol, it's essential to determine the order of the messages, AFAIK Conflict-Free Replicated Data (https://berty.tech/docs/protocol/#conflict-free-replicated-data-type) won't help with byzantine nodes.

We need to achieve a consensus on the order of messages over participants of a group.
Something like PBFT/Tendermint/Stellar Consensus Protocol (FBA) would work best. Can you suggest me some approach? Or maybe someone else tried to do that?

Context

The context has been described in the field above.

post-quantum crytography

Is there an existing issue for this?

• I have searched the existing issues

Feature request

I propose adding post-quantum cryptography (PQC) to the project as a security enhancement against potential quantum attacks in the future. PQC refers to encryption algorithms that are resistant to attacks from quantum computers, which have the potential to break traditional cryptographic algorithms, including the widely used public-key cryptography. By incorporating PQC into the project, we can ensure that the system remains secure even in the face of rapidly evolving quantum technologies and mitigate the risk of potential attacks, such as the "harvest now, decrypt later" vulnerability that quantum computers could exploit.

Context

This change is important as it addresses the potential security risks posed by quantum computers to the project and the sensitive data it may handle. With the advancement of quantum technologies, traditional cryptographic algorithms could become vulnerable, and it is crucial to proactively protect against future quantum attacks. By adding PQC to the project, we can enhance the security of the system and safeguard the confidentiality, integrity, and authenticity of the data. Moreover, this implementation can benefit other users of the project by providing them with a more secure and quantum-resistant solution, ensuring the longevity of the system's security.

Possible implementation

No response

IP address leakage

Asking a question, not reporting a bug

• This question is not about a bug

Is there an existing issue for this?

• I have searched the existing issues

Question

You mention on you faq that you were working on adding to the protocol the use of a mix network system (like I2P or Tor) to mitigate IP address leakage.

How is this work going?

(also, - i'm no expert! - but since you have not talked about tracking thru MAC address - in some way - i suppose that is not a problem in wesh...)

Context

It's a general question about the design

Message not received - context deadline exceeded

Is there an existing issue for this?

• I have searched the existing issues

Package version

latest

OS

None

Language version and compiler version

go

Bug description

(Posted on behalf of @sakul-budhathoki .)
We have experience few issues on the weshnet; it works perfectly fine at some time; at other time friend request, messages doesn't goes to other side.

@D4ryl00

Current behavior

Sometimes messages aren't received. See the attached wesh-message.txt .
Log message:

context deadline exceeded

Expected behavior

All messages should be received.

Environment

macOS

Other

No response

Use Wesh on React Native

Is there an existing issue for this?

• I have searched the existing issues

Feature request

As a business developer, I'd like to have some examples of how could I build a P2P messaging app using React Native Expo app and Wesh.

Context

• P2P Messaging apps for business are interesting for some companies regarding the minimal setup required.
• React Native is a widely used framework for developing hybrid application solutions.
• Expo is a framework on top of React Native that simplifies the development process and facilitates the integration of external libraries.

Possible implementation

• Create a simple POC of how to expose Wesh as an expo module.
• Create a basic tutorial explaining how it works.

allow friends to relay encrypted messages between mutuals

Is there an existing issue for this?

• I have searched the existing issues

Feature request

Alice, Tom and Bob are friends. Alice wants to send a message to Bob but internet is not available. She meets with tom, who is also friends with bob.

Berty transfers an encrypted copy of Alice's message onto toms phone.

Later, tom meets bob, and Alice's message is transferred from tom's phone to bobs.

Context

While BLE does allow for localised transmission of messages from one person to another, it doesn't enable long-distance transmission in an internet-less environment.

Allowing users to store messages and relay them could dramatically increase range in internet-less environments

Possible implementation

No response

Tracking issue: Ubuntu 22.04 compiler error for sqlite3

Building weshnet on Ubuntu 22.04 gives the compiler error shown below. This is a known issue introduced in a recent version of sqlite3. The issue says that it is fixed in version 3.38.0. On my Ubuntu 22.04, apt list libsqlite3-dev shows version 3.37.2. So, I think we just have to wait for apt to use the newer version.

# github.com/mutecomm/go-sqlcipher/v4
In file included from /usr/include/string.h:535,
                 from sqlite3.c:14180:
In function ‘memcpy’,
    inlined from ‘sqlite3Fts5IndexQuery’ at sqlite3.c:226667:18:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:29:10: warning: ‘__builtin_memcpy’ specified bound 
18446744073709551615 excee\
ds maximum object size 9223372036854775807 [-Wstringop-overflow=]
   29 |   return __builtin___memcpy_chk (__dest, __src, __len,
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   30 |                                  __glibc_objsize0 (__dest));
      |                                  ~~~~~~~~~~~~~~~~~~~~~~~~~~

EventType names do not match actual events messages names

Is there an existing issue for this?

• I have searched the existing issues

Package version

v1.10.0

OS

Other

Language version and compiler version

go1.20.4

Bug description

Some event messages names do not match their EventType name
For example the message corresponding to EventType.AccountContactRequestIncomingReceived is actually called AccountContactRequestReceived

This is annoying for writing generic events decoders (it's useful for dumping payloads for example)

I wrote a little script to find inconsistent event naming

❯ npx ts-node packages/scripts/checkWeshnetConsistency.ts
Missing event definition for GroupMemberDeviceAdded
Missing event definition for GroupDeviceChainKeyAdded
Missing event definition for AccountContactRequestOutgoingEnqueued
Missing event definition for AccountContactRequestOutgoingSent
Missing event definition for AccountContactRequestIncomingReceived
Missing event definition for AccountContactRequestIncomingDiscarded
Missing event definition for AccountContactRequestIncomingAccepted
Missing event definition for ContactAliasKeyAdded
Missing event definition for MultiMemberGroupAliasResolverAdded
Missing event definition for MultiMemberGroupInitialMemberAnnounced
Missing event definition for MultiMemberGroupAdminRoleGranted
Missing event definition for GroupMetadataPayloadSent

Current behavior

Some event messages names do not match their EventType name

Expected behavior

All events messages names do match their EventType name

Environment

macOS 13.3.1

Other

Since this is an api breaking change I would recommend fixing this before the api is widely consumed

Can this be used with Helia / browsers?

Asking a question, not reporting a bug

• This question is not about a bug

Is there an existing issue for this?

• I have searched the existing issues

Question

I'm currently powering my upcoming app with OrbitDb, which as far as I know is still the underlying technology for wesh. However it works in the browser, with js-ipfs and someday Helia. Better IPFS nodes exist for the native applications, such as on Desktop or Android (orbitdb for android can be called directly), but I'd like to also communicate with the webapp if needed.

Context

I can do gRPC in the browser, no problem, but I'm suspicious that the weshnet stack won't work there. Perhaps webassembly could work (with WebBluetooth or limited transports) for the Go app. A SharedWorker would be ideal!

Anyway, hoping to upgrade my OrbitDb usage to weshnet soon...