Bounty xxB-2024-001: xxDK C Library Implementation
Overview
This bounty rewards developers for implementing full language bindings for the xxDK library, focusing on C with optional extensions for Rust and C#. C support enables support for Rust, C#, Python, Ruby, etc.
Prize Pool
Total Prize: 1,000,000 xx (~$50,000 USD)
Breakdown:
C Library Implementation: 500,000 xx
This must be completed before work on Rust or C# can begin. Rust and C# can be worked on in parallel.
Rust Bindings Extension: 250,000 xx
C# Bindings Extension: 250,000 xx
Requirements
Eligibility
Participants must complete KYC verification
Participants from OFAC-sanctioned countries are not eligible
Multiple contributors may collaborate on submissions
Hi all, I worked with @rick on the initial Rust bindings earlier this year, and I would be happy to continue working to make them and the C bindings more complete.
For background, I’m formerly the lead engineer of the Mobby blockchain platform, where I worked with Rick for a period of a couple of years, and I’ve been working professionally with Rust and systems engineering more generally for most of my career.
Apologies for the delay, I’ve been busy traveling!
A preliminary list of milestones:
Core CMix functionality (creating/loading keystores, creating/managing reception IDs, starting network threads, etc; the basic functionality common across use cases)
E2E and connect client/server functionality
Restlike functionality
File transfer functionality
DM functionality
RPC functionality*
Misc. functionality
Finalize documentation, test suite, build system
I’m thinking of approaching the library functionality in chunks, focusing primarily on being able to translate existing examples (e.g. from the xxdk-examples repo); this is the goal of the first 6 milestones. For each of these I would aim to have the relevant functions callable from C, the relevant examples translated, and at least a cursory test suite and documentation.
(It’s entirely likely I’m missing large swaths of functionality out of unfamiliarity here; lemme know if this seems like a reasonable division of the library functionality.)
At that point, I’m thinking there will likely be some smaller/more obscure pieces of functionality that remain inaccessible from the C bindings; identifying and implementing/documenting/testing these is the purpose of the 7th milestone. Additionally, the test suite and documentation may need expansion and/or cleanup, and the build system may need cleanup; this is the 8th.
I’m aiming to start work in earnest early-to-mid next week, after I’ve gotten home from the holidays.
*I remember when Rick and I were working on the Rust bindings the RPC functionality was still something of a work in progress, and a scan of the current client repo indicates that it’s still fairly barebones. I suppose it’s still a bit down the line so the question is mostly moot for now, but is that in fact within scope for the bindings?
These look good. You are good to go to get started on this. We will partial award as you complete the milestones. Please let the forum know if you need help or drop it moving forward.
Hi? Julia, A few simple questions.
What is your GitHub ID/username?
When will the implementation of the library start?
Could provide a link where community members can track the progress of the development.
Thank you.
Hi? Julia, A few simple questions.
What is your GitHub ID/username?
When will the implementation of the library start?
Could provide a link where community members can track the progress of the development.
Thank you.
See the news post which links the repository for this information.
Could provide a link where community members can track the progress of the development.
I don’t mean to be against all these questions, but the curator, not us, is in charge of progress tracking as a bunch of other things (including KYC, reviewing the code, etc.) which is why that work (of the curator) isn’t free, by the way.
The grantee has no other obligation than to deliver as per milestones mutually agreed upon prior to the vote of approval. They can let us watch, but they don’t have to - it’s up to them.
From a more practical perspective: there’s nothing we can do with the code until it’s ready unless we want and can contribute for free, but why would the grantee spend time on dealing with your pull requests unless you’re a C guru and enjoy contributing for free, in which case we’d be better off if you took this task on for free and spared the Foundation the expense and effort.
The more burden on the grantee, the slower and/or more expensive development gets.
Starting/stopping network follower tasks, with callbacks for monitoring network health.
Management of reception IDs and contacts.
EKV reads/writes.
Logging configuration: small interface for redirecting xxDK log output to either files or to a custom log message handler, to enable integrating xxDK log output into native logging systems in other languages.
Some incomplete example programs, translated from the Go examples.
A very preliminary automated test suite.
Some miscellaneous design notes:
In general, I’ve tried to make the bindings behave as much like idiomatic C as possible. For instance, this means no functions with multiple return values; functions that may fail return a potentially-null error string, and output their success results via out pointers.
Error strings are stored in library-managed thread-local storage which will be overwritten by subsequent errors. Currently, potentially-failing functions return pointers to the error string directly, though it would be more idiomatic to return e.g. an int or enum indicating success or failure and to provide a single xx_GetError function to get the most recent error string.
I’m currently using a manually-written xxdk.h as the C interface to the library, instead of the Cgo-generated header. The generated header is not ideal for use as an actual C library interface, for several reasons (namely: inability to add const or other qualifiers to functions parameters/return values, lots of extraneous/internal/irrelevant definitions, inclusion of bindings-internal headers forcing these to be available to library users, lack of include guards for the main body of the library), and a manually-written one is much cleaner and more usable.
One downside of using a manually-written header, of course, is that the generated header is automatically compatible with the Go library, whereas a manually-written one needs to be manually checked and updated for compatibility. It would be good to, at the very least, find a way to automatically test the types of the manually-written definitions against the generated ones. I personally think that the gain in library usability is big enough to justify the loss in maintainability, though I would happily accept comments/opinions on this.
Please feel free to reach out with any thoughts or comments!
I’m not qualified to comment, so all I’ll say is thank you
Would it be possible to create a basic Python example, or maybe recommend how to go about using Python with xxDK and leave that as an exercise to the enthusiast?
