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.
Disclaimer
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.
I am interested in knowing the current status of the CLI version and whether it is now usable connecting to the up-to-date APIs as was intended by the end of the period.
It would be really helpful if you could provide some information on the current status of this funding request.
Thank you for your time, and I look forward to try the up-to-date APIs.
I will not engage with this account created 5 minutes after writing thing. I already answer (again for the 10th time) all answer regarding to this on the last meeting.
I wasnāt trying to waste your time or cause any frustration.
I recently joined this forum based on the recommendation of community members who said it would be good to get more information about this funding request.
However, I couldnāt find any updates on the current state of the CLI version and the up-to-date APIs after checking the official Telegram group.
If anyone else in the community has any information or can share a link to the meeting update, I would greatly appreciate it.
Finally, I want to let you know that I use a translation tool to communicate, so please let me know if my message is unclear.
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)
These are all of the releases you can confirm by yourself:
Notice that I also have to work on the UIs at the same time before releasing anything. Desktop UI is written in TypeScript and Mobile UI is written in C# using Xamarin:
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.
I think you are misdirecting your general attitude towards me. I have never previously claimed to comment on your work, only the user experience of grin++.
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.
Some people here can say what they want about my āattitudeā. They can criticise my approach, but it would be crazy to say that I donāt care about Grin users.
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.
I greatly appreciated Davidās work on, support for and proposals for Grin++.
Looking forward to Nostr implementation as well tweaks for the raspberry pi.
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.
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.
.
