Dear all,
I started to develop a web light client in my spare time and I want to start sharing my code in git.duniter.org if possible. Can you create me an account?
I’m Vicente (vjrj) and I participate in other free culture and free software projects (and I don’t like to talk too much about me 
)
The client is oriented to newcomers and I’m using flutter too (and durt lib, thanks!). The current project name is Ginkgo if I don’t change my mind.
TIA,
Vicente
Hi vjrj and welcome to Duniter/Ğ1 project,
I created your GitLab account with your email address provided on this forum. Then we can see to create a Flutter group in clients group clients · GitLab with Ğecko clients. And move your repository there.
Which Duniter version are you targeting with Ginkgo? v1 or v2s?
Regarding your web-based client, if you are targeting Duniter v1 implementation and plan to have it served from remote servers, please do not allow authentication, otherwise member’s credentials could be stolen by anyone serving a web client.
Those stolen credentials could allow very nasty things to happen on Ğ1 currency and would harm it deeply.
Once Duniter v2s gets into production, serving web clients with authentication can be reconsidered, since the members would lose the smith permission, but still harm can be done. To be discussed separately.
You doesn’t seem to speak French, but for reference, in this post all the discussions regarding this topic can be found.
Hi @Moul
Thanks indeed. Merci!
Unfortunately I don’t speak French but I am can try to read it anyway.
I’m using v1 for create wallets without authentication so newcomers can start using G1 fast in markets an later with more experience transfer their savings to a cesium account. To switch to v2 should be easy in the future as I’m using durt
at the beginning I was using just basic crypto libs til I discovered durt. So it’s great to share and reuse code.
All the code runs in the browser and you only have the security of your mobile (your 4 digits pin or whatever).
Thanks again,
Vicente
One question, do you have a faucet in g1 test? I didn’t found it.
Yes this is our faucet: 🪙 Caisse de dons pour les contributeurs techniques à l'écosystème Ğ1 - #158 by tuxmain (kind of…)
Please add your name and the desired remuneration.
The code a Durt lib is here: pokapow / durt · GitLab (have to move to clients category)
This is the last work I did before I start to work on v2s. Making this lib allowed me to get rid of any Rust dependency in the latest versions of Ḡecko mobile v1: Files · duniterV1Latest · clients / Ğecko · GitLab
Also, this is durt_cli, a commandline tool which implements the durt lib: pokapow / durt_cli · GitLab
Durt is using GVA, so we need Duniter 1.9 nodes to use it. @aya is working hard to debug mempool transactions issues on this release, he will probably need help to diagnose the cause of the disappearance of some transactions in mempool.
Me alegro que los españoles se hagan con este lib, pensaba que lo había hecho para nada dada nuestra migración a v2s. Seguro que tendréis un montón de ideas para implementarla de forma original.
There is no actual faucet since all money creation is made by universal dividend (and there is no central authority controlling it).
However some of us will be happy to give you some G1 or GTest to let you do some tests, and if your work is published under a GNU (A)GPL-compatible licence, you can be remunerated in G1 by a rolling crowdfunded account (see the first link posted by poka).
Thanks indeed for both of you!
By the way I started to share my code here:
and you can see a demo here:
Some friend gave me some G1 so I can test with them.
Disclaimer: I just started to use Ĝ1 and go to Ĝ1 Markets since 2 weeks ago, so my knowledge of all this is quite limited. And I only can code in spare time (weekends, etc).
Waow, amazing and useful !
Bravo for this work.
Cant wait to use it 
My compliments to the chief.
Cela a l’air simple d’utilisation et rapide, j’aime.
Ce sera une extension web ou une application ?
Si j’ai bien compris pour l’instant, on ne peut pas se connecter ?
It looks easy to use and fast, I like it.
Will it be a web extension or an application?
If I understand correctly at the moment, we can’t log in?
Ni l’un ni l’autre, pour le moment, c’est une appli-web. Un site, quoi.
De ce que j’ai compris, c’est un portefeuille lambda qui t’est attribué en random (faut importer son compte si on veut le retrouver). Comme cesium, tu commences avec zéro. Tu peux soit vendre en direct et recevoir des sous en montrant un qrcode, soit virer des sous de cesium vers ce wallet.
J’ai aucune idée de c e que ça vaut niveau sécurité, mais l’interface est sympa, ça choisit automatiquement les bons noeuds et c’est rapide.
Faut encourager les vocations
Non, c’est une app flutter, multiplateforme car ma lib Durt le permet.
Donc, c’est une app mobile, mais aussi web, et desktop.
Oui, laissons finir sa POC, et soutenons le dans sa démarche
Au temps pour moi.
Very nice work, well done !! 
Hi folks. I continued developing g1nkgo during this week in my spare time (basically sleeping less). It’s quite functional, with still with some anoying bug (the stored contacts, for some reason are lost between g1nkgo updates).
Anyway I’m basically finishing up things and thinking/planning for the future.
I just updated the demo, and please be aware that I made some important changes, so if anyone sees anything strange with their accounts, please let me know. It shouldn’t happen, but just in case. The demo URL is still: https://g1demo.comunes.net/
Anyway, I’m already working on how to install it by others, quite advanced, but it’s not yet 100% ready. In other words, how to set up g1nkgo on your servers via Docker.
And now to the boring stuff:
Initially, I had always thought of doing something that was a pure static file that would run in people’s browsers once loaded. But I ran into problems with gva and CORS (in development and production).
For example if I try to pay, OPTIONS works but not the POST:
I temporarily avoided it by making the nginx that serves the static g1nkgo act as a proxy with the gva servers, but this would eventually lead to rate limit problems if it is not added to the allow list. If we all start using our wallets on the same g1nkgo server… eventually the proxy will be banned by the gva servers (if X-Forwarder-For is not taken into account, for example, or it is not added to the allowed list, correct me if I’m wrong).
So, I thought of setting up a duniter service with gva in the docker-compose file, and automatically adding g1nkgo to the whitelist. All good. I have that. So, it’s good in one way, because if someone wants to set up a g1kngo, they are more or less obliged to set up a duniter node to serve it, and this also improves the usage and network.
For those who want to take a look, here’s the link: docker-compose.yml · master · vjrj / ginkgo · GitLab (local node requests won’t work yet, because I have some hard coded https somewhere, but I hope it will work soon).
The problem I’m facing now is that, for example, as a non-member, I don’t know which limitations of use I’ll found in my node.
So, that’s where I am now. Let me know if you have any suggestions or comments.
PS: Translations here Ğ1nkgo/g1nkgo @ Weblate (I’ve just enabled nl and de).
Je n’ai toujours pas compris comment importer mon compte.
L’export crée un .json, mais où trouver celui correspondant à mon compte césium ?
Et je croyais qu’on avais convenu que c’était dangereux en termes de sécurité de stoker une clé privé sur un site web, je suppose que c’est juste temporaire.
J’ai quand même fait le test avec le compte par défaut, ça marche très bien.
I edited my nginx vhost for this duniter node:
# if ($request_method = 'OPTIONS') {
add_header 'Access-Control-Allow-Origin' '*';
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
#
# Custom headers and headers various browsers *should* be OK with but aren't
#
add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';
#
# Tell client that this pre-flight info is valid for 20 days
#
add_header 'Access-Control-Max-Age' 1728000;
add_header 'Content-Type' 'text/plain; charset=utf-8';
add_header 'Content-Length' 0;
return 204;
# }
# if ($request_method = 'POST') {
# add_header 'Access-Control-Allow-Origin' '*';
# add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
# add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';
# add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range';
# }
# if ($request_method = 'GET') {
# add_header 'Access-Control-Allow-Origin' '*';
# add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
# add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';
# add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range';
# }
I commented the request_method conditions, that mean I use the same headers rules for all requests kind, based on OPTION one. And that’s ok now, you don’t have any CORS problem for POST with that: CORS Tester - Test a URL for valid CORS headers, everything is green …
But, the thing is, i guess you should not have to use POST for GVA requests, since it’s graphql so it use websocket, which is OPTIONS kind, but maybe i’m wrong about it. You use same lib me for graphql with flutter, which is inspired from Apollo js lib, so this is websocket.
Why do you need post request on GVA exactly ?
This nginx vhost was made by Elois, who create this API, so he probably split request_method headers option for a reason, but honestly, I couldn’t tell you which ones. So I let my config like that for now, I think there is no problem with that.
You can’t, g1nkgo is only for temporary fast account, he designed it like this.
It doesn’t store the private key on a “website”, but only in the local storage of your browser, so it’s local storage (like cesium web used to do before it was bricked, and like Ğecko web could do very easily too).
Yes, that’s what safety purists advocate. Use a web extension that signs transactions instead of the web pages themselves. This is what polkadot.js does for example.
… but this risk is relative.
This is for the sole purpose of preventing man-in-the-middle attacks. But if the domain is safe, and people are connected to proper DNS servers, then I have a hard time even conceiving of security problems. Nor any kind of other potential attacks on people’s devices directly, for which the browser extension would not protect at all.
@flodef can you please share the link to the solana web client you showed me the other day?
Apparently they don’t care about this kind of security convention…
But beyond the security aspect, I see a lot of advantages of focusing on the Ğ1-companion browser extension:
So g1nkgo is a client made to be coded quickly, especially thanks to the durt lib, but those who want to use the Ğ1v1 quickly, without much commitment.
I also remind that it is only a payment client, and does not contain all the logic of interaction with the web of trust. So the need for security is less important.
Maybe it would be interesting to encourage users to load these temporary wallets only with small amounts, with maximum limits for example? But it might make the UX more cumbersome for not much.
@vjrj I think we should consider this client as temporary, meeting an urgent need for the users now. But do you agree to join forces on Ğecko and Ğ1companion for what concerns v2?
edit: ok i had problems with jaklis with this nginx configuration, so I rollback.
Hey @Maaltir ,
I am not sure if you speak english, but I’ll try anyway. If not, you can still copy and paste in a translator that will give you the french version …
As discussed previously with @poka , it seems the team already decided that using local storage to store private key is not appropriate concerning security issues. I don’t exactly know when the decision was taken and who took it on what knowledge…
From what I know, I come from the Solana ecosystem where we had these discussions about web local storage security. Solana is in the top 10 crypto currency by market cap. Not so much to bolster up, but just so you know that some Solana wallets are handling millions of $ in value and so security is something really, really important for the dev community. Especially because we already experienced many clever hacks that could have endanger the crypto ecosystem as a whole because people would distrust the technology.
That being said and without further addue, there is clearly a balance to find between usability and security. The best solution by far is to have a seed vault in your cell phone (see Saga mobile phone > Seed Vault).
But let’s be honest, even if everybody will get a seed vault in it’s wallet eventually, it’s not yet there. And it’s hard to ask every user to buy a brand new phone just to use crypto payment…
So concerning usability, the second best solution would be to use Web worker / local storage as a ledger. With HTTPS encryption for sending transaction, X-XSS-Protection to protect the local storage from cross-site injection and your key encrypted using AES, you’re pretty much protected against the majority of technical attacks.
Now, I don’t know if the June ecosystem long-term goal is to attract users, and especially non technical users. If that’s the case @vjrj 's solution is definitely beautifully solving the problem as it’s simple, can be used without technical knowledge and without having to download anything, and all that without compromising the security.
Of course, the web app can be hacked with great technical means like quantum computing, but so can a web extension and a mobile app. As a hacker, I can tell you that the easiest way to hack a payment solution is not to hack it technically but socially (= jack your password / mnemonic one way or the other, using phishing, scam, false app, keylogger, etc).
As a result, Solflare which is the most used wallet on Solana, has a web wallet, an extension and a mobile app. So far, the web wallet has still not been hacked despise billions of $ to get as a reward!
Having used it for 2 years, and make a lot of non-tech friends / family use it too, I realised that the solution they prefer is by far the web app. But they still consider it very complicated compared to Google Wallet. I know we are not competing with Google, still I really feel inspired by the simplicity and yet the security they offer to allow payments to everybody.
And I’m so far convinced that using a well protected web app with maximum security (encryption) and simplicity (get rid of wallet, address, mnemonic, etc) is the way to go. As most of users don’t care about those concepts as much as they don’t care about what is a microprocessor, ram, SoC when they use a mobile phone. They just want to use it without the constraints to enter a password, store a mnemonic, download an extension.
It’s just my opinion and I would be happy to hear your arguments / discuss about that 
Moi, je me contente de faire confiance aux développeurs.
Si cela leur semble sécure, ça me convient.
I just trust the developers.
If it seems safe to them, that’s fine with me.
Few time today but I added a FAQ with these questions so it’s more clear for users:
Thank indeed @poka for the cors fix. I’ll test and respond to both of you with more time.
DNS or just the server being compromised. As the user cannot choose not to update the client, the service admin can just update the server with the compromised version. This could be mitigated using in-browser verification, but this is not standard yet so it will protect too few people.
Meanwhile published releases are signed by at least one dev, and the users can wait for the approval of other devs to install a new version, if they have a doubt.
I think this is not about local storage, but the app being served remotely.
