Most devs receive no funding, so we all have only a handful of hours per week to work on our respective projects.
Discussion
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?
What language did you write this in? And the vault?https://www.vaughnnugent.com/Resources/Software/Modules/noscrypt?v=7485aa5a43476c47d54ec51fb96751a14e0ed629
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.
Excuse my French.
Ne t’en fais pas, chère nostr:npub1m4ny6hjqzepn4rxknuq94c2gpqzr29ufkkw7ttcxyak7v43n6vvsajc2jl
🥰
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.