People are always asking me which product I'm working on...

nostr:nevent1qvzqqqqqqypzquqjyy5zww7uq7hehemjt7juf0q0c9rgv6lv8r2yxcxuf0rvcx9eqqs2lyh8xj5aq7s5dppkxp95x7q7h599wjj08ma36h8xrhsjq2p284sj4gg48

Reply to this note

Please Login to reply.

Discussion

An SDK is a "software development kit", or a set of code blocks that you can use to build different software, by combining them differently or changing their parameters.

We have plans for what to build with them, but we made the choice to start off extremely modular/reusable because we want to build an entire suite of clients and be able to maintain and alter them later, as a group.

Additionally, in the spirit of contributing to the Nostr community at large, this lets us make our work available for other developers to use from the get-go. As we use it, and possibly as other devs use it, we'll incorporate feedback and fix bugs to make this foundation every more robust and stable.

You have to be working on other projects aswell?

It's one project with multiple products. This is one of them, but an important one.

Oh, you mean, am I part of any other project team?

Not really, no.

Fair enough. I guess have the luxury/misfortune to have 8+ hours/day to dedicate to my projects, so maybe I assume everyone else has over a dozen active projects, because they're also insane. I just like to see what everyone is up to!

Most devs receive no funding, so we all have only a handful of hours per week to work on our respective projects.

Very true. I'm not funded either. I just don't sleep much.

Yeah.

All the OpenSats/Jack/Saylor discussion completely flies past the reality that most of us are volunteers.

Oh yeah. To be fair though, I haven't been trying to get funding either. I tend to reinvent the wheel a little bit in my own image, which means my projects probably aren't worth funding until they are complete and someone finds value in it.

We haven't tried to get funding, either.

We're not really building the sort of thing that gets funded, or even noticed. We knew that, starting out, tho.

Low level libraries. Oh yeah.

Question. Would you think my noscrypt library has a use case as a dependency of NostrSDK? If not, would you suggest any changes?

Sorry probably should have linked the github. Its written in pure C would like to keep in in C89 if I can however mbedtls targets c99, so I may bump it. I just found it easier when I started getting into embedded stuff a few years ago.

https://github.com/VnUgE/noscrypt

nostr:npub1m4ny6hjqzepn4rxknuq94c2gpqzr29ufkkw7ttcxyak7v43n6vvsajc2jl thanks for the tag!

nostr:npub1qdjn8j4gwgmkj3k5un775nq6q3q7mguv5tvajstmkdsqdja2havq03fqm7 I saw this repo a week or so ago, and starred it so I could find it easily later.

One of the next features I intend to add on NostrSDK is a built-in signer. Right now, I've stubbed out an interface for the sake of testing, but it doesn't actually sign anything. I think noscrypt will be a perfect fit for doing the heavy lifting of signing events. Keeping it all in C/C++ land and using only common and lightweight libraries is exactly what I'm trying to do with NostrSDK.

As an aside, I'm curious how you're setting up noscrypt to work with C#. I want to do something similar for NostrSDK–that is, make it interoperable with other languages/frameworks, so we can support more than just C/C++ devs.

Yes I saw, appreciate it! nostr:npub1m4ny6hjqzepn4rxknuq94c2gpqzr29ufkkw7ttcxyak7v43n6vvsajc2jl shared it too. Also appreciated!

Interop with with modern .NET (5.0 and above) just uses Platform Invoke (PInvoke) to access exported symbols in position independent shared libraries. I'm not experienced in C++, but I do remember something about symbol mangling.

So technically nothing on the C side of things, just telling the compiler to export symbols in a shared library.

Thanks for the info!

I'm going to be deep in the weeds of C++ interop pretty soon. I've already peeked at the options, and they look interesting.

For Python, maybe C#, and some other languages, it may be as simple as exporting symbols so other languages can invoke the compiled binary.

For other languages or environments, I've been looking into gRPC, either with inter-process communication (IPC) or as a client-server connection over HTTP. Theoretically, a really lightweight client could use a remote server running NostrSDK with gRPC as a BFF for interacting with Nostr relays. I'm excited to dig into those possibilities!

I haven't farted much with C/nodejs interop, but I do believe that is a fairly simple option as well.

Can we tie his library in somehow, with the build structure nostr:npub1ecdlntvjzexlyfale2egzvvncc8tgqsaxkl5hw7xlgjv2cxs705s9qs735 just made?

It would be tied in automatically if we make it a dependency of NostrSDK.

I'm currently working on pulling dependencies into the CMake build directly, so hopefully it will be easier to incorporate into other builds instead of using the build "scripts" I set up previously.

Definitely. This is a C library, and the structure I set in place is highly modular so it allows the insertion of any C dependencies with minimal friction. It could be as simple as adding a line in the manifest.