What do we organize for the program? How do we organize the agenda? How do we organize these days?
I bet, the focus will be on Substrate with presentations and workshops. Isn’t it?
As a contributor, what would you like to organize as a presentation or a workshop?
From my side, what can I bring you? Do you have any wish from me?
I would like to hold a presentation on how to contribute to Silkaj project, followed by workshops to contribute to it.
If there is someone interested, I can propose an AdminSys workshop to contribute to Duniter infrastructure.
My goal is to recruit contributors on these two topics.
On my side, I have not planned anything yet. I would like to know the needs of the participants, especially in terms of workshops.
Because if it’s to make a workshop where there will be only tuxmain and me it’s useless.
I have to think about whether I can offer an « accessible » workshop, but the notion of « accessible » will depend a lot on the level of the participants.
@tuxmain , if you have any ideas, it could help me too
In would be interested in a client/wallet programming workshop. This would probably be useful to all the client/wallet programmers who need to switch from BMA/GVA/WS2P/LevelDB/DuBP to Substrate/RPC. (e.g. I tried to use subxt in GMixer but I don’t understand how to configure it for gdev)
But duniter-v2s won’t do everything, I would even like it to do as little as possible, because it seems more relevant to me to start with a micro-services infrastructure.
An idea of something you could code : an indexer, like what duniter-squid does.
Basically, you could code a server in Go that retrieves raw blocks from duniter-v2s and indexes some data. Then expose theses indexed data with a graphql api.
A bit like what you might do to port wot-wizard, but split in several different programs (so in micro-services), in order to expose an « indexer API » that can be used by other projects.
Be careful, the term « client » represents the substrate client, i.e. the host node of the runtime, we must banish this term from now on.
Here I understand because you added « /wallet », but it would be better to write « wallet/apps »
I was talking about a workshop idea concerning the duniter-v2s project itself, because that’s where we need contributors.
There are already too many volunteers to code wallet/apps/tools but not enough to code on duniter-v2s itself.
I’m not going to start a workshop on wallets/apps, it’s not my role, especially since it’s quite easy, vit and poka did it by themselves.
I think your problems are more with subxt itself, we’ll look at it together
The end2end tests of duniter-v2s also use subxt, did you check how I did it? It will make you an example
Client is relevant for wallet apps AND substrate nodes as well in the substrate ecosystem. So we must specify the domain of the term (rcp client, node client, etc) when we use it to avoid confusion.
Ce serait bien si chacun de vous pouvait quand même préparer une présentation sur Ğecko, Tikka et cesium v2, et réaliser votre présentation à distance
Ce serait bien, @Galuel est-ce que ça te semble possible ? comment est la 4g sur le lieu ?
Si la connexion le permet, il y a de la place le samedi et le dimanche
Je ne vais rien présenter là-dessus, car je ne suis pas certain de rester sur squid, en fonction de ce que @ManUtopiK va proposer de mieux, mais aussi car squid à tout de même pas mal de limitations.
Ça peut être bien qu’on se fasse une visio/brinstorming sur les indexeurs, car je vois plein de solutions possibles avec différents inconvénients (notamment en effort de dev). J’aimerais bien que @gerard94 nous aide sur cette partie indexeurs, et j’espère qu’en trouvera un moment pour en parler pendant ces RML!
Salut,
je peux faire une petite démo sur le fonctionnement d’Hasura. Ce serait bien même pour comprendre pourquoi squid est monté à l’envers comme je l’explique ici…
Hasura peut créer une api graphql à partir de plusieurs BDD postgresql. J’ai donc ajouté quelques lignes dans le docker-compose pour utiliser la gateway directement avec Hasura. Du coup, plus besoin de typeorm ni d’apollo ni d’express !
Je ne suis pas allé plus loin pour l’instant car la stack squid est bizarre et certainnement pas « lightweight » comme ils le disent. Mais comme je ne connais pas substrate, je me plante peut-être…
Je vais essayé de mettre ça au propre pour faire une démo pour les RML…
Bonjour, je ne serai effectivement pas présent pour des raisons familiales, même si je voulais venir à la base. Par contre j’essaierai de suivre l’événement à distance de temps en temps !
On se rend compte du boulo nécessaire sur les benchmarks et les réglages fins du runtime.
Le calcul des distances en parallèle aussi.
Côté client tout va se jouer uniquement sur la bonne maîtrise de l’API RPC et des changements d’états du storage. Le reste étant délégué aux indexer et data-pods.
Bravo pour tous ça.
Je suis sûr que ça va motiver des contributeurs sur le cœur de l’engin.
Cgeek et Vit avaient le son, donc ça devait être de ton côté. Pas besoin de te drop de la chainspec, c’était surtout un moment symbolique. Mais de toute façon pour qu’on attende d’un forgeron de calculer des blocs, il faut qu’il exécute authority.goOnline et dans un premier temps, il n’y a que le sudo (elois) qui pourra le faire. Donc pas de problème pour qu’on garde ton identité membre et forgeron et que tu ajoutes ton nœud plus tard même en mode validateur !
