/mdt/ - Retours bis

Retours bis (69 Réponses)

1 .

Chère Adelyne,
Quand j'essaie de me connecter à l'acrimonie le message suivant m'est parfois montré :
« Secure Connection Failed

The connection to the server was reset while the page was loading.

The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
Please contact the website owners to inform them of this problem.

Learn more… »
La page vers laquelle « Learn more » me renvoie ne présente aucune information utile et il n'y a pas de bouton permettant de regarder ce qui se passe au niveau du certificat. J'imagine que ça veut dire que le serveur ferme la connexion avant même d'avoir envoyé le certificat, mais à défaut de faire tourner tcpdump h24 sur ma machine je ne saurais comment confirmer mon hypothèse.
Connaîtrais-tu la source de ce problème ?
Chocobisous chaleureux,
- Ânon.

2 .

Un bug dans ma configuration de CFEngine qui lui faisait redémarrer le serveur apache toutes les 2 à 5 minutes ; si tu arrives au mauvais moment, la connexion dysfonctionne. Comme je viens tout juste de changer (encore) de serveur (une histoire de bon d'achat que je ne peux pas générer avant de pouvoir renouveler le VPS), j'en ai profité pour raccorder cette instance de CFEngine à celle de mon serveur qui centralisait déjà le reste de mon réseau personnel.

3 .

Il y a plusieurs lien cassés sur cette page : https://www.acrimonie.com/mdt/list3.html .

4 .

>>3
Si tu cliques sur le numéro au lieu du titre ça marche. Je sais pas pourquoi ça fait ça. De toute façon KusabaX n'en a plus pour très longtemps sur acrimonie.

5 .

>>4
Avant ou après la fin du redesign CSS du site ? :^)

Qu'est-ce que tu as choisi au final ?

6 .

De toute façon KusabaX n'en a plus pour très longtemps sur acrimonie. ENREGISTREZ TOUT

7 .

>>6
J'ai tout sur VHS.

8 .

>>6
Pas de panique, j'ai quelques disquettes vierges pour sauvegarder tout ça.

9 .

>>5
Pour finaliser le redisgn faudrait modifier le backend, et ce dernier est codé avec les pieds et en PHP. Il y aurait bien meguca, écrite en go, mais elle est trop spécialisée et j'aimerais un langage plus dense avec des capacités de meta-programmation avancées pour expérimenter des idées s'éloignant de l'ontologie habituelle des imageboards. J'ai décidé d'utiliser Elixir et Phoenix pour créer ma propre imageboard. Pour le moment je termine d'apprendre en profondeur Erlang/OTP (il me reste à apprendre rebar3, eunit et common_test, mais pour le reste j'ai vraiment bûché à fond la documentation officielle et lu la thèse d'Armstrong). Elixir a quasiment la même sémantique qu'Erlang et il est courant d'avoir à utiliser des bibliothèques en Erlang depuis Elixir (comme des bindings pour ffmpeg que j'ai trouvé sur github qui seront très utiles pour les webms), donc je pense que ma stratégie est la bonne. J'aimerai avoir un truc viable pour noël, mais même s'il semblerait que Phoenix permette d'être super productif je promets rien.

Évidemment, lors de la migration je compte convertir ce qu'il y a dans MySQL vers mnesia (la BdD fournie avec Erlang/OTP).

10 .

>>9
Ha, je me disais bien que c'était toi qui avait posté ce message où tu demandais des conseils vis à vis des technos à utiliser pour « construire un forum pour une petite communauté ».
J'ai du mal à voir en quoi des capacités de meta-programmation vont t'aider à faire quoi que ce soit que tu n'aurais pu faire en utilisant le langage en lui même. Je suis aussi un peu sceptique de l'utilisation de BEAM (à moins que tu aies pour objectif de faire grossir l'acrimonie jusqu'à avoir des millions d'utilisateurs).
M'enfin, tu as l'air de savoir ce que tu fais et j'ai hâte de voir le résultat.

11 .

>>10
Ce qui m'intéresse c'est surtout la philosophie du « let it crash ». L'idée c'est de pouvoir avoir des applications en version alpha immédiatement mises en production sans que ça fasse tout crasher et de façon générale de ne pas avoir à surveiller le moteur d'imageboard comme le lait sur le feu. L'autre idée c'est d'exploiter les capacités de concurrence massive de BEAM pour proposer des fonctionnalités potentiellement très complexes à peu de clients au lieu de proposer des fonctionnalités simples à beaucoup de clients.

12 .

>>11
L'autre idée c'est d'exploiter les capacités de concurrence massive de BEAM pour proposer des fonctionnalités potentiellement très complexes à peu de clients J'ai peu de connaissances à propos de BEAM et Erlang (et aucune en ce qui concerne Elixir), donc il est probable que tes idées soient plus justes que les miennes. Cependant je crois que ce n'est pas comme ça que fonctionne BEAM, à moins que tu parvienne à paralléliser toutes tes fonctionnalités sous la forme de très petits acteurs (et même là tu aura peut être des problèmes, de ce que je me souviens avoir lû la gestion des mailbox des processus Erlang est pas super efficace). Pour ce que je comprends de ton cas d'utilisation j'aurais probablement préféré Rust ou Go, même en étant vraiment pas fan de ce dernier.
Ce qui m'intéresse c'est surtout la philosophie du « let it crash ». Je comprends mieux pourquoi tu as choisi Elixir. C'est vrai que ça doit être franchement agréable de l'utiliser comme ça quand on dev' un site seul pour une petite communauté.

13 .

>>9
>>10
>>11
>>12
Ça veut dire que c'est la fin de l'Acrim' telle qu'on la connaît ?

14 .

>>12
et même là tu aura peut être des problèmes, de ce que je me souviens avoir lû la gestion des mailbox des processus Erlang est pas super efficace La mailbox pose problème quand les messages s'accumulent, car à chaque boucle du processus le pattern matching va passer en revue un nombre croissant de messages. On évite ça en mettant une condition « attrape-tout » pour logguer les messages reçus par erreur, et en gérant la backpressure en signalant l'engorgement en amont du système ou en demandant systématiquement confirmation qu'un processus peut envoyer des données en aval du système. Erlang in Anger a un chapitre sur le sujet.

15 .

J'ai tout sur bande magnétique les perdants.

16 .

J'ai tout enregistré sur carte perforée, j'ai de quoi remplir un carton entier avec vos conneries (plus dix cartons pour les images).

17 .

J'ai tout retransmis par tradition orale sur quinze générations.

18 .

J'ai tout oublié.

19 .

Et voilà... Comme d'habitude, la seizième génération ne sait plus où elle a rangé sa tradition orale...

20 .

Dans le cloud, notre noosphère 2.0

21 .

Y a pas moyen de bannir les cacaposteurs, trolls et autres noms-pédés ?
Ca ressemble presque à un raid ces jours-ci.

22 .

>>21
Faudrait définir un critère clair.

23 .

>>22
Tout ce qui s'apparente à de la provocation ou à un irrespect relatif des règles.
Quitte à bannir de bons acrimoines (je n'y échapperai probablement pas) le temps de calmer les esprits.

24 .

>>23
Un tour de vis sur la rigidité d'application des règles mettant fin à l'idée que les ânons doivent d'abord s'automodérer avant que la modération intervienne est possible, mais « tout ce qui s'apparente à de la provocation » ça semble très large et vague.

25 .

>>24
J'ai une confiance aveugle en Adelyne.

26 .

Putain mais en ce moment c'est la merde sur /a/. Est-ce qu'Adelyne peut faire quelque chose d'utile pour une fois ?

27 .

>>26
Commence par compenser avec de bons fils. Les mauvaises herbes se développement là où il n'y a plus d'autre végétation.

28 .

Je plussois l'auto-modération, mais y aura toujours des Jean-Kev

29 .

Donc un tour de vis sur l'application des règles pour virer les tentatives de profilage et les loultisteries (ou autres communautés cancérigènes à l'avenir), mais pour la qualité du contenu ça s'améliore pas avec de la modération quand l'essentiel de l'humour est fondé sur l'ironie et le non sequitur.

30 .

Je vais attendre demain pour revoir tout ça à tête reposée, mais voici ce que j'aimerai mettre en sticky verrouillé sur /a/ :

La communauté d'acrimonie a échoué à s'automodérer. Malgré les réactions négatives des autres utilisateurs et des multiples avertissements reçus, les utilisateurs de loult.family continuent de poster leurs mèmes dépourvus de sens hors de loult, leur nompédérastie et leur drama n'importe où. Toutes les loultisteries entraîneront donc un an de ban sans avertissement. Malgré les réactions négatives de la communauté, le pourrissement de l'ambiance qu'ils ont causé, la contradiction de fond avec la règle 1 et leurs échecs récurrents et ridicules, les profileurs continuent de profiler. Toute tentative de profilage entraînera donc un an de ban sans avertissement. Malgré la stérilité de leurs messages, les réactions négatives et le pourrissement de l'ambiance qu'ils causent, les insulteurs continuent d'insulter. Les messages ayant pour principal objectif d'attaquer un utilisateur sur le plan personnel entraîneront donc un an de ban sans avertissement. Ces changements ne sont pas rétroactifs et s'appliquent dès maintenant. Quoi, comment ça, vous vous dites que vous ne pourrez plus rien poster sans vous faire bannir ? C'est que vous êtes le problème et ces règles s’adressent à vous. Si vous ne voulez pas voir ce site disparaître, utilisez l'humour pour faire face aux idiots et n'hésitez pas à exprimer vos idées et sentiments les plus étranges sans craindre qu'on vienne vous emmerder pour ça, tant que votre objectif n'est pas d'emmerder les autres. Ce sera tout.
Les règles seraient modifiées comme suit :

1. Respectez le principe d'anonymat, que ce soit pour vous ou pour autrui. Corrolaire 1 : pas de doxxing. Corrolaire 2 : n'essayez pas de deviner qui est derrière quel message. 8. Ne postez pas de messages visant principalement à attaquer personnellement un autre utilisateur. 10. Les règles précédentes sont appliquées de manière aveugle et mécanique en se fondant principalement sur le contenu des message.
C'est mon diagnostic et mes solutions aux problèmes que je perçois sur acrimonie. Si vous avez des propositions ou des améliorations à faire, postez-les. Cette attitude de consommateur passif qui se plaint quand ça va pas mais ne fait rien d'autre est casse-pieds.

31 .

>>30
Un an c'est peut-être beaucoup, non ?

32 .

>>31
J'admets. Ça doit être l'accumulation de l'agacement sur plusieurs mois.

33 .

>>30
Moi ça me va. J'aurais trouvé ça extrême il y a un moment, mais il devient difficile d'ignorer les loutistes et les énervés, ça n'incite pas à contribuer.

34 .

Ce message a été effacé.

35 .

>>33
les énervés En relisant quelques vieux fils, j'étais bien content que l'ânon-hébergeur s'est pris une levée de boucliers.

36 .

>>30
Insulteurs et profileurs une semaine, loutistes un mois, doxeurs un an.

37 .

>>36
Je serais plus sévère avec les loutistes personnellement, parce que c'est leur bêtise et leur loult qui les exposent au doxx. D'ailleurs je ne comprends même pas la chasse au profileurs, puisqu'à la bonne époque on avait des fils de recensement presque réguliers. J'en viendrais à croire que je suis le seul à s'en souvenir.

38 .

>>37
Je comprends pas pourquoi tu comprends pas que ça pose problème par rapport aux principes même de l'anonymat. Le profilage qui est fait ici n'est pas la recherche d'informations personnelles, mais la création de personnages (le féministe, le redpillé, etc.) à partir desquels les messages sont jugés, au lieu de juger les messages sur leur contenu. Au final ça mène aux mêmes problèmes que dans les espaces de discussion avec pseudonymes, alors que l'anonymat est supposé éviter cela, comme expliqué dans cet essai connu des imageboardeux http://wakaba.c3.cx/shii/ L'effet est encore plus prononcé avec les profileurs d'acrimonie car les personnages qu'ils créent sont souvent très faux (j'ai pu le vérifier avec les IPs et leur historique) et taillés pour avoir le dessus dans la discussion sans avancer d'arguments de fond. Les fils recensement au contraire n'ont jamais créé ce problème, car les posteurs y contrôlent les informations postées et ne créent pas de surnoms à la con réutilisés par la suite dans d'autres fils.

39 .

>>38
Ah au temps pour moi, je vais aller lire ça merci.

40 .

>>38
les personnages qu'ils créent sont souvent très faux Soyons honnêtes une minute, les posteurs sont souvent des personnages très faux.

41 .

Ce que je dois (ré)implémenter :

- imageboard de base : des planches contenant des fils contenant des messages avec optionnellement une image
- planches sans images
- image obligatoire pour l'OP sur une planche avec images
- interface d'administration avec création de planches et leurs options
- interface de modération sur chaque message pour bannir et rechercher par IP ou par sous-réseau IPv6
- le BBCode
- l'aperçu des messages
- les flux RSS
- (bonus) mise à jour en temps réel des nouveau messages quand un fil est ouvert
- thread watcher utilisant localstorage et (bonus) mis à jour en temps réel
- page permettant de voir les derniers messages postés sur l'ensemble du site et (bonus) mise à jour en temps réel
- miniatures pour les images et (bonus) les webms
- cacher les fils
- effacer les fils/messages
- signaler les fils/messages
- quick reply
- sage
- pagination des fils
- bannières et slogans aléatoires
- identification du pays du posteur sur /int/
- (bonus) utiliser le push d'http2

Il manque quelque chose par rapport à l'existant ?

42 .

>>41
Je me réponds moi-même :
- l'intégration des vidéos youtube
- une vue en catalogue
- les traductions

43 .

>>41
>>42
Ce n'est pas dans l'existant mais ce serait sympa de pouvoir éditer son message au lieu d'avoir à supprimer/reposter. Si cette fonctionnalité est utilisée pour semer la zizanie, on pourrait imaginer imposer une limite sur le nombre d'éditions possibles (au hasard, trois) et garder un historique des versions.

Le support d'une API JSON compatible avec celles existant déjà (https://github.com/4chan/4chan-API par exemple) serait cool aussi.

44 .

>>43
Là je m'attaque à la couche des modèles et je vais plutôt m'orienter vers des structures de données qui ne sont pas aussi plates que celles exposées par 4chan. Si tu en connais d'autres plus structurées je prends, sinon comme je vais faire une API REST avec du JSON pour le temps réel, je vais simplement exposer mes modèles. Pour l'édition de messages, je pensais mettre à la place une limite de temps et pas d'historique. Le but de l'édition c'est quand même de faire disparaître ses erreurs ; mais s'il s'avère que garder l'historique serait une bonne idée, je remettrai ça au moment où je passerai de mnesia à une autre base de données, comme par exemple CouchDB qui intègre le support des versions multiples d'un même document.

45 .

>>44
J'ai l'impression que la seule API qui existe est celle de 4chan, tous les projets en rapport avec les imageboards que j'ai pu trouver l'utilisent ou alors retombent sur parser directement les pages HTML ( https://github.com/vichan-devel/overchan , https://github.com/miku-nyan/Overchan-Android... , https://github.com/czaks/chanstats/blob/master/stat.rb ).

Quelles sont tes raisons pour envisager d'utiliser une base de données NoSQL ? Les données d'une planche à image me semblent d'une nature très relationnelle (planche<->messages, messages<->ip, messages<->tripcode…).

46 .

>>45
Pour mnesia c'est pas compliqué, elle permet de stocker directement des termes erlang, est incluse par défaut et est de bonne qualité (c'est pas MongoDB 2.X). J'envisage dans le futur d'aller vers des données au format beaucoup plus variable et de choisir le versant AP plutôt que CP. C'est seulement une possibilité que je considère, si ce n'est pas utile je pense que PostgreSQL sera très bien.

47 .

>>44
La limite de temps c'est bien. Avec l'historique ça va être une prise de tête constante et insupportable. Et puis bon les erreurs ça arrive, tant pis.

Par contre un fil ou une place où le principe serait de pouvoir éditer ses messages n'importe comment, ça peut être rigolo aussi (mais pas besoin d'historique non plus).

48 .

>>46
Oui, le choix de Mnesia me paraissait cohérent, ma question venait plutôt de ta mention de CouchDB.

>>47
Pourquoi l'historique serait prise de tête ? Niveau interface utilisateur j'imaginais trois onglets sur le message avec la version la plus récente sélectionnée par défaut et un bouton pour modifier le message « en place ».

D'ailleurs, ça me fait penser, ce serait sympa d'avoir des balises pour poster du code (pas nécessairement avec coloration syntaxique, juste avoir du monospace serait déjà bien cool). On pourrait même imaginer avoir la possibilité de formater ses messages en markdown mais ça va un peu trop loin pour moi.
Et je me rends compte que la possibilité d'avoir des spoilers et des filtramots n'a pas été mentionnée dans l'inventaire de l'existant.

49 .

>>48
Prise de tête en mode

- tu as dit ça

- mais non j'ai pas dit ça

Markdown ça pourrait être bien oui, il doit y avoir des libs qui font ça quasi automatiquement non ?

50 .

>>49
Avec un historique et des dates d'édition il ne peut pas y avoir de débat, si quelque chose a été dit, on le retrouve dans les versions précédentes. Si un participant à la conversation va critiquer un message en se basant sur son ancienne version plutôt que la dernière publiée, c'est un abruti et il vaut mieux l'ignorer.
Le fait de ne pas avoir d'historique pourrait en revanche exacerber le problème que tu mets en évidence, même avec une limite temporelle (sauf si elle est très courte, ce qui rendrait la possibilité d'éditer ses messages vraiment inutile) Alice pourrait envoyer son message, Bob y répondre puis Alice pourrait changer son message sans aucune trace.

Il est fort probable qu'il y ait des bibliothèques permettant de convertir du markdown en HTML (au pire, Erlang a un mécanisme de ffi), seulement quand je vois le résultat que donne le fait de donner aux utilisateurs le fait de pouvoir gérer le formatage de leurs messages sur 8chan je ne suis pas sûr que ce soit une bonne idée.

51 .

>>50
Ok si tout le monde a accès à toutes les versions de tous les messages effectivement ça passe.

Mais bon reste que je n'aime pas trop, par exemple quelqu'un répond a un message, qui est modifié ensuite, et la réponse n'a alors plus beaucoup de sens.

Si le but c'était d'avoir des messages sérieux et techniques, corriger erreurs et inexactitudes est important, mais ce n'est pas vraiment le cas ici, et ça enlève un peu le côté « discussion spontanée ». Enfin comme d'hab tout dépend de l'utilisation qui en sera faite.

52 .

Ce message a été effacé.

53 .

En ajustant les structures de données de base (post, thread, etc.), une idée m'est venue : et si, au lieu de devoir taper « sage » pour ne pas faire remonter un fil, je supprimais le champ email, mettais un case à cocher « faire remonter le fil », le comportement par défaut devenant de sager ? Ça permettrait de virer un champ inutile tout en évitant de faire comme 4chan qui a fait disparaître l'usage du sage.

54 .

>>51
C'est un bon argument. Pour pallier à ce problème, on pourrait faire en sorte que les liens de réponse (tels que « >>308 ») pointent sur la dernière version du message qui existait au moment ou le message lui même a été envoyé.
D'après moi, ce cas de figure arrivera très peu de toute façon. Si l'utilisateur souhaite changer grandement le sens de son message, je pense qu'il préférera supprimer son message et en écrire un autre. Je vois l'édition plutôt comme le moyen de corriger des fautes de grammaire, d'orthographe ou de supprimer une insulte qui, après réflexion, n'avait pas sa place dans le message.

>>53
Ça me parait être une bonne idée, ça évitera aussi un faux pas au tas de bois vert occasionel.

55 .

Ce message a été effacé.

56 .

Pour l'édition, pourquoi pas la possibilité d'éditer tant qu'il n'y a pas de messages plus récents dans le fil ?

>>53
Le sage comportement par défaut ? N'est-ce pas un peu farfelu ? On va oublier de cocher une fois sur deux. En pratique on veut que le fil remonte 9 fois sur 10.

>>54
Pallier à

57 .

>>56
L'idée ce serait que tu ne fais remonter le fil que quand tu le souhaites vraiment. Avec l'arrivée du temps réel, je m'attends à ce que les fils générant beaucoup de réponses rapidement en échauffant les esprits prennent encore plus de place.

58 .

L'ânon qui avait partagé l'article inspiré de Muray a tous mes remerciements.

59 .

Comme j'ai enfin un peu de code à montrer, je poste le lien https://github.com/Adelyne/hanako

60 .

>>59
Que l'autisme nécessaire à la complétion de tout projet informatique soit avec toi.

61 .

Ça irait ces URLs pour l'API REST ? « :xxx » désigne un paramètre, et les ressources au pluriel sont des collections. On peut leur demander du JSON ou du HTML. Concrètement, à la place de « /a/37281.html » on aurait « /thread/a/37281 », et au lieu de « /a/catalog.html » on aurait « /threads/a?display=catalog ».

- `GET /boards`
- `GET /threads` + query string for sorting by date or display format (paginated, catalog...)
- `GET /threads/:board`
- `GET /posts` + query string for sorting by date or whatever
- `GET /posts/:threadid` + query string for sorting by date or whatever
- `GET /posts/reply/:postid` (list of replies to a post)
- `GET /thread/:board/:id`
- `PUT /thread/:board/`
- `POST /thread/:board/:id` (edit)
- `DELETE /thread/:board/:id`
- `GET /post/:board/:id`
- `PUT /post/:board/:thread`
- `POST /post/:board/:id` (edit)
- `DELETE /post/:board/:id`
- `DELETE /board/:id`
- `POST /board/:id`
- `PUT /board/:id`

62 .

>>61
J'ai le sentiment que sémantiquement `GET /posts/:postid/replies` aurait plus de sens que `GET /posts/reply/:postid` mais vouloir garder la partie « variable » à la fin de l'URL fait tout aussi sens (voir est plus propre) selon moi.
En dehors de ça, est-ce que c'est juste une erreur ou est-ce qu'il y a une différence entre les versions au pluriel et les versions au singulier (par exemple « thread » dans `GET /thread/:board/:id` et `GET /threads/:board`) ?

63 .

>>62
Les versions au pluriel retournent des collections, les versions au singulier un seul élément. GET /threads/:board retourne la liste de fils d'une planche, tandis que GET /thread/:board/:id retourne un fil précis.

64 .

>>63
D'autre part je vais virer les opérations PUT et les remplacer par PATCH pour les ressources existantes, et POST sur les collections pour la création d'une nouvelle ressource (en théorie PUT est supposé contenir une représentation complète, mais le champ « id » ne peut pas être connu à l'avance).

65 .

Le lien du doublon sur la page "Une vidéo avec cette ID a déjà été postée ici." (sur le "ici") est incorrect, il manque la partie host/.

66 .

Ah tiens, autre fonctionnalité que je trouve cool : avoir un log de toutes les actions prises par la modération (suppression de messages, bans...).

67 .

Ce lien a été posté y'a pas longtemps sur lainchan, peut être que ça pourra t'être utile : http://9ch.in/overscript/ .

68 .

Quand j'essaie de poster sur /a/ j'ai droit à une page blanche et mon message n'est pas enregistré.

69 .

Pardon pour les messages de spam restés 4 jours sans être effacés, je regardais acrimonie le soir complètement crevée et ça m'a échappé à chaque fois, je vais plutôt faire ça le matin.

70 .

>>69
On le sait que tu nous aimes plus.
Styles : Acrimonie Nuit