Python - Comprehension Lists

Dans le top 10 des raisons d’aimer Python se hisse aisément les listes en intension, ou “comprehension lists” pour les gens branchés.

Rappel du concept, et un petit tour complet de ce qu’on peut en faire. Les connaisseurs attendront le second article qui aborde des notions avancées, et contiendra quelques bonus.

On continue de ressusiter les articles de Sam et Max tout en se formant ? C'est parti !

La boucle for​

Disclaimer: pour comprendre ce petit gros article, il faut être à l’aise avec la boucle for et les listes.

En Python, on itère beaucoup, c’est à dire qu’on applique très souvent un traitement à tous les éléments d’une séquence, un par un. Et pour ça il y a la boucle for:

sequence = ["a", "b", "c"]
for element in sequence:
    print(element)
# a
# b
# c

Et très souvent, on fait une nouvelle liste avec les éléments de la première liste, mais modifiés:

sequence = ["a", "b", "c"]
new_sequence = []
for element in sequence:
    new_sequence.append(element.upper())

print(new_sequence)
# ['A', 'B', 'C']

Les listes en intension: la base​

Cette opération – prendre une séquence, modifier les éléments un par un, et faire une autre liste avec – est très commune. Et comme pour à peu près tout ce qui est opération courante, Python possède une manière élégante de le faire plus vite.

Reliez bien le bloc précédent, il devient:

sequence = ["a", "b", "c"]
new_sequence = [element.upper() for element in sequence]
print(new_sequence)
# ['A', 'B', 'C']

Il n’y a aucun mystère, ce code fait exactement la même chose, mais:

new_sequence = []
for element in sequence:
    new_sequence.append(element.upper())

Est réduit à:

new_sequence = [element.upper() for element in sequence]

Ne cherchez pas un truc compliqué, c’est juste une question de syntaxe, ça fait la même chose, mais écrit différemment : à droite, la boucle, à gauche, ce que l’on veut mettre dans la liste finale.

Et c’est surtout beaucoup plus court.

Là où ça devient franchement sympa, c’est que l’on peut assigner le résultat d’une liste en intension directement à la variable originale:

sequence = ["a", "b", "c"]
new_sequence = [element.upper() for element in sequence]
print(new_sequence)
# ['A', 'B', 'C']

Devient alors:

sequence = ["a", "b", "c"]
sequence = [element.upper() for element in sequence]
print(sequence)
# ['A', 'B', 'C']

Et vous avez du coup un moyen très propre de transformer toute une liste. Listes en intension avancées

On peut faire bien plus avec les listes en intension. Python est un langage dynamiquement typé, donc on peut transformer carrément le type de liste.

sequence = [1, 2, 3]
print([str(nombre) for nombre in sequence])
# ['1', '2', '3']

On peut aussi faire des opérations un peu plus complexes:

sequence = [1, 2, 3]
print(['a' * nombre for nombre in sequence])
# ['a', 'aa', 'aaa']

Et même construire des sequences imbriquées à la volée:

sequence = [1, 2, 3]
print(list(range(5)))  # petit rappel de l'usage de la fonction range
# [0, 1, 2, 3, 4]

sequence = [(nombre, list(range(nombre))) for nombre in sequence]
print(sequence)
# [(1, [0]), (2, [0, 1]), (3, [0, 1, 2])]

print(sequence[-1])
# (3, [0, 1, 2])

print(sequence[-1][0])
# 3

print(sequence[-1][1])
# [0, 1, 2]

La syntaxe [expression for element in sequence] autorise n’importe quelle expression, du coup on peut créer des listes très élaborées, en utilisant tous les opérateurs mathématiques, logiques, etc, et toutes les fonctions que l’on veut. Filtrer avec les listes en intension

Une autre opération courante consiste à filtrer la liste plutôt que de la transformer :

nombres = range(10)
nombres_pairs = []
for nombre in nombres:
    if nombre % 2 == 0:  # garder uniquement les nombres pairs
        nombres_pairs.append(nombre)

print(nombres)
# [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

print(nombres_pairs)
# [0, 2, 4, 6, 8]

Évidement Python a également une syntaxe plus courte pour cela. Il suffit de rajouter la condition à la fin:

nombres = range(10)
print([nombre for nombre in nombres if nombre % 2 == 0])
# [0, 2, 4, 6, 8]

Toutes les expressions habituellement utilisables pour tester une condition sont également disponibles.

Bien sûr, rien ne vous empêche de filtrer ET de transformer la liste en même temps. En clair, un nouvel arrivant à Python fera ça:

nombres = range(10)
sommes = []
for nombre in nombres:
    if nombre % 2 == 0:
        somme = 0
        for i in range(nombre):
            somme += i
        sommes.append(somme)

print(sommes)
# [0, 1, 6, 15, 28]

Un codeur qui trouve ses marques fera ça:

sommes = []
for nombre in range(10):
    if nombre % 2 == 0:
        sommes.append(sum(range(nombre)))

print(sommes)
# [0, 1, 6, 15, 28]

Un pythoniste affranchi ira droit au but:

print([sum(range(nombre)) for nombre in range(10) if nombre % 2 == 0])

Bon, en vérité il fera plutôt:

[sum(range(nombre)) for nombre in range(0, 10, 2)]

Mais c’était pour l’exemple :-)

Les listes en intension ont encore plus à offrir, la suite au prochain article !

Il y a un blog que j'aimais farfouiller de temps en temps lors de mes débuts en python : Celui de Sam & Max, disparu aujourd'hui et plus accessible. Je me permets de resortir quelques archives qui m'ont aidé à l'époque, et qui pourront très probablement vous aider à votre tour.

L’unpacking

Dans ce premier d'une, je l'espère, longue série d'articles sur python, parlons d'une des 5 choses obligatoire à apprendre en python d'après feu le bog Sam&Max.

L’unpacking est une fonctionalité typiquement pythonienne qui permet de prendre un itérable (souvent un tuple), et de mettre ses éléments dans des variables d’une traite.

Cela permet d’augmenter drastiquement la lisibilité des programmes. Et chez Code Commun, on aime tout ce qui peut aider à rendre nos logiciels libre plus lisible.

Le principe de base​

Normalement, si vous voulez mettre le contenu d’un tuple dans des variables, vous devez procéder ainsi :

>>> ducks = ('riri', 'fifi', 'loulou')
>>> duck1 = ducks[0]
>>> duck2 = ducks[1]
>>> duck3 = ducks[2]
>>> print(duck1)
'riri'
>>> print(duck2)
'fifi'
>>> print(duck3)
'loulou'

L’unpacking, qu’on pourrait traduire par le terme fort moche de “déballage”, dans le sens “ouvrir un colis”, permet de faire la même chose, bien plus facilement :

>>> duck1, duck2, duck3 = ducks
>>> print(duck1)
'riri'
>>> print(duck2)
'fifi'
>>> print(duck3)
'loulou'

Il n’y a rien à faire, c’est automatique. La seule condition est que le nombre de variables à gauche du signe égal soit le même que le nombre d’éléments dans la collection de droite.

D’ailleurs, ça marche même avec un seul élément :

>>> ducks = ('riri',)
>>> duck1, = ducks # notez la virgule
>>> duck1
'riri'

Et ça marche avec n’importe quel itérable, pas uniquement les tuples. Avec une liste, une string, un générateur…

>>> a, b, c, d = [1, 2, 3, 4]
>>> c
3
>>> a, b = "12"
>>> b
'2'
>>> def yolo():
    yield "leroy"
    yield "jenkins"
...
>>> nom, prenom = yolo()
>>> nom
'leroy'
>>> prenom
'jenkins'

Ça marche bien entendu avec un dico ou un set, mais comme ils ne sont pas ordonnés, c’est pas très utile.

Astuces autour de l’unpacking​

On peut utiliser l’unpacking dans des endroits inattendus. Par exemple, pour échanger la valeur de deux variables :

>>> a = 1
>>> b = 2
>>> a, b = (b, a)
>>> a
2
>>> a, b = b, a # les parenthèses sont facultatives dans les tuples
>>> b
2

Puisqu’on est dans les tuples sans parenthèses, on peut retourner un tuple et donner l’illusion de retourner plusieurs variables :

>>> def duckmebaby():
...     return "rifi", 'filou', 'louri'
...
>>> et, hop, la = duckmebaby()
>>> et
'rifi'
>>> hop
'filou'
>>> la
'louri'

Allons plus loin.​

On peut utiliser l’unpacking à l’intérieur d’une boucle for. Souvenez vous que les itérables peuvent contenir d’autres itérables. Par exemple, j’ai une liste qui contient 3 tuples, chaque tuple contient deux éléments :

>>> scores = [('Monique', '3'), ('David', 10), ('Dick', 1)]
>>> for score in scores:
...     print(score)
...
('Monique', '3')
('David', 10)
('Dick', 1)

Si je veux afficher le nom et le score l’un en dessous de l’autre :

>>> for nom_et_score in scores:
...     print(nom_et_score[0])
...     print(nom_et_score[1])
...
Monique
3
David
10
Dick
1

Je peux appliquer l’unpacking dans la boucle pour rendre cette opération plus élégante :

>>> for nom, score in scores:
...     print(nom)
...     print(score)
...
Monique
3
David
10
Dick
1

Cela marche avec des itérables plus gros, bien entendu. C’est aussi particulièrement utile avec des dictionnaires car on peut les transformer en itérable de tuples :

>>> scores = {'Monique': '3', 'David': 10, 'Dick': 1}
>>> scores['Monique']
'3'
>>> scores.items() # transformation !
dict_items([('Monique', '3'), ('David', 10), ('Dick', 1)])
>>> for nom, score in scores.items():
...     print(nom)
...     print(score)
...
Monique
3
David
10
Dick
1

Tout aussi utile, mais plus compliqué, est l’usage de l’unpacking dans l’appel de fonction. Pour cela, on utilise l’opérateur splat, l’étoile en Python.

Soit une fonction qui additionne des nombres :

>> def add(a, b, c):
...     return a + b + c
...
>>> add(1, 2, 3)
6

Oui, imaginons que je suis complètement débile, et que j’ai cette fonction pérave dans mon code. Vous noterez dans les articles que je l’utilise souvent sur le blog. C’est la fonction fourre tout pour expliquer un truc quand j’ai pas d’idée.

Maintenant, imaginez que je veuille additionner des canards. Si, ça marche en Python :

>>> 'riri' + 'fifi' + 'loulou' # what the duck ?
'rirififiloulou'

Maintenant je me refais mon tuples de canards :

>>> # nous entrerons dans la bande à picsou, youhou
>>> duckyou = ('riri', 'fifi', 'loulou')

Si je veux utiliser ma fonction pourrie pour mon use case stupide, je ferai ceci :

>>> add(duckyou[0], duckyou[1], duckyou[2])
'rirififiloulou'

Voilà une perte de productivité intolérable, c’est pas comme ça qu’on va faire fructifier son sou fétiche.

On peut forcer l’unpacking avec l’étoile :

>>> add(*duckyou)
'rirififiloulou'

Si on oublie l’étoile, le premier paramètre reçoit tout le tuple, et les autres paramètres rien :

>>> add(duckyou)
Traceback (most recent call last):
  File "", line 1, in 
    add(1)
TypeError: add() missing 2 required positional arguments: 'b' and 'c'

Les fonctions ont même le droit à un bonus car on peut unpacker des dictionnaires en utilisant la double étoile. Ca ne marche qu’avec les fonctions, et ça va déballer le dico pour que chaque paire clé/valeur soit passée comme nom et valeur de l’argument :

>>> def pas_add(arg1, arg2):
    print(arg1)
    print(arg2)
...
>>> pas_add(arg1="Je suis la valeur 1", arg2="Je m'en branle de qui tu es")
Je suis la valeur 1
Je m'en branle de qui tu es
>>> dicocorico = {'arg1': 'cotcot', 'arg2': 'ouai je pête un cable, l\'avion me soule'}
>>> pas_add(**dicocorico)
cotcot
ouai je pête un cable, l'avion me soule

Quand on unpacke des paramètres, il faut s’assurer que le nombre d’arguments passé n’est pas supérieur à ceux existant, sinon ça plante :

>>> dicocorico = {'arg1': 'cocot', 'arg2': 'ouai je pête un cable, l\'avion me soule', 'dang': 'je suis en trop et ça fait chier tout le monde'}
>>> pas_add(**dicocorico)
Traceback (most recent call last):
  File "", line 1, in 
    pas_add(**dicocorico)
TypeError: pas_add() got an unexpected keyword argument 'dang'
>>> stuplet = (1, 2, 3)
>>> pas_add(*stuplet)
Traceback (most recent call last):
  File "", line 1, in 
    pas_add(*stuplet)
TypeError: pas_add() takes 2 positional arguments but 3 were given

Par contre, rien ne vous empêche de fournir moins d’arguments et de remplir les autres à la main :

>>> def encore_add(a, b, c, d):
    return a + b + 0 + c + d # je feinte
...
>>> encore_add(10, *stuplet)
16

Et on peut bien entendu faire le mega mix. Par exemple, prenons la fonction print, dont la signature accepte une infinité d’arguments positionnels et quelques arguments nommés :

print(value, ..., sep=' ', end='\n', file=sys.stdout, flush=False)

Aller, on va lui unpacker sa mère :

>>> ducks = ['riri', 'fifi', 'loulou'] # is this duck typing ?
>>> keywords = {'sep': ' / ', "end": " : vous êtes du coin ? \n"}
>>> print('picsou', *ducks, **keywords)
picsou / riri / fifi / loulou : vous êtes du coin ?

Ça c’est fait.

Python 3, c’est du chocolat​

En Python 3, l’unpacking a été amélioré, et on peut maintenant faire de l’unpacking partiel :

>>> # exemple 100% repompé d'un autre article du blog. Duck it.
>>> l = list(range(5))
>>> l
[0, 1, 2, 3, 4]
>>> a, *b = l
>>> a
0
>>> b
[1, 2, 3, 4]
>>> a, *b, c = l
>>> a
0
>>> b
[1, 2, 3]
>>> c
4

Ce qui peut être très pratique sur les longs itérables. Comment obtenir la dernière ligne d’un fichier ?

>>> *contenu, dernire_ligne = open('/etc/fstab')
>>> dernire_ligne
'UUID=0e8c3132-8fa2-46d5-a541-2890db9b371f none            swap    sw              0       0\n'

Ou alors, dans une boucle :

>>> for initiale, *reste in ducks:
    print(initiale)
...
r
f
l

Vous avez dit sauvage ?​

Un certificat "wildcard" C'est un certificat qui répond à tous les sous-domaines d'un domaine. Par exemple, si vous avez un certificat wildcard pour le domaine *.example.com, il sera valide pour foo.example.com, bar.example.com, prout.example.com, etc.

Vous voyez le * ? C'est un caractère joker, qui signifie "n'importe quoi". C'est pour cela qu'on appelle ça un certificat wildcard, un sauvage.

Pourquoi faire ? Ben c'est quand même 'achement pratique si on doit générer des sites en mode Saas, software as a service. TiBillet, par exemple, est construit en mode multi-tenant. Cela veut dire un noyau unique pour plusieurs instances fédérées. Chaque instance est un tenant, et chaque tenant possède son propre sous-domaine.

Dans le cas d'un déploiement en mode "logiciel à la demande", c'est à dire avec des instances créées automatiquement en quelques clics, avoir un seul certificat valide pour les adresses comme https//raffinerie.tibillet.re/ ou https://rezom.tibillet.re/ (notez le s de https), c'est quand même assez chouette, non ?

Let's Encrypt et Traefik, l'ultra combo.​

Pour convaincre Letsencrypt de nous donner un certificat wildcard, il faut faire un petit peu plus de chose que pour un certificat simple. En plus de lui prouver que nous avons bien la main sur le serveur qui répond à l'ip résolu par le nom de domaine, il faut ausi lui prouver que nous sommes les proprietaires de la totalité du domaine. Autrement dit : que nous avons les droits d'écritures de toute la zone DNS.

Pour cela, Letsencrypt va nous demander d'ajouter un champ TXT dans la zone DNS du domaine. Ce champ contient une clé créé par Letsencrypt, s'il arrive à le lire, il va donc considérer à raison que nous avons bien les droits d'écriture sur la zone DNS. Donc que nous sommes le proprio.

Le truc, c'est qu'un certificat doit se renouveller régulièrement, et que donc, il faut que ce champ TXT soit présent et différent à chaque renouvellement. Et on va pas se le cacher, c'est un peu contraignant et fastidieux de le faire à la main.

C'est la qu'intervient Traefik. Traefik est un reverse proxy, c'est à dire un serveur qui va rediriger les requêtes http vers le bon conteneur docker. Il est capable de faire plein de choses, mais ce qui nous intéresse ici, c'est qu'il est capable de gérer les certificats SSL, et même de renouveller automatiquement les widlcards.

Traefik et Letsencrypt fonctionnent merveilleusement bien ensemble. Le premier va poser la question au second, puis va modifier la zone DNS automatiquement pour que le champs TXT soit à jour régulièrement. Cela nécessite de donner les trois d'écriture à notre Zone à notre conteneur Traefik. Pas de soucis particuliers, l'instance Traefik est hebergé sur notre serveur, nous avons donc la main dessus..

Voyons comment mettre tout ça en place.

Prérequis​

• Un nom de domaine : Ici, nous allons voir la methode avec Gandi et avec OVH
• Docker ( et docker-compose ) : https://docs.docker.com/install/
• Traefik : https://docs.traefik.io/
  • Nous avons un dépot avec tout dedans : https://github.com/TiBillet/
• Un serveur ou heberger tout ça avec une ip statique et les ports 80 et 433 corectement redirigé. On utilise des VPS sous Ubuntu, mais ça marche aussi avec une autre distribution ou même un raspberry pi.

Installation​

Je vous invite à aller du coté d'une précédente note de blog qui détaille comment préparer votre serveur pour la suite : https://codecommun.coop/blog/sysadmin-mon-chaton-part1/

Une légère différence ceci, nous allons utiliser le fichier docker-compose.yml du dossier "wildcard" de notre dépot github Traefik : https://github.com/TiBillet/Traefik-reverse-proxy/tree/main/wildcard

Si vous avez déja lancé le docker-compose.yml de la note de blog, vous pouvez le stopper et le supprimer et utiliser celui-ci à la place.

Si vous n'avez de compte ni sous OVH ni chez Gandi, pas d'inquiétude, Traefik supporte beaucoup de registrar : https://doc.traefik.io/traefik/https/acme/?ref=j.hommet.net#dnschallenge

Commençons par créer un nouveau champ A vers l'ip de votre serveur, avec comme sous domaine *.

* 10800 IN A <IP>

Ensuite, allons générer une clé API pour donner les droits d'écriture dans cette zone à Traefik :

Avec OVH Cloud​

Comme nous le disions, nous allons avoir besoin de donner les droits d'écriture à Traefik. Il vous faut bien sur un compte ovh valide et avoir acheté un nom de domaine.

• Allez sur https://eu.api.ovh.com/createApp/

• Logguez vous, créez une nouvelle app et récuperez les cred'

• Dans le même dossier que le docker-compose, Créez un fichier .env et remplissez les deux premières variables avec les cred' récupérés précédemment.

OVH_APPLICATION_KEY=""
OVH_APPLICATION_SECRET=""
OVH_CONSUMER_KEY=""

• Lancez cette commande curl pour donner les droits de modification à l'application. Remplacez OVH_APPLICATION_KEY et VOTRE_DNS, avec vos propres valeurs.

curl -XPOST -H"X-Ovh-Application: <OVH_APPLICATION_KEY>" -H "Content-type: application/json" \
https://eu.api.ovh.com/1.0/auth/credential  -d '{
    "accessRules": [
        {
            "method": "POST",
            "path": "/domain/zone/<VOTRE_DNS>/record"
        },
        {
            "method": "POST",
            "path": "/domain/zone/<VOTRE_DNS>/refresh"
        },
        {
            "method": "DELETE",
            "path": "/domain/zone/<VOTRE_DNS>/record/*"
        }
    ],
    "redirection":"https://www.<VOTRE_DNS>/"
}'

Si vous n'avez pas curl, installez le. Sinon, vous pouvez aussi utiliser l'application en ligne de OVH. Je vous laisse découvrir par vous-même.

• Copiez le consumer_key et rentrez la variable correspondante dans le .env
• Validez la requete avec le lien envoyé dans la réponse. Pensez à mettre unlimited dans la durée des droits d'execution car Traefik renouvelle le widlcard tous les trois mois.

Avec Gandi.net​

Un ptit peu plus simple du coté de Gandi, il suffit de générer une clé API dans votre compte user / Authentication option / API key.

Dans votre .env, ajoutez la variable suivante :

GANDI_API_KEY="PLOUFPLOUFDEVINEMOI"

Décollage​

Completez votre .env avec EMAIL et DOMAIN, paske c'est le votre et pas le mien :

DOMAIN="pingoin-sauvage.coop"
EMAIL="tux42@pingoin-sauvage.coop"

Et voici le compose magique :

version: "3"
services:
  traefik:
    image: "traefik:saintmarcelin"
    container_name: "traefik_wild"
    restart: always
    command:
      - --log.level=DEBUG
      - --api.insecure=true
      - --providers.docker=true
      - --providers.docker.exposedbydefault=false

      - --entrypoints.web.address=:80
      - --entrypoints.web.http.redirections.entrypoint.to=websecure
      - --entrypoints.web.http.redirections.entrypoint.scheme=https

      - --entrypoints.websecure.address=:443
      - --entrypoints.websecure.http.tls=true
      - --entrypoints.websecure.http.tls.certResolver=letsencrypt
      - --entrypoints.websecure.http.tls.domains[0].main=${DOMAIN}
      - --entrypoints.websecure.http.tls.domains[0].sans=*.${DOMAIN}

      - --certificatesresolvers.letsencrypt.acme.dnschallenge=true
      - --certificatesresolvers.letsencrypt.acme.dnschallenge.provider=gandiv5
      - --certificatesresolvers.letsencrypt.acme.dnschallenge.delayBeforeCheck=60
      - --certificatesResolvers.letsencrypt.acme.dnsChallenge.resolvers=1.1.1.1:53,8.8.8.8:53
      - --certificatesresolvers.letsencrypt.acme.email=${EMAIL}
      - --certificatesresolvers.letsencrypt.acme.storage=/dnschallenge/acme.json

      - --certificatesresolvers.letsencrypt.acme.caserver=https://acme-staging-v02.api.letsencrypt.org/directory

    ports:
      - "80:80"
      - "443:443"
    environment: # choisissez votre provider. Gardez ceux de Gandi, ou ceux d'ovh, ou ceux indiqué par la doc Traefik.
      - "GANDIV5_API_KEY=${GANDIV5_API_KEY}"
      - OVH_APPLICATION_KEY=${OVH_APPLICATION_KEY}
      - OVH_APPLICATION_SECRET=${OVH_APPLICATION_SECRET}
      - OVH_CONSUMER_KEY=${OVH_CONSUMER_KEY}

    volumes:
      - "./dnschallenge:/dnschallenge"
      - "/var/run/docker.sock:/var/run/docker.sock:ro"

    networks:
      - frontend

networks:
  frontend:
    external: true

Attention ! Deux choses à noter :

Pour gandi, ne touchez pas la ligne suivante :

      - --certificatesresolvers.letsencrypt.acme.dnschallenge.provider=gandiv5

Pour OVH, ou pour un autre registrar, il faudra bien le changer :

        - --certificatesresolvers.letsencrypt.acme.dnschallenge.provider=ovh

C'est parti !​

# On lance le conteneur
docker compose up -d
# on check les logs
docker logs -f

Attendez quelques instants que les logs se calment, et allons tester tout ceci avec un conteneur de test.

version: "3"
services:
  whoami:
    image: "traefik/whoami"
    container_name: "simple-service"
    labels:
      - traefik.enable=true
      - traefik.docker.network=frontend
      - traefik.http.routers.whoami.tls.certresolver=letsencrypt
      - traefik.http.routers.whoami.tls.domains[0].main=${DOMAIN}
      - traefik.http.routers.whoami.tls.domains[0].sans=*.${DOMAIN}

      - traefik.http.routers.whoami.rule=HostRegexp(`{sub:[a-zA-Z0-9-]+}.${DOMAIN}`) || Host(`${DOMAIN}`)
      - traefik.http.routers.whoami.entrypoints=websecure

    networks:
      - frontend

networks:
  frontend:
    external: true

Notez la regex sur la règle DNS. Elle permet de matcher tous les sous-domaines de votre domaine. Sexy isn't it ?

Si tout ce passe bien, dans les logs de Traefik, vous devriez voir quelque chose comme ça :

 traefik_wild  | time="2023-11-08T16:40:36Z" level=debug msg="legolog: [INFO] [tibillet.coop] Server responded with a certificate."                                                            traefik_wild  | time="2023-11-08T16:40:36Z" level=debug msg="Certificates obtained for domains [tibillet.coop *.tibillet.coop]" providerName=letsencrypt.acme ACME CA="https://acme-v02.api.le
tsencrypt.org/directory"             

Si non, remontez bien les logs, le problème est forcément indiqué dedans.

En production ?​

Ahah ! Par ce que vous pensiez que c'était fini ?

Le compose de Traefik contien une petite astuce, nous avons utilisé le serveur de test de Letsencrypt. Pourquoi ? Eh bien le serveur de production qui génère de vrais certificats est soumis à une limite du nombre de demande.

Je l'ai découvert à mes dépens, en voulant tester un peu trop de fois mon système, j'ai dû attendre quelques heures pour pouvoir relancer un nouveau certificat... Le serveur de test nous permet par contre de se planter sans limite. J'adore.

Pour passer en production, lorsque les logs du conteneur traefik vous indiqueront que tout roule, il suffit de commenter la ligne suivante :

#      - --certificatesresolvers.letsencrypt.acme.caserver=https://acme-staging-v02.api.letsencrypt.org/directory

Et hop, relancer en mode daemon :

docker compose up -d

Enfin, re-lancez le conteneur whoami et vérifier qu'il matche bien. Remplacez bien sur le DNS par le votre, lancez le conteneur, et allez vérifier sur votre navigateur que le certificat est valide pour tout les sous-domaines que vous souhaitez (https://patate.votre_dns , https://prout.votre_dns, etc...)

Si ça coince, rechargez, videz vos certifs auto générés, et enfin regardez les logs Traefik, ce dernier vous signalera forcement le problème dans un message d'erreur.

Sources et liens utiles :​

• https://doc.traefik.io/traefik/user-guides/docker-compose/acme-dns/
• https://www.grottedubarbu.fr/traefik-dns-challenge-ovh/
• https://j.hommet.net/traefik-certificat-ssl-wildcard-letsencrypt/

Préambule​

Dans la Coop', on pense que ça ne sert à rien de faire du logiciel libre si on explique pas pourquoi et comment. Donc premier effort à fournir : de la documentation et de la vulgarisation.

On commence par un chantier participatif ? Tous les lundi : cod' ensamb !

L'idée : Recoder tout le projet LaBoutik (Caisse enregistreuse, cashless, monnaie locale, etc... pour en savoir plus : https://tibillet.org).

Étape par étape, comme un grand tutoriel géant, nous allons détailler pourquoi et comment nous le construisons.

Le but avoué est d'encourager les contributions aux projets de la coopérative, de réduire le flou technologique, de vulgariser le code, mais surtout de s'engager dans une démarche de partage de savoir.

Koi fé ? (TLDR;)​

Dans ce tuto, nous allons voir comment :

• Préparer son environnement de développement python avec Poetry
• Configurer l'IDE de Jetbrain, Pycharm, pour qu'il nous facilite la vie
• Installer Django 4.2
• Créer ses premiers objets en base de donnée
• Créer une interface d'admin pour les créer et les manipuler

Codons le logiciel de caisse enregistreuse "LaBoutik" depuis zero

La "stack" :​

Autrement dit, l'ensemble des librairies, framework (cadriciel) et outils divers pour construire notre solution.

• Linux (ubuntu/debian) quoique, on pourrait installer la stack sur windows et mac, mais on va le faire paske faut bien choisir.
• Python 3.10
• Poetry (outil de gestion d'environement python qui sert à maintenir nos versions à jour et nous assurer que les librairies n'aient pas d'incompatibilité entre elles )
• Django 4.2

Et bien sur notre IDE préféré qui nous facilite grandement la tache : Pycharm (https://www.jetbrains.com/fr-fr/pycharm/)

Le dépot GIT​

Travaillons sur le dépot : https://github.com/CoopCodeCommun/LaBoutik-CodEnsamb

Installons Poetry​

• https://python-poetry.org/docs/

curl -sSL https://install.python-poetry.org | python3 -
git clone git@github.com:CoopCodeCommun/LaBoutik-CodEnsamb.git

### Sur Mac :
brew install poetry

Une fois le poetry installé et le repos git crée. On peut initialiser le poetry. A La racine du projet :

poetry init

Répondez aux questions en vérifiant
Compatible Python versions ^3.10 : laissez par defaut . Pour les question concernant les dépendances , répondez No ( nous les installerons nous meme )

Vous avez maintenant un fichier pyproject.toml dans votre projet qui reprend tous les paramétres saisis . Ouvrez ce fichier , vous pouvez ici entrer les dépendances que vous sohaitez dans la section [tool.poetry.dependencies]:

Le ^ indique version minimun Nous allons ajouter Django en ligne de commande en figeant la version à l'aide de @ ( à ce jour Octobre 2023 la version stable est : 4.2) :

poetry add django@4.2

Ce qui à pour effet d'installer aussi les dépendances necessaires pour le projet et de créer le fichier poetry.lock qui est l'état actuel de notre projet .

Si vous avez cloné le projet , les 2 premières étapes poetry init et poetry add django@4.2ne seront pas necessaire .( elles le sont uniquement si vous partez de zéro * )

Maintenant entrons et travaillons dans l'environement virtuel qui nous permet d'avoir le meme environement de travail quelque soit l' OS utilisé :

poetry shell

Installons et configurons Django​

Créons le projet (l'application)

    django-admin startproject laboutik .
    // le point '.' est utilisé pour que la racine du project soit dans le dossier dont on est situé
    ./manage.py startapp labutik_core
    

idem( * ) les 2 premières commande ci dessus ne sont plus necessaires si vous avez cloné le projet .

Dans laboutik/settings.py on ajoute:

    INSTALLED_APPS = [
    ...,
    'laboutik_core',
    ]
    
    AUTH_USER_MODEL = 'laboutik_core.CustomUser'

Dajngo à besoin d'une BD, nous allons la créer :

./manage.py migrate

on voit une nouvelle base de données dans notre projet :

et dans le fichier settings :

Pour le moment nous laissons sqlite3, nous changerons plus tard en Production vers une DB plus adaptée .

Lançons le serveur :

./manage.py runserver

Maintenant en vous connectant à l'adresse : http://127.0.0.1:8000/ vous devriez avoir la page ci dessous :

Vous avez maintenant dans votre projet 2 nouveaux répertoires laboutik et laboutik_core et le fichier racine manage.py :

Configurons Pycharm​

Pour l'instant nous n'avons pas indiqué à Pycharm notre environement . Il faut lui indiquer que nous travaillons avec Python3.10 , Poetry et Django . Configurons l'interpreteur , dans settings de Pycharm :

Add interpreter/Local/Poetry environement :

Dans "Poetry executable" indiquez le chemin d'installation de poetry installé precedemment .

Vérifions la configuration pour Django :

Du coup maintenant Pycharm va nous alerter en cas d'erreur de syntaxe , proposer de l'auto-complétion ... trop top 👍

Merci à JetBrains de nous supporter pour nos projets . Pour tester si notre IDE a bien compris notre environement de travail , allez dans le fichier urls.py placer le curseur sur "path" et faites F12 . Vous devriez etre redirigé vers le fichier conf.py .

Remarque pour Mac : le raccourcis clavier est "fn + F12" si cela ne fonctionne pas modifiez le model Keymap sur " sublime Text Copy"

Modele user​

La création d'un model user custom est fortement conseillé dès le début du projet. Dans le futur il devient très compliqué de modifier le modele user une fois nos modeles sont lancés.

Dans le fichier models.py :

from django.db import models
from django.contrib.auth.models import AbstractUser
from uuid import uuid4

class CustomUser(AbstractUser):
    """
    Modèle de base pour les utilisateurs
    On utilise des uuid4 plutôt que des pk auto-incrementés
    """
    uuid = models.UUIDField(primary_key=True, default=uuid4, editable=False, db_index=False)

Dans le fichier settings.py :

# Model user custom
AUTH_USER_MODEL = 'laboutik_core.CustomUser'

On applique les modifications en faisant une migration :

./manage.py makemigrations
./manage.py migrate

Architecture rapide du projet​

Listons les "objects" dont nous allons avoir besoin.

• Configuration
• Point de vente
• Catégories
  • Produit
    • TVAs
  • Prix
• Users
  • droits
• Moyens de paiement
• Ventes

Codons nos objets :​

Dans le fichier models.py :

TODO: Vidéo sur https://peertube.communecter.org

Le detail du codage en Live ici

Création du modèle de base de donnée et d'administration​

Routage url​

le fichier urls.py

il existe déja l'url de l'admin:

urlpatterns = [
    path('admin/', admin.site.urls),
]

Lancement du serveur :

./manage.py runserver
-> Starting development server at http://127.0.0.1:8000/

Du coup, si je vais dans http://127.0.0.1:8000/admin/

Administration Django​

Créons notre utilisateur admin.

# Création du super user "root"
./manage.py createsuperuser

Attention, createsuperuser fabrique des users avec is_staff = True ET is_superuser = True Seul is_staff est nécéssaire pour acceder à l'admin. is_superuser est comparable à un utilisateur "ROOT" qui a tout les droits sur l'admin.

Enregistrer les modèles dans l'admin :

# laboutik_core/admin.py
from django.contrib import admin
from laboutik_core.models import Product, Price, VAT, Category, PointOfSale

# Register your models here.

admin.site.register(Product)
admin.site.register(Price)
admin.site.register(VAT)
admin.site.register(Category)
admin.site.register(PointOfSale)

TODO: Uploader dans peertube La vidéo complete en detail ici

Conclusion​

Nous avons maintenant notre environnement installé et nous pouvons créer des objets en base de donnée.

Dans les prochaines sessions, nous verrons comment créer notre "frontend" avec les templates Jinja, et comment rendre cette stack "MVT" moderne avec HTMX.

Nous allons détailler ici la préparation d'un serveur sous distribution Debian (ou Ubuntu) pour acceuillir toutes nos solutions libres que nous proposons dans la coopérative.

Préparation du système​

Mises à jour du système​

sudo apt update
sudo apt upgrade -y
sudo reboot

Sécuriser le serveur​

Connexion SHH par clé​

# Depuis votre ordinateur client
ssh-copy-id <user>@<ip>
# ou ajouter votre cle id_rsa.pub directement sur le serveur 
nano .ssh/authorized_keys 

Changer le port d'écoute du service SSH et obliger la connexion via clé ssh​

sudo nano /etc/ssh/sshd_config
# Port 22
Port 2252 # choisissez un port entre 1024 et 65535

# On en profite pour autoriser l'agent forwarding
# Cela sera trés utile pour pull/push des dépots git avec sa propre identité
# plutôt que celle du serveur.
AllowAgentForwarding yes

# Pour encore plus d'efficacité, on force la clé ssh.
# L'user n'en sera que plus reconnaissable, avec sa clé et son agent
# Attention à bien backuper votre clé. Si vous la perdez, vous perdez la main sur le serveur.

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
#PermitEmptyPasswords no

Attention, sur les serveurs VPS Ovh, un fichier de conf' ssh se cache dans le dossier /etc/ssh/sshd_config.d/ et permet la connexion via mot de passe. C'est utile pour la première connexion, mais ^ensez à le supprimer si vous voulez forcer la connexion par clé.

On recharge le daemon ssh :

sudo service sshd reload

Installer Crowdsec​

Crowdsec est une solution open source très utile pour gérer la sécurité de votre serveur. Il utilise une liste de banissement d'ip géré par la communauté, surveille les iptables, et peut même s'interfacer avec un reverse proxy pour surveiller les requetes http. Plus d'info ici :

• https://www.crowdsec.net/
• https://plugins.traefik.io/plugins/6335346ca4caa9ddeffda116/crowdsec-bouncer-traefik-plugin

Avant d'installer la solution, il est nécéssaire de créer un compte gratuit sur leur site.

curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.deb.sh | sudo bash
sudo apt-get install crowdsec
sudo apt install crowdsec-firewall-bouncer-iptables

Allez sur l'interface Crowdsec et générez votre token d'invitation :

• https://app.crowdsec.net/security-engines

Une commande du type suivant vous sera proposé :

sudo cscli console enroll ****

Lancez la, puis accepter l'invitation sur l'interface web.

Rebootez le serveur.

Installation des dépendances​

Mes ptits softs que j'aime utiliser :

sudo apt update
sudo apt install git byobu htop borgbackup

Docker :​

• https://docs.docker.com/engine/install/ubuntu/

# Un script d'installation est disponible, si vous ne voulez pas le faire a la main.
curl -fsSL https://get.docker.com -o get-docker.sh
# Attention ! Vérifiez toujours le contenus des scripts téléchargé avant de les lancer en sudo ! 
sudo sh get-docker.sh
# Ajoutez votre utilisteur au groupe docker
sudo usermod -aG docker $USER

Relancez une nouvelle session utilisateur pour prendre en compte les changements de groupes et vérifiez que vous avez bien les droits :

docker ps

Traefik​

Traefik est un service de reverse proxy. C'est lui qui gère la redirection du conteneur depuis votre DNS et qui s'occupe du chiffrement HTTPS grâce à la formidable initiative de lets'encrypt.

Pour le faire tourner, vous devez avoir un nom de domaine qui pointe vers l'ip de votre serveur. Ajoutez un champ A sur votre admin DNS.

#clonez le dépot
git clone git@github.com:TiBillet/Traefik-reverse-proxy.git
cd Traefik-reverse-proxy
# Creez le sous réseau "frontend" commun
docker network create frontend
# Lancez les conteneur en mode daemon
docker compose up -d
# Vérifiez que le conteneur tourne et qu'il écoute bien les ports 80 et 443 :
docker ps

CONTAINER ID   IMAGE               COMMAND                  CREATED         STATUS         PORTS                                                                    NAMES
7f27255b935a   traefik:chevrotin   "/entrypoint.sh --lo…"   5 seconds ago   Up 4 seconds   0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp traefik

Testons Traefik :​

Lançons un conteneur de test pour savoir si tout tourne bien :

cd Traefik-reverse-proxy/test_conteneur
cat "DOMAIN=localhost" > .env # créons un fichier .env qui sera lu par compose
docker compose up

Si vous allez dans https://test.localhost, vous devriez voir une page whoami !

Si vous avez un DNS qui pointe vers l'ip de votre serveur, changez le .env en conséquence pour avoir une connexion chiffrée en TLS !

Conclusion

Et Hop ! Notre serveur est prêt pour acceuillir tous nos services futurs. Dans un prochain article, nous allons voir comment installer Traefik en mode Wildcard pour le moteur TiBillet d'adhésion, de reservation et d'agenda fédéré !

• Auteur : Framatophe, Membre du conseil d'administration de Framasoft
• Article original : Logiciel libre et anarchisme – Framablog

Le logiciel libre n’est pas exempt de causer [un] effet de domination ne serait-ce parce que les rapports aux technologies sont rarement équilibrés. On a beau postuler l’horizontalité entre concepteur et utilisateur, ce dernier sera toujours dépendant, au moins sur le plan cognitif. Dans une économie contributive idéale du Libre, concepteurs et utilisateurs devraient avoir les mêmes compétences et le même degré de connaissance. Mais ce n’est généralement pas le cas et comme disait Lawrence Lessig, « Code is law »

[...]

L’équilibre peut alors être trouvé en créant des chaînes de confiance, c’est-à-dire des efforts collectifs de création de communs de la connaissance (formations, entraide, vulgarisation) et des communs productifs : des organisations à tendances coopératives et associatives capables de proposer des formules d’émancipation pour tous. Créer du Libre sans proposer de solutions collectives d’émancipation revient à démontrer que la liberté existe à des esclaves enchaînés tout en les rendant responsables de leurs entraves.

• Auteur : Sam et Max, Bloggeur français à propos de Python, Django, Linux, Open Source, Free Software, etc.
• Article original : Hacker News

Je suis heureux de constater que les approches minimalistes, comme svelte, htmx et alpine.js sont de plus en plus prisées.

J'ai eu l'impression de me battre seul pendant les années dorées de node, webpack et react où tout le monde créait des piles folles et ajoutait GraphQL et ainsi de suite, pour essentiellement obtenir ce que Django + jquery ont fait il y a 10 ans en un dixième du temps et du code.

Jusqu'à présent, j'ai également survécu [à ces déclarations ]:

• xml est l'avenir
• utilisons nosql pour toutes les choses
• il faut utiliser le même langage pour le back comme pour le front
• oui, votre site doit avoir une version AMP (ah, vous l'avez oubliée celle-là, n'est-ce pas ? C'était tellement important, et puis pouf, c'est parti comme une larme sous la pluie)
• oui, votre page d'accueil doit être une SPA
• vous ne pouvez rien coder sans async
• vous ne pouvez pas vivre sans une file d'attente de messages
• tout doit devenir un micro-service
• bien sûr, vous avez besoin d'un conteneur pour cela
• il faut bien sûr un orchestrateur pour organiser ces conteneurs
• bien sûr, vous avez besoin du nuage, il serait insensé de s'occuper soi-même de ces conteneurs et de ces orchestrateurs
• Hey, pourquoi as-tu un serveur ? Utilise un backend sans serveur !
• Hey, pourquoi as-tu un backend ? Il suffit de l'appeller depuis une plateforme Saas !

Chaque année, une génération d'ingénieurs doit apprendre les concepts suivants : "il n'y a pas de solution miracle", " utilisez la bonne technologie pour le bon problème", "vous n'êtes pas Google", "réécrire une base de code tous les deux ans n'est pas une bonne décision commerciale", "les choses coûtent de l'argent".

TLDR :​

Libérez vous de la pression qu'apporte le Javascript partout. Lorsque vous utilisez une approche hypermédia pour votre application web, vous êtes libre de choisir la technologie côté serveur qui correspond le mieux à votre problème et à vos goûts techniques.

Préalable.​

Nous souhaitons à travers ce blog partager des articles, des tips, des philosophies ou des idées qui ont un rapport de près ou de loin avec les projets de la coopérative.

Je vais donc commencer par un concept que je découvre récemment (depuis un an ou deux.) et dont j'aime discuter : la " pile HOWL".

HOWL est l'acronyme de Hypermedia On Whatever you'd Like.

La suite est une traduction de l'article de Carson Gross : HOWL: Hypermedia On Whatever You'd Like

Si le sujet vous intéresse, je vous invite vous balader sur les sites suivant, il y a plein de concepts intéressants à découvrir.

• https://hypermedia.systems/
• https://htmx.org/essays/
• https://hyperscript.org/

Hypermedia partout​

Carson Gross May 23, 2023

Le seul grand avantage restant des MPAs est le choix du langage de programmation côté serveur. Si vous faites déjà partie de la résistance anti-JavaScript, alors rien de ce que je dirai dans le reste de cet exposé n'aura d'importance. Mais j'y reviendrai plus tard : ce bateau a peut-être coulé...

Rich Harris - Les SPA ont-ils ruiné le Web ?

Un concept dont nous aimons parler est celui de la "pile HOWL". HOWL est l'acronyme de Hypermedia On Whatever you'd Like.

En résumé, la pile HOWL est la suivante : lorsque vous utilisez une approche hypermédia pour votre application web, vous êtes libre de choisir la technologie côté serveur qui correspond le mieux à votre problème et à vos goûts techniques.er server-side technology best fits your problem and your own technical tastes.

La pression du JavaScript​

Si vous décidez d'utiliser un framework SPA pour votre application web, vous aurez naturellement une large base de code front-end écrite en JavaScript.

Dans ces conditions, la question suivante se posera inévitablement :

"Pourquoi ne faisons-nous pas aussi le back-end en JavaScript ?"

C'est une question raisonnable et il y a beaucoup d'avantages à adopter le même langage de programmation des deux côtés du fil :

• Vous pouvez partager la logique d'application entre les deux bases de code. La logique de validation en est un bon exemple.
• Vous pouvez partager des structures de données entre les deux bases de code.
• Vous pouvez acquérir une expertise dans un seul langage, JavaScript, ce qui permet aux développeurs de travailler plus facilement sur les différentes parties de votre application.
• Vous pouvez réutiliser le système de construction et les connaissances en matière de gestion des dépendances que vous avez acquises pour la partie frontale.

Cette pression en faveur de l'adoption de JavaScript ne fera que croître au fur et à mesure que votre investissement dans l'écosystème JavaScript augmentera.

En outre, JavaScript s'est considérablement amélioré au cours des cinq dernières années et il existe aujourd'hui plusieurs excellents applications côté serveur pour l'exécuter. Bon nombre des anciens arguments concernant le désordre du langage peuvent être écartés car ils peuvent être évités grâce au linting, à la discipline des développeurs, etc.

JavaScript est le langage dominant parmi les leaders d'opinion en matière de développement web et il existe un grand nombre de tutoriels, de code camps, etc. qui mettent fortement l'accent sur ce langage. Rien ne réussit mieux que le succès, et JavaScript (ainsi que React) a réussi.

Appelons le résultat de cette situation la pression JavaScript et reconnaissons que presque tous les développeurs travaillant dans le web la ressentent au moins dans une certaine mesure.

Hypermedia : Notre seul espoir​

Quel espoir les développeurs non-JavaScript ont-ils dans le développement web ?

Eh bien, il existe une technologie plus ancienne utilisé dans les navigateurs : l'hypermédia.

Les navigateurs offrent un excellent support HTML (et le Document Object Model, ou DOM). En fait, même si vous utilisez un framework SPA, vous travaillerez avec cette infrastructure hypermédia sous une forme ou une autre (via des modèles JSX, par exemple), ne serait-ce que pour créer des interfaces utilisateur qu'un navigateur peut comprendre.

Vous utiliserez donc HTML ou les API DOM connexes d'une manière ou d'une autre dans votre application web.

Et si nous faisions de HTML un hypermédia plus puissant ?

C'est l'idée de htmx, qui permet de mettre en œuvre des modèles d'application web modernes courants en utilisant l' approche hypermédia. Cela comble le fossé entre les MPA et les SPA traditionnelles, en rendant possible l'adoption de l' approche hypermédia pour un nombre beaucoup plus important d'applications web.

Une fois que vous avez adopté cette approche hypermédia (et rappelez-vous que vous allez de toute façon utiliser l'infrastructure hypermédia, alors pourquoi ne pas l'exploiter autant que possible ?), un effet secondaire surprenant se produit :

Soudain, l'avantage du choix du langage côté serveur que Harris attribuait aux MPAs est de nouveau d'actualité.

Si l'interface de votre application est principalement écrite en termes de HTML, avec peut-être un peu de script côté client, et sans grande base de code JavaScript, vous avez soudainement diminué de façon spectaculaire (ou entièrement éliminé) la pression JavaScript au niveau de l'interface.

Vous pouvez désormais choisir le langage (et le cadre) côté serveur en fonction d'autres considérations : techniques, esthétiques ou autres :

• Peut-être travaillez-vous dans le domaine de l'IA et souhaitez-vous utiliser une variante Lisp pour votre projet ?
• Peut-être travaillez-vous dans le domaine du big data et souhaitez-vous utiliser Python ?
• Vous connaissez peut-être très bien Django et vous aimez l'approche "batteries-included" qu'il adopte.
• Peut-être préférez-vous Flask et l'approche dépouillée qu'il adopte ?
• Peut-être aimez-vous l'aspect brut et proche du HTML de PHP ?
• Vous avez peut-être une base de code Java existante qui a besoin d'être améliorée.
• Peut-être que vous apprenez Cobol, et que vous voulez utiliser htmx pour en faire une interface agréable.
• Peut-être aimez-vous vraiment Rust, Ocaml, Kotlin, Haskell, .NET, Clojure, Ada, ColdFusion, Ruby... peu importe !

Il s'agit là de points de vue techniques, philosophiques et esthétiques tout à fait raisonnables.

Et, en adoptant l'hypermédia comme principale technologie front, vous poursuivez tous ces objectifs sans avoir recours à une double base de code. L'hypermédia ne se soucie pas de ce que vous utilisez pour le produire : vous pouvez utiliser l'hypermédia sur ce que vous voulez. HOWL !

Un Web ouvert à tous​

Et quand nous disons "tout le monde", nous le pensons vraiment.

Voici une capture d'écran de la sous-section HOWL du discord htmx récemment. Notez qu'il ne s'agit que des canaux qui ont un trafic actif, il y en a beaucoup d'autres.

Vous pouvez voir que nous avons des conversations en cours dans un tas de langages de programmation et de frameworks différents : Java, Go, .NET, Rust, Clojure, PHP, Ruby, Python, Ocaml. Nous avons même des gens qui parlent de l'utilisation de htmx avec Bash et Cobol !

C'est exactement l'avenir que nous voulons voir : un Web riche et dynamique dans lequel chaque langage et cadre d'arrière-plan peut jouer le rôle d'une alternative intéressante. Chaque langage et framework possède ses propres forces et propres cultures et chacun peut contribuer au système hypermédia magique qu'est le Web.

Mais... S'agit-il d'une résistance anti-JavaScript ?​

Avant de terminer cet essai, nous voulons aborder l'idée que la résistance à JavaScript partout est nécessairement anti-JavaScript.

Il est vrai que nous avons eu notre part de blagues sur JavaScript et que nous sommes allés jusqu'à créer un langage de script alternatif pour le web, l'hyperscript.

On pourrait donc penser que nous devrions être des anti-javascripteurs patentés.

Mais, au contraire, nous apprécions profondément JavaScript.

Après tout, htmx et hyperscript sont tous deux construits en JavaScript. Nous n'aurions pas pu créer ces bibliothèques sans JavaScript qui, quoi qu'on en dise, a le grand mérite d'être là.

Nous allons même jusqu'à recommander l'utilisation de JavaScript pour les besoins de scripts frontaux dans une application hypermédia, à condition que vous scriptiez d'une manière adaptée aux hypermédias.

De plus, nous ne déconseillons pas l'utilisation de JavaScript (ou TypeScript) côté serveur pour une application hypermédia, si ce langage est la meilleure option pour votre équipe. Comme nous l'avons dit précédemment, JavaScript dispose aujourd'hui de plusieurs excellents runtimes côté serveur et de nombreuses excellentes bibliothèques côté serveur.

C'est peut-être la meilleure option pour vous et votre équipe, et il n'y a aucune raison de ne pas l'utiliser.

Hypermedia On Whatever you'd Like signifie exactement cela : ce que vous voulez.

Mais JavaScript n'est pas, et ne devrait pas être, la seule option côté serveur pour votre équipe.

Le grand retournement​

Avec la résurgence de l'intérêt pour les hypermédias (et leur amélioration), un avenir ouvert et diversifié pour le Web est désormais une possibilité réelle, voire une réalité émergente.

Le Web a été conçu pour être un système hypermédia ouvert, polyglotte et participatif.

Et ce rêve n'a pas encore pris fin, du moins pas encore !

Nous pouvons maintenir ce rêve en vie en réapprenant et en adoptant la technologie fondamentale du web : l'hypermédia.

Tout l'équipe de la Coopérative Code Commun vous souhaite la bienvenue sur notre blog !

Aussi, nous migrons les articles du blog originalement postés sur https//tibillet.org/blog ici.

Note d'intention​

Nous souhaitons à travers ce blog partager des articles, des tips, des philosophies ou des idées qui ont un rapport de près ou de loin avec les projets de la coopérative.

Vous trouverez donc dans ce blog des citations, des traductions d'articles, des notes personnelles, des tutoriels, des recettes de création de logiciel libre... Bref, tout ce qui peut encourager le partage de connaissances, la transmission de savoir, et la diffusion de la culture libre.

Et si tout ceci vous donne envie de venir contribuer à nos projets, voire même à ce blog, génial ! Venez discuter avec nous ( checkez les liens dans le bas de page ) !

Historique et origine​

A l'origine du projet de la Coopérative, il y a TiBillet, le Manapany Festival et l'association organisatrice : Les 3Peaks. Nous étions une bande de joyeux.ses bidouilleur.ses.s et développeur.ses.s bénévoles. Nous avions décidé de créer nos propres outils numériques principalement pour une raison : nous avions envie d'apprendre à le faire nous même :)

En dehors du festival annuel, l'association hébergeait un café associatif ouvert régulièrement et organisait des évènements culturels mensuels avec une contrainte : si l'entrée était libre à tous et toutes, il nous fallait un outil pour gérer les adhésions associatives et les paiements des consommations. Pourquoi ne pas continuer à utiliser la carte NFC cashless du festival tout au long de l'année ?

En même temps, nous regardions comment les solutions existantes des professionnels du secteur fonctionnaient : Carte et bracelets NFC à usage unique, remboursement limité dans le temps, prix prohibitif pour l'organisateur et le public... Nous ne voulions vraiment pas reproduire un modèle qui semblait être juste un moyen de faire payer plus les festivaliers...

Voici que la carte d'adhésion 3Peask est née : Valide à vie, gratuite, rechargeable en ligne, remboursable à tout moment, utilisable au café associatif toute l'année comme au festival, elle permettait de gérer un point de vente et une caisse enregistreuse tout en s'assurant que le membre associatif était à jour de sa cotisation.

Et ça a cartonné ! Avoir plus de 800 membres à l'année fut une expérience très enrichissante. Nous développions TiBillet au fur et à mesure des besoins, des remarques et des idées de nos membres : nous codons un outil que nous utilisons au quotidien.

Aujourd'hui (Juin 2023), après 6 ans de développement, la carte TiBillet permet beaucoup de choses, et nous avons décidé de monter notre équipe en coopérative pour péréniser et rassembler autour de ce projet.

Et bien tout ceci, c'est ce que l'on va tenter de vous raconter dans ce blog. Nous allons essayer de vous expliquer ce que nous faisons, comment nous le faisons, pourquoi nous avons fait comme ça et tout ce qui nous motive !

A très vite !

TiBillet/FEDOW : FEDerated and Open Wallet.

C'est quoi FEDOW ?​

Résumé :

Outil FLOSS de création et de gestion d'un groupement de monnaies locales, complémentaire et citoyenne (MLCC) au sein d'un réseau fédéré.

S'intégrant aux outils TiBillet il permet l'utilisation de portefeuilles dématérialisés dans différents lieux associatifs, coopératifs et/ou commerciaux.

Enfin, Fedow intègre des principes de monnaie fondantes dans une chaine de block par preuve d'autorité, transparente, non spéculative et non énergivore.

Code source et documentation technique publiés sous licence AGPLv3 :​

https://github.com/TiBillet/Fedow

Manifeste pour l'appropriation d'une économie locale, sociale et solidaire.​

Moteur libre et open-source de gestion de monnaies temps et/ou locale.​

Parce qu'une banque peut être un logiciel libre : Nous n'avons pas besoin de blockchain spéculative, de NFT, DeFi ou Dapp ou de tout autre battage techno-solutionniste.

Tout ce dont nous avons besoin, c'est d'un moteur de création monétaire, de gestion de compte et de transactions. Le tout sous une gestion fédérée et transparente, pour créer des réseaux de points de vente acceptant des monnaies locales, des monnaies temporelles ou même des monnaies qui ne sont pas des monnaies.

Un outil simple pour créer une petite banque à l'échelle d'un petit ou d'un grand territoire et soutenir une économie locale, sociale et inclusive.

Pourquoi ?​

Chez Code Commun (la coopérative numérique qui développe l'écosystème TiBillet), nous pensons que le logiciel libre couplé à des pratiques de gouvernance ouverte et transparente pour une économie sociale et solidaire sont les conditions d'une société que nous souhaitons voir émerger.

Avec Fedow, qui s'inscrit dans l'écosystème TiBillet, nous souhaitons permettre à chacun de créer ou rejoindre une fédération de monnaies locale ou temps et de participer à sa gouvernance.

Nous ne croyons pas aux solutions technologiques promises par le Web3 : Blockchains énergivores, création de valeur sur du vide, bulles spéculatives, marchés d'échanges dérégulés, gourous milliardaires… Autant de promesses populistes d'empuissancements non tenues au service d'une économie ultra-libérale de la rareté et de la spéculation.

Ceci dit, nous ne jetons pas le bébé avec l'eau du bain.

Nous pensons que les entreprises humaines, coopératives et locales peuvent (doivent ?) être soutenues par des outils numériques libres pour construire des structures bancaires locales et coopératives au service d'une économie réelle.

Nous pensons que les technologies de blockchain peuvent aider en garantissant la sécurité, la transparence et la gouvernance partagée : The code we own is law.

Nous souhaitons construire Fedow dans ce sens : un outil numérique simple et compréhensible par chacun pour une économie réelle, non spéculative et transparente.

L'économie réelle et la blockchain éthique​

Imaginons un livre de compte tenu par tous les acteurs d'une coopérative.

Dans ce livre de compte, chaque acteur peut créer sa propre monnaie et peut (ou non) l'échanger à un taux fixe avec les autres monnaies de la coopérative.

Une monnaie fédérée à l'ensemble des acteurs est créée, indexée sur l'euro pour que chaque monnaie puisse s'échanger et servir à l'économie réelle des biens et services.

D'autres type de monnaies non indexée sur l'euro peuvent être créées : Monnaie temps pour s'échanger des services ou valoriser le bénévolat, monnaie "cadeau" pour analyser les stocks offerts, monnaie "ticket resto" pour gérer des repas des invités, et même monnaie "libre" compatibles avec d'autres systèmes comme la June.

Couplés au reste des outils de TiBillet, il est alors possible de créer des points de ventes, des caisses enregistreuses, des rapports de comptabilité légaux et des boutiques en ligne qui acceptent indifféremment les monnaies locales et fédérées du réseau, comme des espèces ou cartes bancaires.

Tout ceci avec du matériel DiY et du software low-tech, en favorisant au maximum le réemploi et le reconditionnement de matériel existant, et en utilisant une preuve d'enjeu comme mécanisme de consensus solide, sécurisé et transparent de validation (cf explications plus bas).

Financement, pérennisation du projet et lutte contre la spéculation.​

Imaginons un mécanisme qui puisse à la fois :

• Inciter de nouveaux acteurs à rejoindre la fédération ou en créer de nouvelles.
• Financer le développement du projet libre et coopératif (Problématique récurrente dans le milieu des logiciels libres).
• Lutter contre la spéculation et l'accumulation des capitaux pour une économie réelle et non financiarisée.

Une idée a été retenue. Elle a le mérite de résoudre les trois problématiques soulevées et s'inspire fortement de la monnaie fondante théorisé par l'économiste Silvio Gesell.

Concepts :​

• Tout le matériel nécessaire est produit par la coopérative et distribuée à ses acteurs à prix coutant. (matériel de points de vente, TPE, carte RFID, logiciel comptable, e-boutique, etc... voir TiBillet)
• Chaque utilisateur dispose d'un portefeuille numérique qui lui permet d'utiliser toutes les monnaies du réseau.
• Chaque lieu de point de vente est un nœud du réseau et est considéré comme un point de change.
• Les portefeuilles sont utilisables à vie et sans frais pour les utilisateurs ni pour les nœuds.
• Un demeurage est appliqué sur les portefeuilles sous la condition suivante : Si la monnaie n'est pas utilisée sous un certain délai (un an ou plus?) elle fond. Une partie est prélevée pour être réinjecté dans le réseau coopératif.

Les principes du demeurage et de la monnaie fondante permettent de favoriser la circulation des capitaux. En intégrant ce mécanisme dans le code de Fedow, nous tentons d'inciter la création d'un écosystème redistributif, social et solidaire.

Plus vous encouragez vos utilisateurs à utiliser une monnaie locale, plus vous récolterez une partie de la monnaie fondante issu du demeurage.

Ce mécanisme propose une solution incitative à la circulation de monnaie(s) locale(s) qui est une grande problématique de beaucoup de MLCC (monnaies locales citoyennes et complémentaires).

Je suis un utilisateur lambda, en pratique ça donne quoi ?​

• J'adhère et donne de mon temps dans une association de quartier qui utilise TiBillet pour gérer ses adhésions : je reçois une carte de membre et l'association me crédite de la monnaie temps.
• Je peux dépenser cette monnaie temps pour réserver des heures d'utilisation d'un fablab ou d'un espace de travail partagé.
• Je scanne ma carte et je peux la recharger en ligne. Je change des euros contre de la monnaie fédérée.
• Je réserve une place dans un festival partenaire de la coopérative qui utilise le système de cashless et de billetterie de TiBillet.
• J'achète le billet, des boissons et de la nourriture sur place avec cette même carte préalablement rechargée : Le festival reçoit de la monnaie fédérée.
• Le festival peut échanger cette monnaie fédérée contre des euros, ou s'en servir pour payer ses prestataires avec tout le bénéfice d'une monnaie locale complémentaire et citoyenne "MLCC".
• Il me reste de la monnaie sur ma carte. Je peux la dépenser dans un autre lieu qui utilise TiBillet/Fedow ou la garder pour le prochain festival : Elle est valable à vie.
• Je l'oublie dans un tiroir : Je suis régulièrement rappelé à l'utiliser via les newsletters de la fédération qui font la promotion des évènements associatifs et coopératifs du réseau.
• Si ma carte reste inactive pendant un certain temps, la coopérative récupère une partie du contenu du portefeuille et le réinjecte dans le développement du réseau.
• La coopérative se réunit régulièrement pour faire le point sur la circulation des monnaies et choisir les projets dans lesquels réinvestir l'argent récupéré.

(Exemple possible : 1/3 pour le nœud (organisateur de festival, association...), 1/3 pour un fond commun de soutien aux projets associatifs et coopératifs, 1/3 pour la maintenance et le développement de l'outil.)

Blockchain bas carbone et mécanisme de confiance : La preuve d'enjeux (PoS) et la preuve d'autorité (PoA) :​

Ou comment répondre à la grande question : Comment faire pour avoir confiance en un système bancaire décentralisé sur lequel repose de l'argent réel ?

[ATTENTION DISCLAIMER PARTIE VULGARISATION TECHNIQUE CRYPTO !]

Pour créer un système décentralisé mais sécurisé et fiduciaire, le Bitcoin a proposé la preuve de travail (Proof of Work) : Plus on est nombreux à vérifier, plus il est difficile de falsifier le document comptable car il faut convaincre la majorité pour faire consensus.

Pour encourager le nombre, il est proposé de récompenser les validateurs. Et pour savoir quel validateur va récupérer la récompense, on leur propose une énigme. Celui qui réussit à la résoudre gagne la récompense et valide par la même occasion le bloc de transaction.

Le reste du groupe vérifie ensuite que ce bloc a bien été validé correctement et tente de résoudre l'énigme suivante. On appelle ça "miner" et cela ne peut se faire qu'à l'aide d'ordinateur très puissants.

Résultat : c'est super sécurisé car beaucoup de monde vérifie chaque transaction.

Corollaire : c'est très (trop) énergivore au point d'en être insoutenable. (Et ne parlons même pas des mécanismes de rareté et de spéculation qui finissent par achever ce système à nos yeux...)

La preuve d'enjeu (Proof of Stake) a été proposée très vite comme une alternative à la preuve de travail (Proof of Work). Dans un système PoS, il n'y a pas de concept de mineurs, de matériel spécialisé ou de consommation massive d'énergie.

Pour être un validateur, vous devez prouver que vous avez intérêt à ce que tout le système reste bien valide. Chez Ethereum, la deuxième blockchain la plus valorisée, vous devez verrouiller une quantité variable de capital comme preuve d'intérêt et vous êtes récompensé en fonction de cette quantité verrouillée.

Ce système est beaucoup moins énergivore, mais il a tendance à favoriser une oligarchie car n'importe qui peut devenir un nœud : il suffit d'être riche...

Avec Fedow, c'est un peu différent. Il est necéssaire de vérifier votre identité comme celle de vos utilisateurs. La preuve d'enjeu, c'est vous !

Cette preuve d'enjeu, c'est la quantité de monnaie fédéré que vous récolterez en installant TiBillet/Fedow. Vous avez intérêt à ce que les comptes soient bien valide car vous en possédez une partie des actifs.

Dans ce système, il n'y a pas de concept de mineurs, de matériel spécialisé ou de consommation massive d'énergie. Tout ce dont vous avez besoin, c'est d'un ordinateur ordinaire sous linux.

Et cet ordinateur, vous l'avez déjà : il héberge votre instance TiBillet. Validez la co-optation ou créez votre réseau Fedow, et votre instance TiBillet devient un nœud qui valide les transactions de tout le réseau en toute transparence.

La preuve d'enjeu, c'est votre instance liée à votre identité. Plus exactement, ce mécanisme de consensus dérivé du PoS est appelé une preuve d'autorité (PoA).

En pratique :

• Créez ou rejoignez le nœud primaire Fedow de votre région ou réseau.
• Une fois votre identité validée, votre instance devient un nœud et vous validez les transactions avec les autres validateurs du réseau fédéré.
• Chaque nœud participant fait de même. Si tout le monde est d'accord, alors la transaction est validée. Tout le monde à une copie du même livre de compte : le réseau est résilient aux pannes, décentralisé, immuable et transparent.
• En contrepartie de votre participation à la sécurisation du livre de compte commun, vous recevrez une partie des frais prélevés lors de la revalorisation de la monnaie fondante (le demeurage).

C'est quoi la différence finalement avec une autre blockchain ?​

Contrairement à la majorité des crypto-actifs, il n'y a pas de blocks fraîchement créés dans le cadre de la récompense pour les validateurs. La monnaie fédérée est émise dans une économie réelle.

Cette émission est réalisée par les adhérents et utilisateurs de vos lieux lorsqu'ils échangent de vrais euros pour recharger leur carte cashless de festival ou d'adhésion associative.

La monnaie est bien réelle. Elle n'est pas volatile. Le moteur de l'application et le consensus de validation s'assurent qu'il existe et existera toujours 1€ de disponible en banque pour 1 token fédéré.

Nous ne sommes pas une startup. Notre but n'est pas de lever des fonds en crypto-actif ou d'entrer en bourse. Nous ne prélevons pas de pourcentage sur les transactions dans le but de revendre les tokens que nous créons nous même sur un marché spéculatif.

Nous construisons TiBillet/Fedow au sein de tiers-lieux populaires, de coopératives et associations culturelles dans le but de construire des communs.

Nous ne souhaitons pas un Fedow pour contrôler un actif financier, mais des Fedows pour des mises en réseaux de lieux.

Nous sommes une société coopérative d'intérêt collectif, et nous invitons tous les acteurs de TiBillet à devenir sociétaires pour décider ensemble de l'évolution du projet.

Nous sommes CodeCommun.Coop, Venez discuter avec nous !

Projet construit, financé et testé avec le soutien de :​

• Coopérative Code Commun
• la Réunion des Tiers-lieux
• La Raffinerie
• Communecter
• Le Bisik
• Jetbrain supports non-commercial open source projects.
• Le Manapany Festival
• Le Demeter

Contact :​

• https://discord.gg/ecb5jtP7vY
• https://chat.tiers-lieux.org/channel/TiBillet
• https://chat.communecter.org/channel/Tibillet

Sources, veille et inspirations​

Sur la supercherie ultra libérale du web3 et des applications décentralisés (Dapp) :

• https://web3isgoinggreat.com/

Sur la monnaie fondante et son auteur :

• https://fr.wikipedia.org/wiki/Monnaie_fondante
• https://fr.wikipedia.org/wiki/%C3%89conomie_libre

Sur les relations entre consommation, écologie et crypto :

• https://app.wallabag.it/share/64e5b408043f56.08463016
• https://www.nextinpact.com/article/72029/ia-crypto-monnaie-publicite-chiffrement-lusage-numerique-face-a-son-empreinte-ecologique

Sur les consensus de validation de blockchain :

• https://academy.binance.com/fr/articles/proof-of-authority-explained?hide=stickyBar
• https://github.com/P2Enjoy/proof-of-consensus
• https://www.geeksforgeeks.org/proof-of-stake-pos-in-blockchain/?ref=lbp
• https://www.geeksforgeeks.org/delegated-proof-of-stake/?ref=lbp

Design Billetterie​

TiBillet est construit sur un modèle de SaaS (Software as a service) : Un serveur peut héberger plusieurs instances de projets.

Un serveur peut être monté pour un territoire. Chaque lieu qui souhaite participer à un agenda commun peut rejoindre le serveur.

Qu'il soit organisateur, artiste, ou porteur de plusieurs projets, chaque évènement sera visible sur sa page personnelle et sur l'agenda commun.

D'une pierre deux coups, vendez vos billets en ligne et participez à un agenda commun !

JPG :​

SVG et fichier excalidraw:​

• Design-billetterie-sept23.svg
• Design-billetterie-sept23.excalidraw

Document de travail :​

• Front Billetterie Excalidraw
• Tâches et Kanban

Historique et origine​

A l'origine du projet TiBillet, il y a le Manapany Festival et l'association organisatrice : Les 3Peaks. Nous étions une bande de joyeux.ses bidouilleur.ses.s et développeur.ses.s bénévoles. Nous avions décidé de créer nos propres outils numériques principalement pour une raison : nous avions envie d'apprendre à le faire nous même :)

En dehors du festival annuel, l'association hébergeait un café associatif ouvert régulièrement et organisait des évènements culturels mensuels avec une contrainte : si l'entrée était libre à tous et toutes, il nous fallait un outil pour gérer les adhésions associatives et les paiements des consommations. Pourquoi ne pas continuer à utiliser la carte NFC cashless du festival tout au long de l'année ?

En même temps, nous regardions comment les solutions existantes des professionnels du secteur fonctionnaient : Carte et bracelets NFC à usage unique, remboursement limité dans le temps, prix prohibitif pour l'organisateur et le public... Nous ne voulions vraiment pas reproduire un modèle qui semblait être juste un moyen de faire payer plus les festivaliers...

Voici que la carte d'adhésion 3Peask est née : Valide à vie, gratuite, rechargeable en ligne, remboursable à tout moment, utilisable au café associatif toute l'année comme au festival, elle permettait de gérer un point de vente et une caisse enregistreuse tout en s'assurant que le membre associatif était à jour de sa cotisation.

Et ça a cartonné ! Avoir plus de 800 membres à l'année fut une expérience très enrichissante. Nous développions TiBillet au fur et à mesure des besoins, des remarques et des idées de nos membres : nous codons un outil que nous utilisons au quotidien.

Aujourd'hui (Juin 2023), après 6 ans de développement, la carte TiBillet permet tout ceci :

• Carte d'adhésion associative et d'abonnement.
• Portefeuille pour paiement sans contact (Cashless) :
  • En euro rechargeable en ligne et/ou sur place.
  • En points cadeau, dans le but de comptabiliser les ventes offertes.
  • En monnaie temps, pour une valorisation du bénévolat.
• Système de prise de commande avec imprssion de ticket en cuisine.
• Billetterie en ligne avec paiement par carte bancaire via Stripe.

Le Pôle régional des musiques actuelles​

Lors des rencontres de la filière culturelle organisée en 2016 par le pôle régional des musiques actuelles de la réunion (PRMA), et le ministère de la culture, le projet TiBillet est présenté et reçoit un accueil très positif. Une petite subvention est alors débloquée pour réaliser un "Proof of concept" en dehors du festival de Manapany : TiBillet s'installe au Bisik, un lieu culturel à l'est de la réunion.

Communnecter.org​

En 2020, nous avons rencontré l'équipe de Communecter.org, un réseau social libre et open source. Un appel à projet venant du secrétariat général aux affaires régionales de la réunion (SGAR) est lancé et une demande de subvention commune est rédigée. Succès !

La Réunion des Tiers Lieux.​

Début 2022, le collectif "La Réunion des Tiers Lieux" (RTLx) se construit et propose des chantiers de travail collaboratif. TiBillet est utilisé à la Raffinerie de Savanna, un tiers lieu éco-culturel et artistique à Saint Paul. RTLx se propose de financer une partie du développement de TiBillet pour l'adapter aux besoins des tiers lieux.

Fond propre​

Avec l'aide du dossier SGAR/Communnecter et de RTLx, l'équipe de bénévole qui construit TiBillet se motive pour passer au niveau supérieur. Des fonds propres sont investis, du matériel est acheté et zou !

Au menu : Portefeuille, agenda et billetterie fédéré.

L'idée : Utiliser la même carte d'adhésion sur tout un territoire, réer des monnaies locales à la demande et donner à chacun la possibilité d'auto héberger ses données.

Argent public ? Code Public !​

Car nous pensons que le modèle coopératif vaut mieux qu'une startup, nous créons alors une Société Coopérative d'Intérêt Collectif (SCIC). Orientée développement de logiciel libre, la coopérative Code Commun est née.

Et en pratique ?​

En pratique, les outils TiBillet sont expérimentés dans de de nouveaux lieux et deux grands dépôts de code sont maintenus pour favoriser la contribution.

On vous invite à farfouiller dedans, et on vous donne rendez vous dans les prochaines notes de blogs pour les détails !

• TiBillet
• Code Commun

Deconstruire pour decentraliser.​

Fini le gros bloc PHP. La billetterie, qui s'occupe de gérer les paiements en ligne (recharge cashless via stripe), les réservations et les ventes de billet a été complètement repensée.

Première étape : L'agenda fédéré.​

En avant avec Django ! Le framework web en Python est déja utilisé coté cashless, nous avons tout repensé depuis la base pour faire un modèle dit de SaaS (Software as a service). L'idée est de pouvoir utiliser la puissance combinée du moteur de schéma PostgreSQL pour des applications multi-tenant.

Derrière ce vocabulaire un peu barbare se cache une idée toute simple : Un seul serveur pour gérer plusieurs instances qui se partagent des informations communes.

Autrement dit, plutôt que d'avoir plein de serveurs séparés qui stockent chacun peu ou prou les mêmes données (carte, utilisateurs, évènements, etc... ), nous mutualisons tout un territoire sur une seule "Stack".

Certaines données, comme les utilisateurs et l'agenda sont partagées entre tous les acteurs.

D'autre sont uniques à chaque instance : Évènements, adhésions, information générales, cartes cashless etc ...

Mais surtout, ce système nous permet de faire une présentation de TOUS les évènements présents dans l'instance: Nous l'avions nommé la META, mais bon... Yen a un qui nous a piqué le nom xD ...

Et hop ! Agenda Fédéré !

Ici nous parlons de concerts et d'artiste. Mais il est tout à fait possible d'imaginer des réunions, des marchés d’artisans, des festivals, des locations de salle de répetes, des randonnées etc etc ...

C'est un moteur évènementiel de données partagées. Les idées qui permettent de l'exploiter sont nombreuses !

À l'heure où nous écrivons ces lignes (octobre 2022), ce système est prêt et mis en production depuis quelques jours.

A vous de le tester ! Venez discuter avec nous pour vos retours et vos idées !

Et ma carte dans tout ça ?​

On y vient ! C'est la suite logique, non ? Et si nous ajoutions dans les données communes les cartes NFC déja utilisées par les lieux ?

Après l'agenda, libérons les cartes NFC !

À suivre dans la 3ᵉ partie ...

Cet article est un tout petit peu technique, mais tout à fait accessible à quiconque souhaite plus d'information sur le chantier en cours.

Avec le collectif La Réunion des Tiers Lieux (RTL) se lance un grand chantier autour des outils communs. Nous détaillons ici une partie, celle de la construction et la decentralisation d'un
agenda et d'un portefeuille cashless partagé à tout un territoire.

Introduction​

Aujourd'hui, lorsque l'on veut organiser des évènements, beaucoup de solutions existent.

Et rare sont les routes pour communiquer entre ces solutions : il faut souvent apprendre à jongler.

De plus, chaque acteur de la filière s'affaire souvent dans son coin, multipliant ainsi les données souvent redondantes.

Parfois même, nous alimentons des plateformes silo qui enferment et captent nos données sans avoir la main sur la visibilité de nos actions : nous sommes souvent devenus dépendant des algorithmes des GAFAM qui décident de notre visibilité.

TiBillet ?​

Avec TiBillet, nous participons aussi malgré nous à cette isolation. Depuis 2010, nous construisons des outils numériques pour l'évènementiel culturel : Chaque lieu peut posseder une carte d'adhésion et de paiement sans contact (Cashless) et son instance de billetterie avec son agenda.

Le public peut réserver sa place de concert et recharger sa carte en ligne. Chaque lieu à son instance, ses membres et utilisateurs bien à lui.

Et sur un petit territoire comme la Réunion, c'est souvent les mêmes utilisateurs ...

Au commencement ...​

Au tout début, la "Stack' TiBillet (ensemble de boites techniques) était très centralisé :

En 2018 vient un premier intérêt public avec l'aide du PRMA (Pole Régional des musique actuelles) de la Réunion.

On commence à penser fort à libérer le code et créer une coopérative pour supporter le développement.

Puis vient la rencontre avec les tiers-lieux de La Raffinerie, de Vavang'Art, et avec le réseau social libre Communecter.

Le projet de portefeuille fédéré de RTL ne fait que confirmer nos envies communes et nous donne les moyens de développer un nouveau modèle.

Aujourd'hui (Octobre 2022), le chantier à beaucoup avancé. Il reste beaucoup à faire et la feuille de route commence à bien se dessiner :

Réunion des Tiers-Lieux​

Avec la Réunion des Tiers-lieux, nous avons lancé le chantier Outil Commun pour fédérer les pratiques, éviter de multiplier les données et mutualiser le matériel.

Du côté de la team TiBillet, nous nous sommes affairés à construire les briques d'un logiciel libre utilisable par tout un territoire et depuis plusieurs mois, nous changeons le moteur de notre application pour pouvoir construire un outil commun et fédéré de billetterie, d'agenda culturel et de cashless.

Pour réussir à construire TiBillet en outil fédéré, techniquement, il a fallu changer pas mal de choses. Et pas uniquement notre vision globale :)

Dans les grandes lignes, nous souhaitons séparer le développement et l'expérimentation en trois grandes étapes.

• L'agenda partagé
• Le portefeuille fédéré
• Les monnaies locales

À suivre dans la deuxième partie ...

Dans le cardre du chantier Outil Commun de la Réunion des Tiers-Lieux (RTL), nous engageons une réfléxion autour d'une carte TiBillet partagée entre plusieurs Tiers-lieux.

Une roadmap a été travaillée avec un résumé des budgets et des finances.

Pour ceux qui veulent aller vraiment loin dans la réflexion, nous avons créé un document qui recense un peu de littérature sur tout ce qui touche de près ou de loin à ce chantier.

C'est pensé comme une bibliothèque commune : Sentez-vous libre de rajouter vos articles et vos connaissances : https://nuage.tierslieux.re/s/sMPScgSPNgwRrWD

Prochaine réunion dans le lundi 17 octobre 2022, sur le Discord de la coopérative TiBillet. Ordre du jour : Portefeuille fédéré -> Remontez-nous vos idées et besoins !

Extrait de https://framablog.org/2022/08/17/ecosocialisme-numerique-une-alternative-aux-big-tech
Louis Derrac, Michael Kwet.

L’accord sur les Technologies Numériques​

Les grandes entreprises technologiques, la propriété intellectuelle et la propriété privée des moyens de calcul sont profondément ancrées dans la société numérique et ne peuvent être éteintes du jour au lendemain. Ainsi, pour remplacer le capitalisme numérique par un modèle socialiste, nous avons besoin d’une transition planifiée vers le socialisme numérique.

Les écologistes ont proposé de nouveaux “accords” décrivant la transition vers une économie verte. Les propositions réformistes comme le Green New Deal américain et le Green Deal européen fonctionnent dans un cadre capitaliste qui conserve les méfaits du capitalisme, comme la croissance terminale, l’impérialisme et les inégalités structurelles. En revanche, les modèles écosocialistes, tels que le Red Deal de la Nation Rouge, l’Accord de Cochabamba et la Charte de justice climatique d’Afrique du Sud, offrent de meilleures alternatives. Ces propositions reconnaissent les limites de la croissance et intègrent les principes égalitaires nécessaires à une transition juste vers une économie véritablement durable.

Cependant, ni ces accords rouges ni ces accords verts n’intègrent de plans pour l’écosystème numérique, malgré sa pertinence centrale pour l’économie moderne et la durabilité environnementale. À son tour, le mouvement pour la justice numérique a presque entièrement ignoré les propositions de décroissance et la nécessité d’intégrer leur évaluation de l’économie numérique dans un cadre écosocialiste. La justice environnementale et la justice numérique vont de pair, et les deux mouvements doivent s’associer pour atteindre leurs objectifs.

À cet effet, je propose un Accord sur les Technologies Numériques écosocialiste qui incarne les valeurs croisées de l’anti-impérialisme, de la durabilité environnementale, de la justice sociale pour les communautés marginalisées, de l’autonomisation des travailleurs, du contrôle démocratique et de l’abolition des classes. Voici dix principes pour guider un tel programme :

1. Veiller à ce que l’économie numérique ne dépasse pas les limites sociales et planétaires.
2. Supprimer progressivement la propriété intellectuelle.
3. Socialiser l’infrastructure physique.
4. Remplacer les investissements privés de production par des subventions et une production publiques.
5. Décentraliser Internet.
6. Socialiser les plateformes.
7. Socialiser l’intelligence numérique et les données.
8. Interdire la publicité forcée et le consumérisme des plateformes.
9. Remplacer l’armée, la police, les prisons et les appareils de sécurité nationale par des services de sûreté et de sécurité gérés par les communautés.
10. Mettre fin à la fracture numérique.

Source :

• https://longreads.tni.org/digital-ecosocialism
• https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3965128
• https://framablog.org/2022/08/17/ecosocialisme-numerique-une-alternative-aux-big-tech/#easy-footnote-bottom-11-28126

Ce billet de blog n'en est pas vraiment un. C'est un recceuil de lien qui nous plait, qui nous inspire, ou qui nous remets en questions sur nos pratiques.

N'y voyez pas forcément une adhésion à chaque parti pris (Il y a par exemple des articles pros et scèptiques sur les cryptoactifs...), mais je ne doute pas que vous saurez deviner de quel bord nous penchons.

Fédérations​

Fediverse​

Le Fediverse est un réseau social multiforme qui repose sur une fédération de serveurs interconnectés. C’est un phénomène assez jeune encore, mais dont la croissance suscite déjà l’intérêt et des questionnements.

https://framablog.org/2021/01/26/le-fediverse-et-lavenir-des-reseaux-decentralises/

https://andre-ani.fr/divers-informatique/quest-ce-que-le-fediverse/

Communecter​

Communecter est un partenaire de longue date. Plongez dans leurs outils !

https://peertube.communecter.org/videos/watch/00b4cc60-7d88-4b23-a775-b5bc69a1664e

Murmuration​

Le protocole Murmurations est conçu pour permettre le partage décentralisé de données. Les exemples les plus évidents de son utilisation sont les cartes et les répertoires, mais ce n'est qu'un début. Dans ce billet de blog, nous explorons certains des autres concepts qui pourraient être construits sur Murmurations.

https://murmurations.network/2022/07/05/what-can-you-build-on-the-murmurations-protocol/

Schema.org​

Schema.org est une activité collaborative et communautaire dont la mission est de créer, maintenir et promouvoir des schémas pour les données structurées sur Internet, sur les pages Web, dans les messages électroniques et au-delà.

Licences libre et open source​

Licences open source : Trés bonne entrée en matière dans le monde fabuleux du libre :)

https://www.youtube.com/watch?v=HGid_PYx0Fo

Selon nous, le logiciel et la culture libre restent au cœur des actions de l’association, mais deviennent un moyen, et non une fin. L’objectif devient alors de réfléchir et mettre en place des actions diverses qui facilitent l’émancipation des internautes.

https://framablog.org/2022/10/04/voyage-en-contributopia-ca-nous-a-fait-murir/

Organisations​

Le feuilleton en 8 épisodes dont nous entamons aujourd’hui la publication n’est pas un simple mouvement d’humeur contre certaines dérives du militantisme mais une réflexion de fond sous l’angle de la psychologie sociale, nourrie et illustrée d’exemples analysés.

https://framablog.org/2021/07/09/quand-le-militantisme-deconne-injonctions-purete-militante-attaques-1-8/

Une asso qui se lance, comment ça marche ? Ou plutôt quels écueils ça rencontre, comment on peut les contourner, quel mode de gouvernance installer… ? Ces questions et bien d’autres qui agitent ses membres jusqu’à les rendre perplexes, Quentin et ses complices les ont affrontées au sein de l’association Picasoft… :

https://framablog.org/2022/09/05/de-la-bureau-cratie-a-la-tout-doux-cratie-refonder-la-gouvernance-associative/

Blockchain​

OpenWallet et Hyperledger​

Un projet modulaire et open-source qui permet aux entreprises de construire en utilisant la blockchain d'une manière qui leur convient.

Hyperledger est un projet hébergé par la Fondation Linux pour aider les développeurs et les entreprises à travailler ensemble pour construire des projets de blockchain collaboratifs. Il s'agit d'un collectif de blockchains et d'outils open-source que chacun peut utiliser pour créer ses propres grands livres distribués.

https://www.hyperledger.org/

https://decrypt.co/resources/hyperledger

https://decrypt.co/109593/linux-foundations-announces-open-source-digital-wallet-initiative-may-include-cryptocurrencies

Pour tout comprendre à la blockchain, un très bon article de vulgarisation :

Patrice, fondateur de la société Unblocked et Himran, en charge de son développement commercial et marketing, ainsi que Léo, directeur de projet, nous partagent leurs connaissances et leur vision sur la blockchain et les opportunités qu’elle génère : de l’explosion des NFT à de nouveaux cas d’usage. L’origine de la blockchain

https://blog.link-value.fr/democratisation-blockchain-potentiel-nft-nouveaux-usages-35c3ac3365f6

Technos BC :​

Le Tangle, une nouvelle forme de BC.

" Le Tangle succède naturellement à la blockchain en tant que prochaine étape d'évolution, car il offre des fonctionnalités adaptées à la mise en place de solutions de grands livres distribués plus efficaces et plus évolutives."

https://wiki.iota.org/learn/about-iota/tangle

Plateforme paiement et crypto-actifs​

UTRUST​

Accepter le paiement en cryptomonnaie (Bitcoin, eGold) en tant qu'artisan, le cas pratique avec UTRUST : https://developpeur-freelance.io/blog/acheter-fromage-bitcoin/

Crypto scepticisme​

Articles intéressants et critiques du monde des crypto-monnaies (crypto-actif) :

https://web3isgoinggreat.com

https://www.numerama.com/tech/1128614-la-crypto-reunit-les-meilleurs-reveurs-et-les-pires-escrocs-quand-meme-les-fans-de-cryptos-quittent-le-navire.html

https://www.lemonde.fr/pixels/article/2022/09/07/au-crypto-policy-symposium-les-sceptiques-de-la-cryptoeconomie-entrent-en-resistance_6140539_4408996.html

https://www.numerama.com/tech/1006000-bill-gates-demonte-les-nft.html

https://www.nextinpact.com/article/69429/1-500-informaticiens-crypto-sceptiques-interpellent-congres-americain

https://fredcavazza.net/2022/06/23/le-progres-ne-viendra-pas-des-nouvelles-technologies-mais-de-levolution-des-usages/

Crypto Enthousiastes​

Articles intéréssants et enthousiastes sur les crypto actifs :

https://www.nextinpact.com/article/69454/le-plaidoyer-pro-crypto-dun-cryptographe-emerite

https://www.numerama.com/tech/1058914-elizabeth-stark-lactiviste-qui-veut-democratiser-le-bitcoin.html

Sur les GAFAM​

On le sait bien : Google se permet de tranquillement lire tous les mails qui passent sur ses serveurs, ceux des boîtes Gmail ainsi que ceux adressés à des boîtes Gmail…

En général, le but est de refourguer de la publicité ciblée. Mais pas seulement. Une petite histoire (vraie) qui montre que les conséquences peuvent être autrement plus dramatiques…

https://framablog.org/2022/09/09/google-lespion-le-plus-con-du-monde/