Request for funding @davidtavarez May-July 2022

L;DR

This is a request for a 3 months period from May to July 2022. Past request I had to prioritise past pending work to improve P2P stability of Grin++ node. I would like to retake previous work planned.

Rate: €5,000/month .

What do I plan to achieve?

Priority.

There are important features that I plan to add to Grin++ in this release based on direct feedback from users. Users in China, and now Russia, face censorship from their governments, which makes it difficult for them to have their wallets accessible through Tor. The solution for this is to use Tor Bridges, and I would like to simplify this for users by adding a helper to the UI, so that users can add them more easily.

IMO it is also important not to reuse the same address while receiving coins, for that reason I plan to complete the WIP work on this. If the user has the non-reusable addresses, it would be nice if we could automatically generate a new address every 24 hours, or at least after every transaction received. I’m still not sure which of these two options affects the user experience.

The latest version v1.2.7 brought major improvements in P2P stability, but some users have reported getting stuck in block sync at 99% sometimes from two previous versions. The easiest solution is to quit and reopen, which works, but could cause users to become impatient and try to kill the process while writing to disk, and this leads to data corruption. This is worth investigating and fixing.

Not very important, but useful.

The following are things I will add during this period if I have time for it.

Our network is full of slow peers today, eventually some people get frustrated reporting extremely slow speeds during an initial sync. I have recently added the ability to have a list of preferred peers using the configuration file, but I also think it is important to expose this feature through the API and UI to simplify the process for regular users.

Getting the current payment proof from the UI is also important, right now Grin++ users can’t do it. The ability to do that has been suggested to me by several previously, I think it’s time to add this.

Disclaimer

I want to continue to express my thoughts freely, if the support to this funding request will be used in any way to silence me, please do not support it. Also, I am part of the Community Council and will, of course, inhibit myself from voting that day.

13 Likes

thank you David for all the hard work. I have some comments regarding the priorities

I think one of grin’s issue is usability, and people using grin ++ thinks the app is not working just because they are having a hard time to sync their node. so the priority imo should be to focus on improving usability. you already did a good job with 1.2.7 but following your list I’d like to remix it a little bit

below what I consider the priorities :
1 - setup a list of preferred peers from UI : it’s an easy fix for those who have problems but we need to make sure and find a way to avoid flooding one specific node because someone recommended it on a telegram group
2 - Tor bridges : will help onboard new users from Russia and china
3-P2p stability : this can take some time, as we need feedbacks from users. why don’t you add an easy option to export logs from UI instead of using cmd lines ?

the 3 previous one are related to usability and that should be the priority imo

next, we can add the reusable address and payment proof : on the long term, these two are important but for now unfortunately people are not yet using grin to buy and sell, you can check by yourself slatepacks.com

What’s your thought on this - https://snowflake.torproject.org/ ?

There are 3 buttons to export the logs from the UI.

I understand that but what can happen is that the node rejects new connections. The problem I have with having preferred peers is privacy. We should not encourage users to trust a certain list of peers, what we need to do is let users do whatever at their own risk. This is, of course, a temporary patch until PIBD is deployed and nodes supporting the feature take over the network, which will take time.

People’s nodes will connect to slow and inefficient peers, there’s not much we can do about that in terms of coding. The only thing we can do to help is to deploy reliable nodes everywhere. Let me expand on this a bit, because it’s a source of a lot of confusion in general.

Now, users report from time to time having to wait a long time to do an initial sync, they see it as a problem of the wallet, in my case Grin++. The answer to this is: slow connections are not a problem of the wallet itself. So, some users will say, “but I close it and open it again and it’s still slow”, and the answer to that is, “because you’re probably in the same batch of slow peers”, that’s why cleaning the peers database usually helps. The node will randomly try to connect to a certain amount of peers, and that’s what we want, we don’t want nodes to filter peers by latency or anything like that. And one of the reasons is that, for example, a government could deploy super-fast nodes and then monitor citizens’ behavior. The downside is that the network must then have a good number of nodes run by independent, non-compressed community members, which is not easy, but is the healthiest thing to do.

I understand that this is frustrating for many users, that’s why I took the initiative to help people deploy nodes by doing the technical work by myself. I hope more people follow the example, the CC could actually promote Linux Installation Parties like but for public nodes, but that’s another topic. Been said that, let’s clarify these concepts:

Utility = whether it provides the features you need.
Usability = how easy & pleasant these features are to use.
Useful = usability + utility .

I can say that Grin++ is more focused on bringing an easy and pleasant experience for regular users than the Rust node, but there are many things that are out of our (grin-node and Grin++) domains, and the “slow” synchronization due to slow peers is one of them. I found Grin++ syncronization faster than the rust node, but only when you are not connected to slow peers, I haven’t take a look into the Rust code in deep, so I can only say that this might be perception. After v1.2.7 the only reported problem in Grin++ regarding the synchronization process is this, but I confess I only experienced it once and it was running Grin++ on an Android phone. Still, I want to take a look because I want to make synchronization easy and pleasant for everyone but without compromising privacy and security.

To improve usability we are doing things like statically compiling dependencies, so you don’t have to deal with that 99% of the time, we are shipping Grin++ with the Tor binary signed by the Tor Project, we also check if your wallet is accessible or not. The next step is then to guide users to set up Tor bridges themselves, and help them avoid censorship and make their wallets reachable. Also, to facilitate the initial synchronization if the user is constantly connecting to slow peers, I believe that having the ability to connect to peers will help them go through the process of downloading 2GB of information.

I personally want to make things as easy and pleasant as possible for Grin++ users, but we also have to work to offer more privacy, and I see that the possibility of generating a new address helps, it’s not a big deal, but it helps.

This is very good, Snowflake proxies looks like a good option, I will have to double check how this affects hidden services, if the locally started hidden service is not affected in any way, I don’t see why not to use it. Thanks for the link.

Is this a theoretical concern or a real one? Is it chasing the news (which will soon be out of date) or are there really people who can only use Grin and nothing else?

Maybe they aren’t using it to buy/sell because the UX doesn’t enable them? How do you currently show proof of purchase with Grin? how do you handle invoices or receipts?

I invite you to join the Telegram groups and get your answer.

No.

this is not about chasing the news, we actually have users struggling to user grin ++ because of censorship

you are completely right, but as I said for the moment people are not using slatepacks .com for p2p transaction that can easily be handled, manually. by the way there is this Early beta version of grinnode.live’s public transaction proof verification service is online! you can check.

1 Like

nah, @trab is wrong… how is it that the UX does not allow or does not allow anyone to buy/sell? explain please.

Grin can already be used to buy and sell, it can however be made even easier. Having access to payment proof via both UI and API is needed if anyone would like to build a payment processor. Only with a payment processor, Grin can be used as easily as Bitcoin since no manual linking and verifying of payments is needed, nor manual dispute settlement. If people will use it is in the end up to them, we should however enable them to do so by making as easy and scalable as possible.

Same with one-time use addresses. I do not feel comfortable exposing my tor address when interaction with strangers. Only with one-time use address I would feel comfortable sharing it with strangers for online purchases. So indirectly, one-time use addresses also support active use of Grin.

I summary, I support this request.

6 Likes

What if a link to aggregate “grin stores” were included in the GPP gui? (Like the telegram link but perhaps on a different tab) also perhaps link to how/why forward port 3414.

One thing I would love to see added to this list, is a “resend button” in case a wallet was offline.
For example use the reload button symbol from the browser. Note, nothing changes internally nor in the behavior of the wallet. When a sender clicks the “resend button” the the wallet will attempt to resend the slatepack via tor. If the receiving wallet is online, the transaction will be finalized. If the receiving wallet is still not available, the wallet will again show to the user that the wallet is not reachable and will present the same slatepack again to the user.
resend_button

2 Likes

This funding request has been approved!
Looking forward to that resend via tor button if you get around to it :wink: :muscle:.

4 Likes