This is a request for a 4 months period from January to April 2023 in which I would like to continue working on extending the Grin++ APIs, updating the CLI version of Grin++ and improving the Grin++ documentation. By the end of this period the CLI version should be usable connecting to the up-to-date APIs.
Rate: EUR 7.500,00/month.
What do I want to accomplish?
I want to make it easy for people to develop new things on top of Grin++ now and in the future, but that requires a robust API. And that’s what I want to continue to focus on. The current API is very UI-bound at the moment, and this should be improved. I have been working on improving the API using as a guide the API in Rust, the RFC and adding the changes that I think are important.
In order to make sure things are working fine, I will bring to life the CLI version of Grin++, this CLI version should be using the new APIs and it should have a basic compatibility with the Rust API.
Recently @satoshocrat managed to compile the master branch for a Raspberry Pi4, this is a huge step, and simplifies the efforts on increasing portability. I would love to make possible to users to run their Grin++ wallets on their Pi4, and a CLI version seems to be more reasonable to me.
I will continue to express my thoughts freely, if support for this funding request will be used in any way to silence me, please do not support it.
As much as I am looking forward to grin rust having a GUI, I am also looking forward for Grin++ to have a similar API and CLI version.
The reason why this is so important is because we want in the longer term as much as possible a balanced used of both grin rust and Grin++ for all user groups
regular user (GUI)
advanced users and ecosystem developers (API +CLI version)
This should ensure there is a balanced number of nodes available for both implementations and that ecosystem developers can develop on top of Grin without having to distinguish between the Rust and C++ implementation. The same logic applies to future implementations of for example Python or Haskell.
Now I have collected enough feedback/comments to rethink the idea I had initially, not only by opening that post but also by sharing ideas with different people before I even talk about it in public. Today I understand better how Grin could benefit from the use of Nostr, and I think it is worth a try. I already expressed this in Keybase.
Here you can have a summary about v1.2.8:
Here’s one about v1.2.7:
Here’s one about v1.2.6 (not the best release I have to admit, sorry for that, v1.2.5 worked better):
This is progress on Grin++ running on arm64 (still a lot of work to do):
(There was another more recent post on the subject that I can’t find)
You can scroll through the channel and get a better idea of my approach. Most of what I do is prioritize based on the frequency with which requests are raised or the frequency of problems. I also add features that make life easier for users, and simplify support for me.
I also could, but I won’t because anyone could also do it, go through the forum and paste here each and every topic, I’ve openly shared anything I’m working on here (check for yourself), explained myself, asked for feedback while still coding, and made changes before pushing anything.
A pretty epic “community-driven” development, I know.
I already said this before. I never release code that:
I am aware that it doesn’t work well.
it does not “respect” the framework.
it is not secure.
hat I don’t feel comfortable with it.
introduces some important change without being reviewed.
code that I know I will rewrite in the near future.
When I have introduced changes to the C++ code that have the potential to break something or lesser the privacy and security of Grin++, I have always asked for review and @david has very kindly assisted me. Respect.
If the way I work “slows down the pace”, I’m still not going to change it. I have been introducing new features as I have been fixing issues at the same time. Sure, there are still a few issues to fix, but the fact that every time someone asks for support, everything is fixed without me even writing a line of code, now with only few clicks, tells me that good progress has been made. And I want to continue to deliver as much as I can to the nodes that represent 70% of the entire network:
I have always delivered much more than what I have initially committed to, throughout this time I have been totally open, I have spent time proactively asking for feedback on my work, which has enriched what I release. I think I should start documenting more, but it’s quite boring and I could do it at any time, at least that’s my excuse, but don’t worry, eventually I’ll get around to writing the documentation.
Did I already mentioned that Grin++ native libraries can be integrated into any Visual Studio or XCode solution? No? well, it is because I still need to do more testing and write a PoC for it.
I decided to make this post to stop repeating myself over and over again, but at this point, I have no reason not to believe that some people here are driven by pure evil intentions, so much so that they are now creating fake accounts here. Guys, get a life.
@Trinitron you have finally admitted that you are not qualified to comment on my work. We’ve come a long way, I’m glad. The same applies to some others, especially the noisy ones.
At some point Grin should stop pandering to the lowest common denominator, people who bring 0 value to the table, none, nothing, not even basic technical discussions, they don’t spend time offering support to newcomers, or fixing a broken link in any of Grin’s websites; they just demand and give nothing back but hate; envious people, unable to handle their base desires to destroy anyone who dares to think independently. They will kill Grin and then blame those who actually do something. Be aware.
As I said before I am respecting your work, but there is no transparency at development process, what is not looking good especially after situation with @satoshocrat, cause we can not see anything for 4 months at Github.
I think your development progress should be on Github, as you positioning yourself as full-time developer, the world deserves to see real work at Grin. I am developing my project locally and still doing all commits, its very useful for development and further testing.
You can simply create another branch at your Github, nobody pushes you to give releases, we have another good example - Grin-GUI (GitHub - mimblewimble/grin-gui: GUI for Grin Node + Wallet), project is not ready, but @Yeastplume is showing real progress by commiting, every big task can be divided by small parts and pushed at the end of the day.
I still can not find sources for this page, @hendi is not answering here and at Keybase, if you have contact with him, can you ask him to push his work at Github, please.
David, critics is normal process, don’t be offended please, it’s making us better, we are working on the same side, we are making world better through technology with Grin. Millions people will use our products, we should unite to rise together.
I don’t know what exactly you mean by “general attitude”, but you are certainly being lazy to a fault here because I have been very open with everything I do for years contributing to Grin. To answer your question, I’ve merely posted links to my work that you could have found yourself, but you haven’t even invested your time in doing so and want others to do it for you. I am more than happy to offer my apologies if I am misconstruing laziness with you having some attitude against me or my work. Maybe you’re just too busy and that’s fair, but if so, I invite you to try to be more honest by saying something like “I haven’t followed much of what you do.”.
OK @ardocrat you finally brought points that can be addresses, thank you. I am happy you did. Let’s begin.
And I’m not saying otherwise, but I’ve always had the same approach, and as I explained above, it has always worked so far. One could probably argue that this Q wasn’t my best.
I will tell you this: my “mistake” was to estimate on the unknown without taking into account that I was doing something totally new to me.
I started experimenting with Nostr with skepticism after integrating Tor Bridges into Grin++ only to realize that Nostr could actually be a solution for Tor. Using Bridges helps but doesn’t solve the problem completely, Nostr could do it. For a PoC I needed to change some responses, and adapt the code. That aside the instability of using overloaded relays that stops working, I had to deploy my own relay in order to use it with the release, the lack of portability of Nostr’s Python libraries, and the differences between relays implementations, not all of them responds the same way. Take into consideration that I am working with two separate repositories here. That’s pretty much the non-technical summary of my last Q.
Now, my take based on my experience writing software is this: There is no need for the commits tree to reflect all of that. Commits should, for the most part, reflect value; me, as a developer, I should be able to move to any commit and get something that works. I should be able to roll back to any commit and deploy it just like I could deploy the master branch.
I have seen many times developers make any small change in the source code just to say “look, I’m doing something!”, especially under pressure from project managers. But others may have their own reasons which I do not want to refute. I won’t tell anyone how to do their work.
I know there are people who see commits as you are more or less putting it here. It’s nothing new to me, but I disagree.
So now you might ask yourself the valid question: how do you show progress? Well, as I have been doing all this time. I publish how it’s going, ask for feedback, and generally give me time to do an alpha release. I then gather more information, correct the problems found, refactor the code I consider faulty, commit it and publish it. Only this time it has not been possible so far for the reasons I have already explained several times.
I’ve linked the releases of all the progress in Grin++ and its current status that you can go click and use it right now, and your answer is: “the world deserves to see real work at Grin” and shows a list of the commits! Madre mia! The irony here! Amazing!
Yes, but I won’t. Repeat with me: committing for the sake of committing is useless. Don’t tell me how to do my work, don’t waste your time.
With all due respect, and I mean it… with all due respect I strongly disagree with that approach. I have talked about it quite a bit in the past and how this is/was affecting Grin.
Look, building a good product is not like going from A to B in a straight line. It never is. The path to a good product is more like a spiral, you code, you release, you test, you fix, you release and repeat:
You shouldn’t go into the dark to write code and think you’re building the perfect product without getting feedback from your users somehow. Technology is advancing so fast that if you do, you will end up launching a product that most likely won’t even hold your initial assumptions and will be old by the time it hits the market. There is plenty of documentation on the subject, enough to change anyone’s mind.
That said, I have no right to go into Keybase to build conflicts just because I don’t agree with the approach taken by the people working on the Rust implementation. That would be disrespectful and immature of me. All I have to do is to be ready to help in any way I am needed, as I have done so far.
For years I have been presenting my work publicly asking for opinions/feedback/comments here, always. I have taken the ones I consider valid, and discarded the others. The most recent example is from my last post, I can honestly say that most of my assumptions were wrong. I am not afraid to say it. I have been changing much of the code because I accepted the observations as good and valid.
I embrace criticism, criticism of my coding style, for example, has helped me a lot of times.
I have been able to interact here with people with whom I disagree most of the time but many other times I have found valid points that I have taken without problem.
Asking about the status of Grin++ while openly accepting not being qualified to review it? Now there are people who can’t even write code telling me how to do my job? Questioning me without even reading my posts and/or reading my updates during past meetings? People admitting they can’t review my code but wanting to judge my effort and time? At this point I don’t think it’s “just criticism”. It’s more like a witch hunt.
I care so much about Grin users that I my entire approach is focus on them since day one. Now I want to release something that will allow us to gather enough feedback to initially evaluate how Nostr + Grin could work successfully. I have repeatedly expressed that after this next release my focus will be on things that are not exactly visually perceptible to regular users, and will be for a long time to come. The more value I can deliver to users in this next release, the better.
Hi guys, from a view of normal ‘investor’ or crypto-newbie, they like to see how is our github although it could make some pressure to developers.
Github could be a signal to let other people know that we’re still alive after 4 years downtrend.
Sometimes, we have several talents here that’s why it’s difficult to go ahead with same voice.
Anyways, I really appreciate what David has been contributed since years.
We agree it was mistake to take new task without finishing previous, we can see you are asking for next funding for Nostr, I think previous task should be finished first, you can even take extra month at your own expense.
We don’t need small commits, we just need to see real progress of development, developers work can be evaluated only from real code, it works equally at big companies and startups, screenshots can be showed by projects managers to their сustomers, cause they have no clue how to write code.
Not for previous funding period from what was promised.
Commiting to show you are working on code as developer, period ended, nothing at Github, its fair to ask what happened.
This is actually calling community feedback, don’t stop yourself and bring your ideas as we are working together at same project. I also found some bugs at Rust code while developing my projects on it, I do what I can from my side to fix them with the time.
As I said before it is more like presentation from PM to customers, not developer style.
Sadly we can not see this style, cause we can not see the code to make any criticism here, it’s your choice to take Typescript or Python, actually I thought it will be C++
I want to see code to know how it works. Mobile/TOR/ISP operators are changing their IPs all the time, I want to know how they are counting these agents, nothing else. Their backend is not on Github too: https://grinnode.live:8080/agents
Thanks for your time of commenting, I think we understood each other now.
It is not the developers who “evaluate” my contributions, but the users. All my contributions are focused on users and/or people using what I release. If you want to work to please developers because you want to feel “smart” that’s your thing, good luck with it. I will not change my approach because you or anyone else wants me to.
No, you and I we do not work together. Enough of this nonsense.
As I have said before, I have the freedom to work as it fits best for me, just like you, just like anyone else.
Sometimes the estimations are accurate, sometimes they are not. If your estimates are always correct, it means that you are not pushing yourself beyond your own limits, but that’s another topic. Wow, you just figured out how estimations work. Congratulations! Good job!
What is “real progress” means? You brought the GRIN-GUI sadly because I don’t want to talk about other people’s work, but you brought that example. What you are saying is that “real progress” is a list of commits without releasing an actual product to users. What I’m saying is that I don’t agree with that, what is proven to work best is that one should release workable software, even if it is incomplete, so that one can let users test it, and one can correct or pivot initial assumptions. Early users will be happy to report any problems and won’t judge you for it, so you have a “safe space” to experiment whatever you want. Over time you’ll have something closer to what users expect from your software.
On the other hand, if you release everything together when you think your work is “done”, user expectations are higher. Your software will work, for sure, but it most likely won’t solve anyone’s problems. I’ve been writing code for startups for years, in fact I’ve only worked in or for startups. This is how the majority of startups die.
Most of the time, programming is a creative process. You start small, you have an idea, you follow it, you try it, if it works, you improve it, if it doesn’t, you drop it. You want to encourage developers to be creative. This is how, for example, the Linux kernel and many other successful open source projects are built.
My guy, you have no clue what you are talking about.
Basically, because I was “wrong” with my estimates, in quotes because estimates are there to be wrong, what you are asking is that we stop supporting the only developer who spends hours and hours directly supporting users and who works prioritizing his work based on the needs of the users themselves, that constantly contributes to the wallet destined for regular users, which is used by 70% of all nodes. Let that sink in.
Your obsession with me is not criticism, it’s just malice. Is this how you want Grin++ to stop being the most used Grin wallet? You don’t need to answer, it’s already clear that it is.
No, I want all developers and members of community who is going to be paid by CC fund to have equal rights and follow equal rules. If work is not done, payment should not be done also. Again, we are not looking for past merits we are only looking at results of current tasks. No code, no release, no payment, simple as that.