Messaging Sdk #ProjectIdea

[efecan0]

An end-to-end encrypted cli messaging sdk based on the Noise Protocol, using websocket and tcp transports.

https://noiseprotocol.org/

Maybe in the near future we can build our full-secure mobile messaging application by using this sdk.

What do you think about that sdk idea, we can implement in C++?

[dailker]

@codehubbers/core-contributors

[Ziqian-Huang0607]

This is definitely a good idea, I have thought of this idea too, but from my personal perspective this might be a complex project to start as the first project we work on.

[efecan0]

Yeap but if we design architecture confidently (I've worked with uml at my college) at first, why not?

[Ziqian-Huang0607]

I geuss its worth a try

[dailker]

Yeah, I really like the direction you're thinking.

Using the Noise Protocol as the cryptographic foundation makes a lot of sense — it’s battle-tested and designed exactly for this kind of secure channel setup. If we wrap that in a modular C++ SDK with pluggable transport layers (TCP / WebSocket), we could create something super flexible ; usable both in CLI tools and later on mobile/desktop apps.

I’d be down to help spec out the SDK — maybe start with a Noise handshake over TCP, then abstract out the transport layer so WebSocket can just slot in later. For crypto, probably smart to build on top of noise-c or wrap libsodium for primitives.

[dailker]

We can go both since we have Go and C developers(you guys and me too i just dont know Go). What you think?

[gunkim]

If we choose Go as the language, we can benefit not only from goroutines, but also from the fact that Go is syntactically lighter and simpler compared to C++. This could potentially make it easier for more developers to participate in the project.

Thanks for the feedback! You're absolutely right that Go is attractive for contributors. That said, I prefer to chose C++ for this project because:

1. We want tight control over memory and buffers (especially with cryptographic payloads).
2. The Noise protocol itself benefits from a lower-level implementation for performance and portability (including embedded targets).
3. Our goal is to eventually expose a modular SDK that can be wrapped in other languages (Python, Rust, Go, etc.) which is more idiomatic from a C++ core.

We should likely keep the core low-level in C++ but a Go-based CLI or higher-level bindings are absolutely on the table in the future!

I understand the need for strict performance control. In that case, what about using Rust instead of C++? Rust is better suited to low-level work than Go, yet it offers safer memory management than C++. It’s also rapidly gaining traction, so we could count on strong, long-term developer support.

While I don’t have hands-on experience with Rust, C++, or Go in a professional setting, I’m open and eager to learn whichever language best fits the project’s needs.

[Ziqian-Huang0607]

If we choose Go as the language, we can benefit not only from goroutines, but also from the fact that Go is syntactically lighter and simpler compared to C++. This could potentially make it easier for more developers to participate in the project.

Thanks for the feedback! You're absolutely right that Go is attractive for contributors. That said, I prefer to chose C++ for this project because:

1. We want tight control over memory and buffers (especially with cryptographic payloads).

2. The Noise protocol itself benefits from a lower-level implementation for performance and portability (including embedded targets).

3. Our goal is to eventually expose a modular SDK that can be wrapped in other languages (Python, Rust, Go, etc.) which is more idiomatic from a C++ core.

We should likely keep the core low-level in C++ but a Go-based CLI or higher-level bindings are absolutely on the table in the future!

Hi, thanks for sharing your ideas, I definitely understand why you want to choose CPP, I am suggesting that we can integrate CPP and Go to combine both their advantages for the project

[efecan0]

If we choose Go as the language, we can benefit not only from goroutines, but also from the fact that Go is syntactically lighter and simpler compared to C++. This could potentially make it easier for more developers to participate in the project.

Thanks for the feedback! You're absolutely right that Go is attractive for contributors. That said, I prefer to chose C++ for this project because:

1. We want tight control over memory and buffers (especially with cryptographic payloads).
2. The Noise protocol itself benefits from a lower-level implementation for performance and portability (including embedded targets).
3. Our goal is to eventually expose a modular SDK that can be wrapped in other languages (Python, Rust, Go, etc.) which is more idiomatic from a C++ core.

We should likely keep the core low-level in C++ but a Go-based CLI or higher-level bindings are absolutely on the table in the future!

I understand the need for strict performance control. In that case, what about using Rust instead of C++? Rust is better suited to low-level work than Go, yet it offers safer memory management than C++. It’s also rapidly gaining traction, so we could count on strong, long-term developer support.

While I don’t have hands-on experience with Rust, C++, or Go in a professional setting, I’m open and eager to learn whichever language best fits the project’s needs.

Honestly, I personally think C++ is more suitable for this type of SDK especially when it comes to FFI support and embedded/platform flexibility. But if there are people who truly believe we can achieve the same level of control and portability with Rust, I’m totally open to that too. But at the begining we should design our architecture very-well after that no matter which language we choose

[efecan0]

I believe C++ toolchains are still better supported on embedded and constrained platforms

[JumaOchi]

Hey guys so I just started working with Go a few weeks ago and its amaizing honestly things like memory safety, built in concurrency with goroutines. I think Go would do well with this project. But if your going for max performance and want more control c++ ...But Go is really gaining traction and is awsome would be a good idea to go that way

[efecan0]

Yeap no problem about that. As i said before, design the architecture at first would be better for us after that, we will implement in 2 languages. It doesn't matter.

[dailker]

get ready

Messaging Sdk - NoiseProtocol ~ Cross Language

[dailker]

https://github.com/codehubbers/msg-sdk-go
https://github.com/codehubbers/msg-sdk-cpp

[IsmailBinMujeeb]

Nice idea I like it, let's go

[CoderRC]

I see that An end-to-end encrypted cli messaging sdk based on the Noise Protocol, using websocket and tcp transports. Since efecan0 wrote https://noiseprotocol.org/ I tried to compile for windows with libmingw32_extended in https://github.com/rweather/noise-c but posix_memalign does not exist in the phase one of libmingw32_extended so I will patch it up with https://github.com/CoderRC/noise-c is that a good idea?

[efecan0]

Yeap it's ok, but as i said before again, we should design architecture first. If you have enough time maybe you'd like to help, is it ok?

[isyedaliraza]

It's a good idea. Noise protocol is being used by WhatsApp for end-to-end encryption of messages. I searched on Google and found open source library implementations of this protocol in many languages.

@efecan0 So what are we building? Are we building another library for this protocol?

[dailker]

Started please continue conversations in here. You can easily access from Projects or https://github.com/codehubbers/msg-sdk-cpp Issues tab too.

This will be high level design please do not complicate too much so we can finish early and starting coding.

codehubbers/msg-sdk-cpp#1