TLDR:
1) Feedback on the governance and the need for the CC and community to better check deliverables will be take to heart.
2) Respect our long term developers, but let @davidtavarez first wrap up his deliverables for the previous funding request, before moving to funding the next request.
3) Give biweekly bullet-point update/follow-up on progress
4) Explain to the community the relevance of features like PIDB and Nostr, their benefits for users. When a feature gets enough up-votes, move to a funding request for and a vote for the request. In this way we are certain the community is supportive of the funding request.
I want to post some suggestions here since there has been some criticism on how the CC checks the deliverables of funding requests and one how developers updates their progress on the deliverables of his funding requests.
Let me start with saying that some of the criticisms is deserved, although I think we should keep it general since criticism is on governance and procedures in governance and not specific to @davidtavarez who only happens to be the only full time developer governed by the CC.
he has contributed greatly to the project both as a developer and as a CC member and we should give him some slack and credits for that and not target him. But to get back to the criticism, yes we should be more strict in putting value to deliverables and checking deliverables and perhaps even move to paying per achieved deliverable, although I want to keep that to a separate discussion.
In his recent funding period, @davidtavarez got distracted by all the enthusiasms in the community for implementing Nostr as an alternative to tor. Nostr has many potential benefits. Not only is tor sometimes unreliable and requires bridges to work in some countries, but it also does not serve as a buffer/bulletin board to store transactions when a receiving wallet is not online. Wanting to work on Nosr is therefore understandable and might bring a lot benefit to the community, but it was not in the deliverables of his funding request.
Back to those deliverables. It is true that @davidtavarez got distracted and did not finish the client implementation and API part + documentation. I would therefore propose he works to wrap-up these deliverables to his and the communities satisfaction before applying new funding. Does that mean the work on Nostr goes unaccredited/unpaid? Not at all. I discussed it with @Mokhtar and he proposed we will first discuss which functions the community wants to be implemented and explain there relevance and then let the community up-vote if they want a feature and which to implemented first. I am quite certain that Nostr implementation will be funded at some point in the future, so all work done by @davidtavarez on Nostr will save him time when the funding request for Nostr gets approved. Below I will shortly discuss the two main functions that I think are relevant to be implemented in the near future. We will create separate posts to discuss them with the community and see if they want to support their funding, here I will give a short summary of them.
1. Partial Initial Block Transfer (PIDB).
PIDB is currently on testnet implemented for grin-rust and hopefully is soon stable enough to be brought to main-net. The benefit is that users will be able to download blocks when they first install their wallet and node from multiple peers. Many users experienced having to wait in some cases for a day to fully download the grin blockchain, or having errors when first syncing and needing to restart the whole process. Considering the Grin blockchain is < 3GB this means the current system of initially downloading the blockchain as .zip file from a single peer is slow and unstable. PIDB will allow nodes to sync with multiple peers making initial syncing more robust, decentralized and in the future with some tweaking it might become faster since you can benefit from the upload speed of multiple peers. Of couse we do not only want PIDB working for only a part of the nodes (the rust nodes), but for the whole network to reap its benefits. Therefore implementing it in Grin++ is important for the whole network
2. Nostr.
Nostr is a decentralized network protocol for distributed and free social networking system. Posts are particularly resistant to censorship and are cryptographically validated. As of April 2023, Nostr has 1.1 million users. One of Nostr’s main innovations is its concept of relays, software that sends, receives, and stores text messages. In the case of Grin this would mean that if a wallet is offline, that he download transaction slates when going online from the relay. So Nostr not only serves as an alternative transfer protocol but also serves as sort of a bulletin board.
Regarding follow-up and updates on developments. As agreed in previous CC meetings, he can keep us updated with a few bullet-points update each two weeks or so. Apart from that I think @davidtavarez should be free to work in whatever way he wants, as long as the final deliverables get merged on Github in the end. Yes, it would be great to work with commits, but in the end who cares as longs as the final code is released.
This is my personal opinion and proposal to move forward while taking in consideration the recent criticism on governance by the community, feel free to give feedback.