Forum distribué
Ouin ouin, onche c'est de la merde ya trop de KJ
Ouin ouin, JVC ya trop de censure
Ouin ouin, AVN c'est plein d'AW
==> On créerait pas un forum qui permet à tout le monde d'avoir enfin le forum qu'il veut sans avoir à quitter ce qu'il aime ?
L'idée
Tous les utilisateurs installent un client local (disons un docker + une DB) sur leur machine, répliquent et partagent le forum, mais aussi ce que les autres utilisateurs partagent. L'intérêt est multiple :
- C'est facile à Customiser
- Ca permet d'étendre le forum
- Ca permet de passer outre la censure et les downs
Fonctionnement
C'est tout simple, on aurait un server qui sert juste d'intermédiaire, un DNS en gros : tu lui dis ce que tu veux (je veux répliquer les topics ONCHE) et lui te dit où les récuperer (sur ce shéma, chez un autre utilisateur qui réplique déjà onche):
Le server te dit le hash de ce que tu veux, comme ça tu vérifies l'intégrité de ce qu'on t'envoie et évite qu'on t'envoie des virus, et te fournit une clé à donner au sharer pour que lui puisse vérifier que tu as bien demandé un truc au server avant et que tu ne viens pas juste lui DDOS sa grande daronne, il te file ce que tu lui a demandé, et le server t'enregistre comme sharer, on pourra aussi te demander cette ressource.
Customiser
- On peut déjà construire au delà des limites existantes du forum, puisque chacun est libre d'ajouter n'importe quoi à sa database locale. Exemple :
Ici on a un utilisateur qui veut tous les topics de Onche, les badges d'un cluster custom "No-KJ" qui cache les badges KJ, ne requiert aucune banlist spécifique, veut sauvegarder
localement le top 100 des stickers de Onche et de Noelshake, et veut la vue custom du FDVD.
Récuperer les topics de X
Notre utilisateur veut tous les topics de Onche, il les récupère soit d'un sharer soit de onche directement.
Pourquoi passer par un sharer ? Cela enlève la modération des sites. JVC et ses maudits 410 n'affecte plus personne puisque les sujets sont sauvegardés dans le clusters d'utilisateurs. Tu veux répondre à "[Débat] L'islam et Star Wars, lien" ? Tu peux faire ta longue réponse, JVC ne pourra plus te faire de mal, on continue la conversation longtemps après le 410.
Je compte sur cette feature pour être le moteur principal de migration depuis JVC. Tu veux continuer une discussion ? Pas de soucis, installe le client et continue le topic depuis le cluster. Onche est down ? Viens sur les clusters copain.
Ca permet également un autre point : aggréger les forums. Il n'est plus question de migration, ni même de partager des forums. Tu veux voir Onche seulement ? Demande seulement onche. Tu veux voir Onche, JVC, AVN ? Demande les 3. Tu veux ajouter le Forum Android de JVC ? Vas-y, demande. Comme ça, les utilisateurs ont leur propre expérience. On ne te demande plus de récréer un pseudo, de faire X ou Y. Tu installes un Client, tu indiques ce que tu récupères et avec quoi tu postes, et c'est parti.
Customiser les Rewards, les Banlistes, ...
On peut voir que notre bon utilisateur veut cacher les badges KJ (dans un univers alternatif ayant lieu après la prise de contrôle de Onche par les KJ)
Pour ça, on va se référer à ce diagram. 3 personnes dessus : Sharer Onche, User 1, User 2.
User 1 veut tous les rewardes de Onche, le server les récupère chez Sharer Onche, lui file, tout est bien qui finit bien.
Sharer Onche, étant un utilisateur basé et rougepillulé, a créé une table de badge locale qu'il a appelé No-KJ, qui ne contient pas les Badge KJ. Il le communique alors au server, qui retient que chez Sharer Onche, il y a une table local de badge qui s'appelle No-KJ. Quand User 2 demande au server la liste des clusters de badge, server lui répond qu'il existe un cluster No-KJ, et user 2 décide alors de répliquer cette table dans son propre environnement local, s'ajoutant au cluster.
Ainsi, un cluster customisé peut maintenir et s'étendre par popularité. On voit que le cluster des rewards FDVD est déjà bien étendu, et contient une database de Badge, ainsi que les ID des forumeurs à qui ils sont attribués. Petit apparté d'ailleurs, mais plutôt que de laisser les badge à la modération, c'est les utilisateurs qui peuvent les donner. Chaque user peut te +1 un badge dans un cluster, et à +X tu obtiens le badge. Seuls ceux qui ont copié le cluster en question voient ton badge, donc les footeux peuvent avoir leurs badge PSG ou OM, les KJ peuvent avoir leurs badge Gentil et Pédophile, les FDVD peuvent avoir leurs badges squelette,... sans qu'on n'ait à coexister ni même reconnaître les existences des uns des autres
Custom View
Plus que juste des tables, on pourrait aussi récuperer des modèles de frontend. Une custom view FDVD qui est le thème de base un peu halloween, avec des callback sur les badges du cluster FDVD pour créer des petites animations dans les postes des badgés. Par exemple. Je m'y connaît pas en front et ne sait pas à quel point c'est possible ou non, mais j'aime bien l'idée de partager les customisations du front.
Etendre le forum
Un autre point permis par ce genre d'architecture, c'est qu'on peut ETENDRE les forums. Par exemple, ni JVC, ni Onche n'ont de filtres de topics par tags. C'est problématique, parce que j'ai pas envie d'avoir les topics épinglés sous les yeux, ni de lire les blabla de foot.
Prenons un exemple : un utilisateur veut tous les topics de Onche, mais ne veut aucun qui est taggé comme "Foot" :
Afin de faciliter le partage de la totalité des topics, on lui fournit tous les topics, même ceux qu'il aurait filtré, et derrière, en local, il y a un filtrage qui se fait :
Dans ce cas précis, on peut voir que notre utilisateur est mécontent : le topic foot est passé. En effet, puisqu'on étend le forum, on ne peut se baser que sur les clusters : si personne n'a taggué le topic en question comme "foot", aucun moyen de savoir que c'est du foot. Alors notre utilisateur lui colle un +1 dans le tag foot, et update le cluster : tous les sharers updatent +1 en tag foot. De plus, comme sa règle (configurée localement), dit que dès qu'un topic a au moins 1 badge FOOT, on le cache.
Avoir des règles locales avec le poids des tags permet de ne cacher les topics qui ont un tag "CRINGE" qu'à partir de 5 reports. Comme ça, la politique n'est pas trop aggressive mais toujours efficace. Alors que dès qu'un tag "SCAT" ou "PEDO" apparaît, je veux une politique très aggressive, quitte à avoir des faux négatifs. On notera qu'on peut aussi filtrer directement sur d'autres fields de la database : on peut ne pas vouloir voir les topics de moins de 1j, par Azlok, qui contiennet le mot KJ, ...
Protection contre le DDOS
Puisqu'on n'a un server qui n'est au final qu'un DNS, on peut aussi se protéger des DOS de façon suivants :
- On établie une liste de sharer locaux qui veulent bien servir de DNS en cas de down. (backup)
- Ils peuvent eux même définir leur politique de délivrance : soit on sert les requêtes qui viennent de partout, soit seulement d'une whitelist de confiance (elle même distribuée sur le cluster pendant les phases UP, et maintenue localement). Ainsi, lors d'un DDOS, on passe en mode lockdown et seuls les utilisateurs de confiance (ceux qui ont été sharer pendant 1 mois, par exemple) peuvent accéder aux backups.
Légalement
2 points majeurs à régler :
- C'est très certainement considéré comme du vol de données (du scrapping) de répliquer les topics de JVC pour les distribuer sur un cluster. Pour Onche, AVN et autres plus petis forums, ce n'est probablement pas un problème, mais pour JVC en particulier il faudra étudier ce qui est possible et ce qui ne l'est pas avant même de commencer. Je n'ai aucune notion juridique et ne sait pas si des utilisateurs peuvent faire une requête HTTP en bonne foi, pour réellement utiliser les données selon le ToUA, mais les partager derrière.
- On s'affranchit de la modération et les contenus sont partagés en P2P, et stockés localement. Le server n'héberge rien. Mais disons qu'un utilisateur, qu'on nomera Benzedigimon pour conserver son anonymat, décide de menacer un individu de type pas menaçable sans action légale. On peut mettre un système de ban des messages et non réplication des messages bannis, suppression du cluster et compagnie, mais comment prouver que ça été fait dans les temps impartis par la loi française ? Qui sont les responsables ? Est-ce qu'un utilisateur normal qui sert de sharer et se retrouve à partager du pédo, par mécanisme de réplication + sharing P2P parce qu'un malade mental spam sur internet, avant que le contenu soit flag et détruit, est tenu responsable ?
Pour le point 2, si être sharer d'un Benzedigimon attire les utilisateurs en taule, ça tue le projet dans l'oeuf.
Si des jean juristes passent dans le coin, vous avez le micro.
Note
L'idée est en phase ... d'idée. Rien n'est commencé ni dans le marbre, probablement que 75% des idées ne sont pas faisables, ridiculement sous estimées, inutiles ou un mélange de 3. La mise en page est pas facile et les schéma un peu confus. Vous l'avez compris, c'est une idée.
Si vous avez n'importe quelle remarque / amélioration, je prends.
Ouin ouin, onche c'est de la merde ya trop de KJ
Ouin ouin, JVC ya trop de censure
Ouin ouin, AVN c'est plein d'AW
==> On créerait pas un forum qui permet à tout le monde d'avoir enfin le forum qu'il veut sans avoir à quitter ce qu'il aime ?
L'idée
Tous les utilisateurs installent un client local (disons un docker + une DB) sur leur machine, répliquent et partagent le forum, mais aussi ce que les autres utilisateurs partagent. L'intérêt est multiple :
- C'est facile à Customiser
- Ca permet d'étendre le forum
- Ca permet de passer outre la censure et les downs
Fonctionnement
C'est tout simple, on aurait un server qui sert juste d'intermédiaire, un DNS en gros : tu lui dis ce que tu veux (je veux répliquer les topics ONCHE) et lui te dit où les récuperer (sur ce shéma, chez un autre utilisateur qui réplique déjà onche):
Le server te dit le hash de ce que tu veux, comme ça tu vérifies l'intégrité de ce qu'on t'envoie et évite qu'on t'envoie des virus, et te fournit une clé à donner au sharer pour que lui puisse vérifier que tu as bien demandé un truc au server avant et que tu ne viens pas juste lui DDOS sa grande daronne, il te file ce que tu lui a demandé, et le server t'enregistre comme sharer, on pourra aussi te demander cette ressource.
Customiser
- On peut déjà construire au delà des limites existantes du forum, puisque chacun est libre d'ajouter n'importe quoi à sa database locale. Exemple :
Ici on a un utilisateur qui veut tous les topics de Onche, les badges d'un cluster custom "No-KJ" qui cache les badges KJ, ne requiert aucune banlist spécifique, veut sauvegarder
localement le top 100 des stickers de Onche et de Noelshake, et veut la vue custom du FDVD.
Récuperer les topics de X
Notre utilisateur veut tous les topics de Onche, il les récupère soit d'un sharer soit de onche directement.
Pourquoi passer par un sharer ? Cela enlève la modération des sites. JVC et ses maudits 410 n'affecte plus personne puisque les sujets sont sauvegardés dans le clusters d'utilisateurs. Tu veux répondre à "[Débat] L'islam et Star Wars, lien" ? Tu peux faire ta longue réponse, JVC ne pourra plus te faire de mal, on continue la conversation longtemps après le 410.
Je compte sur cette feature pour être le moteur principal de migration depuis JVC. Tu veux continuer une discussion ? Pas de soucis, installe le client et continue le topic depuis le cluster. Onche est down ? Viens sur les clusters copain.
Ca permet également un autre point : aggréger les forums. Il n'est plus question de migration, ni même de partager des forums. Tu veux voir Onche seulement ? Demande seulement onche. Tu veux voir Onche, JVC, AVN ? Demande les 3. Tu veux ajouter le Forum Android de JVC ? Vas-y, demande. Comme ça, les utilisateurs ont leur propre expérience. On ne te demande plus de récréer un pseudo, de faire X ou Y. Tu installes un Client, tu indiques ce que tu récupères et avec quoi tu postes, et c'est parti.
Customiser les Rewards, les Banlistes, ...
On peut voir que notre bon utilisateur veut cacher les badges KJ (dans un univers alternatif ayant lieu après la prise de contrôle de Onche par les KJ)
Pour ça, on va se référer à ce diagram. 3 personnes dessus : Sharer Onche, User 1, User 2.
User 1 veut tous les rewardes de Onche, le server les récupère chez Sharer Onche, lui file, tout est bien qui finit bien.
Sharer Onche, étant un utilisateur basé et rougepillulé, a créé une table de badge locale qu'il a appelé No-KJ, qui ne contient pas les Badge KJ. Il le communique alors au server, qui retient que chez Sharer Onche, il y a une table local de badge qui s'appelle No-KJ. Quand User 2 demande au server la liste des clusters de badge, server lui répond qu'il existe un cluster No-KJ, et user 2 décide alors de répliquer cette table dans son propre environnement local, s'ajoutant au cluster.
Ainsi, un cluster customisé peut maintenir et s'étendre par popularité. On voit que le cluster des rewards FDVD est déjà bien étendu, et contient une database de Badge, ainsi que les ID des forumeurs à qui ils sont attribués. Petit apparté d'ailleurs, mais plutôt que de laisser les badge à la modération, c'est les utilisateurs qui peuvent les donner. Chaque user peut te +1 un badge dans un cluster, et à +X tu obtiens le badge. Seuls ceux qui ont copié le cluster en question voient ton badge, donc les footeux peuvent avoir leurs badge PSG ou OM, les KJ peuvent avoir leurs badge Gentil et Pédophile, les FDVD peuvent avoir leurs badges squelette,... sans qu'on n'ait à coexister ni même reconnaître les existences des uns des autres
Custom View
Plus que juste des tables, on pourrait aussi récuperer des modèles de frontend. Une custom view FDVD qui est le thème de base un peu halloween, avec des callback sur les badges du cluster FDVD pour créer des petites animations dans les postes des badgés. Par exemple. Je m'y connaît pas en front et ne sait pas à quel point c'est possible ou non, mais j'aime bien l'idée de partager les customisations du front.
Etendre le forum
Un autre point permis par ce genre d'architecture, c'est qu'on peut ETENDRE les forums. Par exemple, ni JVC, ni Onche n'ont de filtres de topics par tags. C'est problématique, parce que j'ai pas envie d'avoir les topics épinglés sous les yeux, ni de lire les blabla de foot.
Prenons un exemple : un utilisateur veut tous les topics de Onche, mais ne veut aucun qui est taggé comme "Foot" :
Afin de faciliter le partage de la totalité des topics, on lui fournit tous les topics, même ceux qu'il aurait filtré, et derrière, en local, il y a un filtrage qui se fait :
Dans ce cas précis, on peut voir que notre utilisateur est mécontent : le topic foot est passé. En effet, puisqu'on étend le forum, on ne peut se baser que sur les clusters : si personne n'a taggué le topic en question comme "foot", aucun moyen de savoir que c'est du foot. Alors notre utilisateur lui colle un +1 dans le tag foot, et update le cluster : tous les sharers updatent +1 en tag foot. De plus, comme sa règle (configurée localement), dit que dès qu'un topic a au moins 1 badge FOOT, on le cache.
Avoir des règles locales avec le poids des tags permet de ne cacher les topics qui ont un tag "CRINGE" qu'à partir de 5 reports. Comme ça, la politique n'est pas trop aggressive mais toujours efficace. Alors que dès qu'un tag "SCAT" ou "PEDO" apparaît, je veux une politique très aggressive, quitte à avoir des faux négatifs. On notera qu'on peut aussi filtrer directement sur d'autres fields de la database : on peut ne pas vouloir voir les topics de moins de 1j, par Azlok, qui contiennet le mot KJ, ...
Protection contre le DDOS
Puisqu'on n'a un server qui n'est au final qu'un DNS, on peut aussi se protéger des DOS de façon suivants :
- On établie une liste de sharer locaux qui veulent bien servir de DNS en cas de down. (backup)
- Ils peuvent eux même définir leur politique de délivrance : soit on sert les requêtes qui viennent de partout, soit seulement d'une whitelist de confiance (elle même distribuée sur le cluster pendant les phases UP, et maintenue localement). Ainsi, lors d'un DDOS, on passe en mode lockdown et seuls les utilisateurs de confiance (ceux qui ont été sharer pendant 1 mois, par exemple) peuvent accéder aux backups.
Légalement
2 points majeurs à régler :
- C'est très certainement considéré comme du vol de données (du scrapping) de répliquer les topics de JVC pour les distribuer sur un cluster. Pour Onche, AVN et autres plus petis forums, ce n'est probablement pas un problème, mais pour JVC en particulier il faudra étudier ce qui est possible et ce qui ne l'est pas avant même de commencer. Je n'ai aucune notion juridique et ne sait pas si des utilisateurs peuvent faire une requête HTTP en bonne foi, pour réellement utiliser les données selon le ToUA, mais les partager derrière.
- On s'affranchit de la modération et les contenus sont partagés en P2P, et stockés localement. Le server n'héberge rien. Mais disons qu'un utilisateur, qu'on nomera Benzedigimon pour conserver son anonymat, décide de menacer un individu de type pas menaçable sans action légale. On peut mettre un système de ban des messages et non réplication des messages bannis, suppression du cluster et compagnie, mais comment prouver que ça été fait dans les temps impartis par la loi française ? Qui sont les responsables ? Est-ce qu'un utilisateur normal qui sert de sharer et se retrouve à partager du pédo, par mécanisme de réplication + sharing P2P parce qu'un malade mental spam sur internet, avant que le contenu soit flag et détruit, est tenu responsable ?
Pour le point 2, si être sharer d'un Benzedigimon attire les utilisateurs en taule, ça tue le projet dans l'oeuf.
Si des jean juristes passent dans le coin, vous avez le micro.
Note
L'idée est en phase ... d'idée. Rien n'est commencé ni dans le marbre, probablement que 75% des idées ne sont pas faisables, ridiculement sous estimées, inutiles ou un mélange de 3. La mise en page est pas facile et les schéma un peu confus. Vous l'avez compris, c'est une idée.
Si vous avez n'importe quelle remarque / amélioration, je prends.
T'as vraiment écrit tout ça ?
J'aime ma signature
C'est trop compliqué pour les pyjs ca
T'as vraiment écrit tout ça ?
Khey je m'apprête à dev un truc pendant plusieurs mois, c'est pas un pavé et quelques illustrations qui vont m'arrêter
Même si je suis pas encore arrêté sur l'architecture. Vu comme j'imagine ça, docker ça paraît indispensable pour le client local, et dedans je sais pas encore, sans doute du Java Spring pour les micro service et appels API, et JDBC pour le storage dans une DB. Mais encore une fois, rien dans le marbre.
Même si je suis pas encore arrêté sur l'architecture. Vu comme j'imagine ça, docker ça paraît indispensable pour le client local, et dedans je sais pas encore, sans doute du Java Spring pour les micro service et appels API, et JDBC pour le storage dans une DB. Mais encore une fois, rien dans le marbre.
Oui ça s'addresse plutôt aux dev du forum, et aux quelques juristes / kheys à idées.
Vous pouvez vous retourner sur les topics de guerre raciale promis je ferais pas trop de up intempestifs
Vous pouvez vous retourner sur les topics de guerre raciale promis je ferais pas trop de up intempestifs
Khey je m'apprête à dev un truc pendant plusieurs mois, c'est pas un pavé et quelques illustrations qui vont m'arrêter
Même si je suis pas encore arrêté sur l'architecture. Vu comme j'imagine ça, docker ça paraît indispensable pour le client local, et dedans je sais pas encore, sans doute du Java Spring pour les micro service et appels API, et JDBC pour le storage dans une DB. Mais encore une fois, rien dans le marbre.
Même si je suis pas encore arrêté sur l'architecture. Vu comme j'imagine ça, docker ça paraît indispensable pour le client local, et dedans je sais pas encore, sans doute du Java Spring pour les micro service et appels API, et JDBC pour le storage dans une DB. Mais encore une fois, rien dans le marbre.
Pas tout compris mais je up
Khey je m'apprête à dev un truc pendant plusieurs mois, c'est pas un pavé et quelques illustrations qui vont m'arrêter
Même si je suis pas encore arrêté sur l'architecture. Vu comme j'imagine ça, docker ça paraît indispensable pour le client local, et dedans je sais pas encore, sans doute du Java Spring pour les micro service et appels API, et JDBC pour le storage dans une DB. Mais encore une fois, rien dans le marbre.
Même si je suis pas encore arrêté sur l'architecture. Vu comme j'imagine ça, docker ça paraît indispensable pour le client local, et dedans je sais pas encore, sans doute du Java Spring pour les micro service et appels API, et JDBC pour le storage dans une DB. Mais encore une fois, rien dans le marbre.
Ah mais c'est toi qui veut développer ce nouveau forum ? J'avais compris que tu demandais aux devs d'ici de faire ça
J'aime ma signature
Ah mais c'est toi qui veut développer ce nouveau forum ? J'avais compris que tu demandais aux devs d'ici de faire ça
Non, je demande de l'aide sur l'architecture, sur les features, et sur le point juridique.
Si je trouve des kheys deter le repo sera ouvert et ils pourront faire des PR, pas de soucis. C'est juste que pour l'instant, si un khey me dit "euh gros t'es au courant qu'il n'existe aucune architecture qui permet de t'assurer que tes sharers sont à jours avec Onche" bah je vais devoir revoir les bases, alors que si un khey passe et me dit "tiens c'est exactement ce que fait ce repo + lien github" bah j'économise plusieurs mois de travail à tatonner une architecture viable
Si je trouve des kheys deter le repo sera ouvert et ils pourront faire des PR, pas de soucis. C'est juste que pour l'instant, si un khey me dit "euh gros t'es au courant qu'il n'existe aucune architecture qui permet de t'assurer que tes sharers sont à jours avec Onche" bah je vais devoir revoir les bases, alors que si un khey passe et me dit "tiens c'est exactement ce que fait ce repo + lien github" bah j'économise plusieurs mois de travail à tatonner une architecture viable
Non, je demande de l'aide sur l'architecture, sur les features, et sur le point juridique.
Si je trouve des kheys deter le repo sera ouvert et ils pourront faire des PR, pas de soucis. C'est juste que pour l'instant, si un khey me dit "euh gros t'es au courant qu'il n'existe aucune architecture qui permet de t'assurer que tes sharers sont à jours avec Onche" bah je vais devoir revoir les bases, alors que si un khey passe et me dit "tiens c'est exactement ce que fait ce repo + lien github" bah j'économise plusieurs mois de travail à tatonner une architecture viable
Si je trouve des kheys deter le repo sera ouvert et ils pourront faire des PR, pas de soucis. C'est juste que pour l'instant, si un khey me dit "euh gros t'es au courant qu'il n'existe aucune architecture qui permet de t'assurer que tes sharers sont à jours avec Onche" bah je vais devoir revoir les bases, alors que si un khey passe et me dit "tiens c'est exactement ce que fait ce repo + lien github" bah j'économise plusieurs mois de travail à tatonner une architecture viable
J'y connais rien en dev mais il faudrait juste que Onche propose une API pour que tout le monde ai accès au même Onche, pas besoin de distribué.
J'aime ma signature
Tu veux un forum en p2p donc :zizou_sourit:
Ça me rappelle le projet FreeNet :zizou_sourit:
Ça me rappelle le projet FreeNet :zizou_sourit:
Khey Texan
Ouais c'est l'idée, un forum en P2P
Douce idée de doux idéaliste peut-être
Douce idée de doux idéaliste peut-être
L'idée c'est que le cluster se nourrit du forum, mais que si le forum disparaît, le cluster survit. A l'inverse, si le cluster disparaît, on peut le régénérer à partir du forum.
Mais oui, je vois pas trop pourquoi maintenir une structure pour 0 connectés.
Mais oui, je vois pas trop pourquoi maintenir une structure pour 0 connectés.
Ton projet est Impossible notemment à cause des protections contre le scrapping / crawling
Refusé
Mais justement, vu que les infos sont demandées en bonne foi par des utilisateurs, c'est pas du scrapping. Les users font les requêtes directement auprès du server de X, et parsent et sauvegardent les données en local. Ya pas une instance de scrapping, c'est de l'utilisation normale de forum, mais enrichissant la DB locale..
Et tu penses vraiment que quelqu'un à part toi va autoriser un outils à récupérer ses requêtes http ?
un forum skyrock p2p, pas mal
go le faire avec tor
go le faire avec tor
Cette description n'est plus disponible sur onche.org suite à une modération du contenu ou autre action du staff