;
Automated updates of the Yunohost packages work rather well. This is why packages for Streams, Forte and Mitra usually allow you to run the latest releases.
Good news. Mitra is now officially available in the YunoHost apps catalog, as a working app.
I've just remembered that some of the people I'm connected with live in Germany or are originally from there. My eldest son is going to Bayern in a few days with other students from his secondary school. He will be staying with a local family for a week.
We're wondering what he could bring to the family who are kind enough to host him. My better half will be baking macarons, which are one of the most French things you can find, but we're a little short of ideas for other things he could bring with him. We don't think alcohol or wine would be appropriate.
So, my dear German friends, what kind of French delicacies would you like to receive if you were in the shoes of the family who will be welcoming our son?
We're wondering what he could bring to the family who are kind enough to host him. My better half will be baking macarons, which are one of the most French things you can find, but we're a little short of ideas for other things he could bring with him. We don't think alcohol or wine would be appropriate.
So, my dear German friends, what kind of French delicacies would you like to receive if you were in the shoes of the family who will be welcoming our son?
Mayonnaise is special, not everyone likes it and there are lots of different kinds. On the other hand, I like the idea of sea salt, because it's true that we have several regions where it's produced in an artisanal way, like in Noirmoutier.
And what about chocolate? Is there any German savoir-faire in this area?
And what about chocolate? Is there any German savoir-faire in this area?
@Thomas (aka Papa Dragon)
I would say, chocolate always works. Just, you know, from what I know of my friends. Not at all from personal experience.
And what about chocolate? Is there any German savoir-faire in this area?
I would say, chocolate always works. Just, you know, from what I know of my friends. Not at all from personal experience.
Working on packaging the new release of the Streams repository for YunoHost. To be fair, there's not much to do:
There has to be a way to write a tiny script to handle this in a more automated way. I just don't have time to work on this right now.
- Updating the code takes less than 3 minutes (essentially copy pasting commit references and a sha256 sum),
- Testing it with the YunoHost package checker takes around 20 minutes,
- Having the package upgrade available through the YunoHost admin interface usually takes a few hours (I don't know how it exactly works)
There has to be a way to write a tiny script to handle this in a more automated way. I just don't have time to work on this right now.
I'd be questioning why it needs a commit reference at all and try and find a way to bypass that bit. If there's a good reason for it, fine - but it seems like just another silly little restriction that somebody imposed at one point in time to save some effort; and it just creates more effort for everybody else in perpetuity.
Question for all streams-based websites admins, how did you install your websites?
Feel free to add any additional info in the comments!
(Reposting this on my channel, as poll did not work when shared on a group)
(Feel free to share/repeat!)
Manually, using the repo's INSTALL.txt instructions
Using one of the install scripts in the repo's 'contrib' folder
On a YunoHost server, with the Streams package
As a preinstalled app offered by a hosting provider (like K&T Host)
Feel free to add any additional info in the comments!
(Reposting this on my channel, as poll did not work when shared on a group)
(Feel free to share/repeat!)
Manually, using the repo's INSTALL.txt instructions
1 Vote
Using one of the install scripts in the repo's 'contrib' folder
1 Vote
On a YunoHost server, with the Streams package
1 Vote
As a preinstalled app offered by a hosting provider (like K&T Host)
1 Vote
Le sondage est terminé.
I really need to change my mind these days.
So here's a new #YunoHost package I worked on: https://github.com/YunoHost-Apps/zusam_ynh
I'm installing this. Should be perfect to convince our grannies and grampas not to use WhatsApp or iCloud to send us pics or videos.
If you want to give it a try, the author has a demo website : https://demo.zusam.org/
So here's a new #YunoHost package I worked on: https://github.com/YunoHost-Apps/zusam_ynh
I'm installing this. Should be perfect to convince our grannies and grampas not to use WhatsApp or iCloud to send us pics or videos.
If you want to give it a try, the author has a demo website : https://demo.zusam.org/
Update on the YunoHost Package - We're there
I'm happy to annouce that the #streams app is now available on #YunoHost. As it is my very first package for this solution, I admit I'm kinda proud. Hence the frame.
If you have a YunoHost server running you can find it in the Application catalog. For the moment, it still appears there as a broken app. This is because the bot that updates the apps integration level only runs every friday. So, on the Github repo it shows as an app with Integration Level 7 (on a scale of 8, yay!) while in the admin of your YunoHost server it appears as broken. Should be fixed next friday or saturday.
For the moment the LDAP integration is not configured. This means that YunoHost users can't connect with their YunoHost usernames and go straight to channel creation. My next task is to see if anything can be done on that matter. I don't know zip about php so I'll probably be asking for some help with the ldapauth addon.
That's it for today, and that's quite a lot. I hope this will help those who are still hesitating about setting up their own server to make the leap.
//
Je suis heureux de vous annoncer que le package #streams est maintenant disponible sur #YunoHost. Comme c'est mon tout premier package pour ce système, j'avoue que je suis un peu fier. D'où le cadre.
Si vous avez un serveur YunoHost, vous pouvez trouver l'application streams dans le catalogue. Pour l'instant, elle y apparaît toujours comme une application cassée. Ceci est dû au fait que le bot qui met à jour le niveau d'intégration des applications ne s'exécute que tous les vendredis. Sur le repo Github, elle apparaît comme une application avec un niveau d'intégration de 7 (sur une échelle de 8!) alors que dans l'administration de votre serveur YunoHost, elle apparaît comme cassée. Cela devrait être corrigé vendredi ou samedi prochain.
Pour le moment, l'intégration LDAP n'est pas activée. Cela signifie que les utilisateurs de YunoHost ne peuvent pas se connecter avec leur nom d'utilisateur YunoHost et aller directement à la création de canal. Mon prochain objectif est de voir si quelque chose peut être fait pour y remédier. Je ne m'y connais pas du tout en php, je demanderai donc probablement demander de l'aide avec l'addon ldapauth.
Voilà, c'est tout pour aujourd'hui, et c'est déjà pas mal. J'espère que cela aidera ceux qui hésitent encore à mettre en place leur propre serveur à franchir le pas.
Today, an incident reminded me how useful it would be that nomadic identity became widespread within the fediverse. I run a Mastodon instance. Or at least I ran one. But something went wrong during the last update and my backups were totally useless, I wasn't able to restore it.
Long story short, I installed a brand new instance, using the very same domain name and even the same ID. Some of the few followers I had did follow me again automatically, but not all of them. And I no longer followed anyone. And of course, all of my content was lost.
Fortunately, Mastodon is no vital for me. I follow a few dozens account which provide interesting content, but I can't really say I have a rich social life there. But I do understand some people can. So, if losing my account and my content is not a drama for me, it can be different for others. And that's when you remember how important the nomadic identity feature can be.
I'm not to used to make backups of the websites I run. I had a backup for my Mastodon instance, automatically created before the upgrade on my YunoHost server. Turns out, the backup could not be restored in one click as it should. I did a little search to see if I could solve the problem by myself, but soon gave up. I don't know anything about PostgreSQL. Not even how it is pronounced.
Anyhow I ended up reinstalling a new single-user instance, with none of my previous posts and no followers at all. I don't care. But if you are more into social networks than me, this probably sounds unacceptable. If on very rare occasions they are down, Facebook, Instagram or Twitter will probably not lose your content or your contacts. While shit like that can happen on a tiny fediverse server operated by a techie pal or a geeky cousin.
Selfhosting buffs like me don't have the skills of the army of IT workers who maintain the gigantic commercial social networks. If you have an account on my fediverse server, you can't trust that I'll be able to restore your online identity if something goes wrong. So there has to be a solution to protect your online identity from disappearing if the server it is tied to ends up crashing.
"Nomadic identity, duh." would say any Hubzilla or Zap family user. And that would be totally right. A solution exists that can make sure your online identity and data can be safe even if the server that hosts them vanishes someday. All it takes is having your account cloned on another server you trust. Piece of cake.
If Mastodon had the same feature, in addition to my main instance which runs in a VPS, I'd have a backup instance on a server at home. If my VPS instance had crashed like it did today, it would have been not only possible but also easy to restore my data. I really don't undestand why this kind of feature is not worked on as a main priority. Not that I think it's something easy to implement, but that would be so useful in a decentralized network.
Some may wonder why I reinstalled a Mastodon instance while I know it does not include such a cool feature. It lacks support for nomadic identity, and it's a shame, yes. But it has other cool features. Like those fancy smartphone apps such as Fedilab or Tusky. I know this could convince some of the many Facebook users I have among my closed ones to try something else. And, if you think about it, many people have a Facebook account AND an Instagram account AND a Twitter account AND a TikTok account, so why couldn't you have a Zot/Nomad account AND a Mastodon account?
Long story short, I installed a brand new instance, using the very same domain name and even the same ID. Some of the few followers I had did follow me again automatically, but not all of them. And I no longer followed anyone. And of course, all of my content was lost.
Fortunately, Mastodon is no vital for me. I follow a few dozens account which provide interesting content, but I can't really say I have a rich social life there. But I do understand some people can. So, if losing my account and my content is not a drama for me, it can be different for others. And that's when you remember how important the nomadic identity feature can be.
I'm not to used to make backups of the websites I run. I had a backup for my Mastodon instance, automatically created before the upgrade on my YunoHost server. Turns out, the backup could not be restored in one click as it should. I did a little search to see if I could solve the problem by myself, but soon gave up. I don't know anything about PostgreSQL. Not even how it is pronounced.
Anyhow I ended up reinstalling a new single-user instance, with none of my previous posts and no followers at all. I don't care. But if you are more into social networks than me, this probably sounds unacceptable. If on very rare occasions they are down, Facebook, Instagram or Twitter will probably not lose your content or your contacts. While shit like that can happen on a tiny fediverse server operated by a techie pal or a geeky cousin.
Selfhosting buffs like me don't have the skills of the army of IT workers who maintain the gigantic commercial social networks. If you have an account on my fediverse server, you can't trust that I'll be able to restore your online identity if something goes wrong. So there has to be a solution to protect your online identity from disappearing if the server it is tied to ends up crashing.
"Nomadic identity, duh." would say any Hubzilla or Zap family user. And that would be totally right. A solution exists that can make sure your online identity and data can be safe even if the server that hosts them vanishes someday. All it takes is having your account cloned on another server you trust. Piece of cake.
If Mastodon had the same feature, in addition to my main instance which runs in a VPS, I'd have a backup instance on a server at home. If my VPS instance had crashed like it did today, it would have been not only possible but also easy to restore my data. I really don't undestand why this kind of feature is not worked on as a main priority. Not that I think it's something easy to implement, but that would be so useful in a decentralized network.
Some may wonder why I reinstalled a Mastodon instance while I know it does not include such a cool feature. It lacks support for nomadic identity, and it's a shame, yes. But it has other cool features. Like those fancy smartphone apps such as Fedilab or Tusky. I know this could convince some of the many Facebook users I have among my closed ones to try something else. And, if you think about it, many people have a Facebook account AND an Instagram account AND a Twitter account AND a TikTok account, so why couldn't you have a Zot/Nomad account AND a Mastodon account?
Yes, correct, "it" is Streams. I need to write more clearly.
Backups? What backups?
sensitive - vue
Great day, the automated install script I've been working on recently was merged in the dev branch of the Streams repository.The few tests I've made both with Nginx & Apache were successful, so feel free to give it a try, folks. In the whiptail dialogs interface that can be used, there's only one thing I have not worked on: the external USB drive backup. If you need it, you can still run the script using a manually edited config file where this backup option is available.
Among the many necessary or possible improvements to the .easyinstall folder (it's not .homeinstall anymore) that I plan to spend some time on, is the issue of backups. Personally, I'm running in "mad dog" mode, since I don't use a backup system for my Zap server. As this is a single-user server, which is mainly used as a long-term test machine, on which I don't really store vital or sensitive information, I don't really worry about this issue. But I know I should. And I think I will.
I would be interested to know if the Streams/Zap & family/Streams admins have set up backup systems, and if so which solutions they have chosen to use. The idea would be to be able to add (those for which it is possible) to the features of the install script. The solution currently available sounds fine for a small server at home. It is for the case where you host your site on a remote server that there is surely something to do.
So, people...
How do you do that? Or how would you do that?
![backups.jpg]( "backups.jpg")
Among the many necessary or possible improvements to the .easyinstall folder (it's not .homeinstall anymore) that I plan to spend some time on, is the issue of backups. Personally, I'm running in "mad dog" mode, since I don't use a backup system for my Zap server. As this is a single-user server, which is mainly used as a long-term test machine, on which I don't really store vital or sensitive information, I don't really worry about this issue. But I know I should. And I think I will.
I would be interested to know if the Streams/Zap & family/Streams admins have set up backup systems, and if so which solutions they have chosen to use. The idea would be to be able to add (those for which it is possible) to the features of the install script. The solution currently available sounds fine for a small server at home. It is for the case where you host your site on a remote server that there is surely something to do.
So, people...
How do you do that? Or how would you do that?
Some web hosting companies will make backups and restore them for you so you don't have to mess with the technical stuff. Depending on the price and type of web hosting plan, this is either included or an extra fee.
On web hosts that will restore backups for you, restoring your website is just a support ticket away, assuming you didn't wait too long (since they rotate backups).
Another option is to use hosting with a control panel, such as WHM/cPanel. It has built-in support for backups & restores with a simple user interface.
So there are options for less technical people.
But nomadic identity gives you more flexibility since you can actually move your identity to another domain name and server and not lose anything. It's not the same as a web hosting account backup though. It's a backup for your social identity.
On web hosts that will restore backups for you, restoring your website is just a support ticket away, assuming you didn't wait too long (since they rotate backups).
Another option is to use hosting with a control panel, such as WHM/cPanel. It has built-in support for backups & restores with a simple user interface.
So there are options for less technical people.
But nomadic identity gives you more flexibility since you can actually move your identity to another domain name and server and not lose anything. It's not the same as a web hosting account backup though. It's a backup for your social identity.
Jusqu'à dimanche, le CNRS et l'INRIA font une simulation de l'élection au jugement majoritaire, l'expérience parait intéressante. Je me suis prêté au jeu, je vous invite à le faire aussi. Pour la Science, au moins.
MieuxVoter2022.fr : exprimez enfin vos opinions !
MieuxVoter2022.fr : exprimez enfin vos opinions !
Notre démocratie est malade de son mode de scrutin. Vote utile, vote contre, vote barrage, vote blanc : autant de symptômes d’un système qui dysfonctionne. La recherche Française a conçu un nouveau mode de scrutin, le jugement majoritaire, qui ouvre la voie vers une vie démocratique plus saine. Notre but : expérimenter massivement ce nouve...
Work in progress
Now entering the save/edit settings part. Much fun to come.
I'm only working on a script that helps setting the variables present in setup.config.txt.template (+ required DDNS settings in the relevant files). There's nothing about the mail there. For now, I'm just working on the existing. Next steps I'll be working on are:
1/ Saving the settings at the end (and re-using them later on if present),
2/ Variables for the backup on external storage configuration.
Someday, I hope I'll be able to work on other backup options (backup on an a distant server via rsync or borg, for instance), but that's probably not in a near future.
1/ Saving the settings at the end (and re-using them later on if present),
2/ Variables for the backup on external storage configuration.
Someday, I hope I'll be able to work on other backup options (backup on an a distant server via rsync or borg, for instance), but that's probably not in a near future.
Je bosse sur un script qui ajoute une interface un peu plus user-friendly au script d'installation automatisé du dépôt Git Streams. Pour le moment, si tu veux installer un site toi-même en auto-hébergement, soit tu fais tout à la main étape par étape pour chaque composant nécessaire, soit tu utilises un script d'installation automatisé qui impose d'éditer en ligne de commande un fichier de configuration.
"Éditer en ligne de commande", en soi, ce n'est pas du tout sorcier, mais enfin, ça peut faire un peu peur. Ce que je fais, c'est essayer de développer un genre de surcouche qui permet de faire tous les réglages demandés dans le fichier de configuration avec une interface qui puisse paraître un peu plus accessible à ceux qui ne sont pas familiarisés avec la ligne de commande.
"Éditer en ligne de commande", en soi, ce n'est pas du tout sorcier, mais enfin, ça peut faire un peu peur. Ce que je fais, c'est essayer de développer un genre de surcouche qui permet de faire tous les réglages demandés dans le fichier de configuration avec une interface qui puisse paraître un peu plus accessible à ceux qui ne sont pas familiarisés avec la ligne de commande.
Crazy thought time. What if, instead of having to edit a config file in the terminal, the install could be made using interactive dialog boxes? Something like this:
That's what I plan to be doing these days if I need to change my mind a bit.
And I actually need to.
That's what I plan to be doing these days if I need to change my mind a bit.
And I actually need to.
The way I see it, the idea is to collect all the necessary variables present in
I also have in mind an option to save the settings in a reusable config file.
server-config.txt.template (and in DDNS scripts) through dialog boxes. Before running server-setup.sh, a summary of the settings you entered will appear, and you'll be asked to choose between starting the proper install and editing your settings if necessary.I also have in mind an option to save the settings in a reusable config file.
Some progress on the installation script
I've been quite busy lately. Spent most of my nights in the room that serves as my office when I work from home. Annualization of working time magic. Anyhow, I spent most of my 1:30 AM breaks working on the homeinstall folder of the Streams repository.
There has been some progress. As planned I moved the Dynamic DNS (DDNS) part in separate scripts, one per provider. So now we have a "ddns"folder, which contains a script for FreeDNS ad another for selfHOST.de, which basically contain the functions previously included in the setup script.. I also added a script for Gandi (my registrar for years). Some things work, some don't. Here's where we're at:
- FreeDNS: after creating an account and a subdomain on freedns.afraid.org (with a wrong IP address), the script was successfully run by the setup script and correctly updated the IP address linked to the subdomain. Unfortunately, there seems to be some kind of propagation delay so the ping doesn't work and the setup script ultimately fails. I checked and it took half an hour before the right IP got pinged. For now, the best thing to do is probably to set the right IP when creating the subdomain on FreeDNS's website. Seems obvious if your server is at home, but not that much if you use a VPS (EDIT: a VPS with a Dynamic IP??? Duh.).
- selHOST.de: I did not test it. I'm not one of their clients, so... It should work. Unless there also is a propagation delay issue.
- Gandi: Almost works perfectly. The script uses actually installs a nice script (available here) and uses it to create the subdomain. Of course, you need to own the domain in the first place, but you don't need to create the subdomain on Gandi's user interface, you just have to put it in the main config file before running the setup script and that's it. The only minor issue I have is with the check_https function wihich show an error. It does not interrupt the program though, so the website really gets installed in the end. I don't know if the check_https needs some improvement, or if there could also be a propagation delay issue here too.
I don't know much about the DNS, but I know that changes on DNS records can require some time before being applied all over internet. I'm wondering if, in case of an install that requires a DDNS solution, there should be a first check in the setup script. Like, one of the first things done would be to ping the website's FQDN and only allow the install after a successful ping (with a "Try again a little later message" if it fails).
As it is now, the setup script installs MariaDB and creates the database and its user BEFORE taking care of the DDNS stuff. So if the install fails because of that and you try to re-run the setup script, you'll get an error message telling you that the database already exists and you'll have to delete it manually. Which is not something the users of the homeinstall script should have to be doing, I guess (knowing that in addition to DB deletion there are a few other things to get rid of before retrying an install). Hence the idea of making sure that everything is ready in terms of DDNS before installing the website.
If you want to test on your side, it's here: https://codeberg.org/thomas/streams/src/branch/homeinstall/.homeinstall
Suggestions are more than welcome.
There has been some progress. As planned I moved the Dynamic DNS (DDNS) part in separate scripts, one per provider. So now we have a "ddns"folder, which contains a script for FreeDNS ad another for selfHOST.de, which basically contain the functions previously included in the setup script.. I also added a script for Gandi (my registrar for years). Some things work, some don't. Here's where we're at:
- FreeDNS: after creating an account and a subdomain on freedns.afraid.org (with a wrong IP address), the script was successfully run by the setup script and correctly updated the IP address linked to the subdomain. Unfortunately, there seems to be some kind of propagation delay so the ping doesn't work and the setup script ultimately fails. I checked and it took half an hour before the right IP got pinged. For now, the best thing to do is probably to set the right IP when creating the subdomain on FreeDNS's website. Seems obvious if your server is at home, but not that much if you use a VPS (EDIT: a VPS with a Dynamic IP??? Duh.).
- selHOST.de: I did not test it. I'm not one of their clients, so... It should work. Unless there also is a propagation delay issue.
- Gandi: Almost works perfectly. The script uses actually installs a nice script (available here) and uses it to create the subdomain. Of course, you need to own the domain in the first place, but you don't need to create the subdomain on Gandi's user interface, you just have to put it in the main config file before running the setup script and that's it. The only minor issue I have is with the check_https function wihich show an error. It does not interrupt the program though, so the website really gets installed in the end. I don't know if the check_https needs some improvement, or if there could also be a propagation delay issue here too.
I don't know much about the DNS, but I know that changes on DNS records can require some time before being applied all over internet. I'm wondering if, in case of an install that requires a DDNS solution, there should be a first check in the setup script. Like, one of the first things done would be to ping the website's FQDN and only allow the install after a successful ping (with a "Try again a little later message" if it fails).
As it is now, the setup script installs MariaDB and creates the database and its user BEFORE taking care of the DDNS stuff. So if the install fails because of that and you try to re-run the setup script, you'll get an error message telling you that the database already exists and you'll have to delete it manually. Which is not something the users of the homeinstall script should have to be doing, I guess (knowing that in addition to DB deletion there are a few other things to get rid of before retrying an install). Hence the idea of making sure that everything is ready in terms of DDNS before installing the website.
If you want to test on your side, it's here: https://codeberg.org/thomas/streams/src/branch/homeinstall/.homeinstall
Suggestions are more than welcome.
Just in case one day I want use Gandi myself I would very much appreciate if you could provide this info in the readme.md or in the script as explanation.
There's a sub folder named "ddns" that contains one script per provider, with a few instructions.
I'm almost done here, I just have to solve a few DNS cache issues.
sensitive - vue
Done. DNS Successfully tested with FreeDNS and Gandi. Won't be testing with selfHOST.de as I don't have an account there. Should work with Apache and Nginx.
Next step is probably to rewrite the README a little and have a look at more sensitive stuff like webserver(s) configuration. Also, Adminer does not seem to work any longer.
Next step is probably to rewrite the README a little and have a look at more sensitive stuff like webserver(s) configuration. Also, Adminer does not seem to work any longer.
Woohoo! Successfully installed a website using the Streams repository and a single shell script (based on the one available in the .homeinstall folder of Zap)! Or almost, a few things had to be done manually.
Only tested it with Nginx using localhost, can't see why it wouldn't work using a real domain name, I'll test this as soon as I can. Should even work better.
Only "major" issues I have are related to Composer. When run from the script I get a message telling me the command is unavailable (while it can be found in /usr/local/bin/) and when run manually there's a message saying that it can not be run by root, which is actually possible after answering yes to a prompt. Figuring this out should just require a little extra time.
If you feel like having a look at it, the script can be found here.
Only tested it with Nginx using localhost, can't see why it wouldn't work using a real domain name, I'll test this as soon as I can. Should even work better.
Only "major" issues I have are related to Composer. When run from the script I get a message telling me the command is unavailable (while it can be found in /usr/local/bin/) and when run manually there's a message saying that it can not be run by root, which is actually possible after answering yes to a prompt. Figuring this out should just require a little extra time.
If you feel like having a look at it, the script can be found here.
Well, seems to work, both with Nginx and Apache.The script probably needs some cleanup and optimizations, but as is, it does the job.
The setup script allows to configure the server to use two DynDNS providers (selfHOST.de and FreeDNS). I don't know if this feature is useful to lots of people or if it could safely be removed.
On one hand I understand that if you plan to self-host on a Raspi@home with nothing but a landline with non-static IP address you can certainly have the use for that kind of functionality. On the other hand, I don't see why those two providers should be highlighted (especially the non-free one) rather that other ones who offer the same kind of service.
On one hand I understand that if you plan to self-host on a Raspi@home with nothing but a landline with non-static IP address you can certainly have the use for that kind of functionality. On the other hand, I don't see why those two providers should be highlighted (especially the non-free one) rather that other ones who offer the same kind of service.
Retour sur la feuille de route
<p>J'ai publié hier une traduction de la publication que @mike a consacrée à la feuille de route qu'il envisage concernant l'avenir du projet Zap et de sa famille, ainsi que celui du projet qui lui succédera, pour le moment identifié sous le nom de "Streams". Ce texte étant relativement touffu, il me semble utile de revenir sur certains points qui y figurent.</p>
<h4>Sur le devenir de Zap et ses dérivés</h4>
<p>Le tableau qui ouvre la publication est clair: passé 2022, il n'y aura plus de développement ni de support pour Zap et sa famille (Mistpark, Osada, Redmatrix et Roadhouse). Concrètement, il sera possible, pour ne pas dire nécessaire, de faire évoluer tout site s'appuyant sur Zap ou un de ses dérivés pour le "faire tourner" avec avec le logiciel proposé sur le dépôt Streams, à l'aide d'un simple script. Sauf à vouloir continuer à utiliser un logiciel obsolète et donc plus forcément sûr.</p>
<p>Hubzilla étant un cousin suffisamment proche de Zap, il sera également possible d'importer un canal hébergé sur un site Hubzilla vers un site créé à l'aide du dépôt Streams. J'utilise le terme "importer" plutôt que "cloner", parce qu'on parle bien d'une importation unique sans synchronisation par la suite. En gros, la procédure consistera à transférer, pour ceux qui le souhaiteraient, leur canal d'un site Hubzilla vers un site créée en utilisant le dépôt Streams (qui utilisera donc aussi des canaux). Ce qui restera une simple possibilité et pas du tout une obligation, Hubzilla poursuivant son développement de son côté.</p>
<h4>Ce que j'ai compris de Streams</h4>
<p>L'un des principes les plus originaux du projet Streams est celui de son "invisibilisation" au profit de l'identité propre de votre site. Concrètement, si vous créez un site en utilisant le dépôt Streams, vous pouvez une fois l'installation terminée proposer à vos proches de s'inscrire sur votre site, point barre. Pas sur une instance Streams ou un serveur Streams, non, simplement sur votre site, depuis lequel tout le fediverse compatible avec les protocoles ActivityPub et/ou Nomad sera joignable.</p>
<p>Dit comme ça, ça n'a l'air de rien, mais c'est en réalité une façon d'aborder les choses très différente, qui ne limite pas le fediverse à une réunion de plateformes de réseaux sociaux capables d'interagir les uns avec les autres. Le dépôt Streams offre la possibilité d'intégrer le fediverse sans devoir arborer une bannière ou une marque particulière, en ne contribuant pas à augmenter la part de marché de tel ou tel projet. Finalement, c'est un peu le dépassement du concept de réseaux sociaux pour arriver à un nouvelle façon d'interagir sur le web dans sa globalité.</p>
<p>J'ai peut-être un peu de mal à trouver les mots. En tout cas, je trouve la proposition très chouette.</p>
<h4>Sur les incompatibilités annoncées</h4>
<p>Il est fait mention du fait que Pleroma ne pourra pas communiquer avec un site créé grâce au projet Streams, ce qui peut sembler étonnant dans la mesure où ActivityPub est supposé être géré des deux côtés. Honnêtement, je ne sais pas à quoi ça tient, je ne peux que supposer que c'est dû à des façons différentes d'envisager l'utilisation du protocole. J'ignore à quel point cette problématique peut relever ou non de l'insurmontable.</p>
<p>Pour ce qui est de Diaspora*, c'est plus clair, puisque pour le moment il n'est pas question que ce projet implémente le protocole ActivityPub, qui est présentement le plus utilisé au sein du fediverse. On imagine donc que le protocole Nomad est encore moins à l'ordre du jour pour Diaspora*, même s'il est le seul à permettre une véritable identité nomade (en gros, le fait de disposer d'un compte n'étant pas obligatoirement lié à un site donné, et même de pouvoir déménager celui-ci d'un site à l'autre en toute transparence pour ses contacts).</p>
<h4>Logiciel libre ou propriétaire</h4>
<p>La question de l'absence de licence pour le logiciel disponible sur le dépôt Streams pourrait paraître problématique à certains. Il me semble qu'elle ne l'est pas, et qu'il n'y a pas vraiment besoin de le justifier. Le commentaire de mike sur ce point me semble suffisant, sans devoir creuser plus loin.</p>
<h4>Mes interrogations quant à la suite</h4>
<p>C'est assez court, puisqu'il n'y en a pas. J'avoue attendre avec une certaine impatience le moment où je pourrai installer mon premier site en commençant par cloner le dépôt Streams, mais je n'ai pas d'attentes particulières. Je verrai bien le moment venu en quoi cela sera différent de Zap. J'ai tendance à penser que, pour commencer, cela ne changera pas grand-chose, et que le projet deviendra tout simplement ce que les utilisateurs en feront. On verra bien.</p>
<h4>Sur le devenir de Zap et ses dérivés</h4>
<p>Le tableau qui ouvre la publication est clair: passé 2022, il n'y aura plus de développement ni de support pour Zap et sa famille (Mistpark, Osada, Redmatrix et Roadhouse). Concrètement, il sera possible, pour ne pas dire nécessaire, de faire évoluer tout site s'appuyant sur Zap ou un de ses dérivés pour le "faire tourner" avec avec le logiciel proposé sur le dépôt Streams, à l'aide d'un simple script. Sauf à vouloir continuer à utiliser un logiciel obsolète et donc plus forcément sûr.</p>
<p>Hubzilla étant un cousin suffisamment proche de Zap, il sera également possible d'importer un canal hébergé sur un site Hubzilla vers un site créé à l'aide du dépôt Streams. J'utilise le terme "importer" plutôt que "cloner", parce qu'on parle bien d'une importation unique sans synchronisation par la suite. En gros, la procédure consistera à transférer, pour ceux qui le souhaiteraient, leur canal d'un site Hubzilla vers un site créée en utilisant le dépôt Streams (qui utilisera donc aussi des canaux). Ce qui restera une simple possibilité et pas du tout une obligation, Hubzilla poursuivant son développement de son côté.</p>
<h4>Ce que j'ai compris de Streams</h4>
<p>L'un des principes les plus originaux du projet Streams est celui de son "invisibilisation" au profit de l'identité propre de votre site. Concrètement, si vous créez un site en utilisant le dépôt Streams, vous pouvez une fois l'installation terminée proposer à vos proches de s'inscrire sur votre site, point barre. Pas sur une instance Streams ou un serveur Streams, non, simplement sur votre site, depuis lequel tout le fediverse compatible avec les protocoles ActivityPub et/ou Nomad sera joignable.</p>
<p>Dit comme ça, ça n'a l'air de rien, mais c'est en réalité une façon d'aborder les choses très différente, qui ne limite pas le fediverse à une réunion de plateformes de réseaux sociaux capables d'interagir les uns avec les autres. Le dépôt Streams offre la possibilité d'intégrer le fediverse sans devoir arborer une bannière ou une marque particulière, en ne contribuant pas à augmenter la part de marché de tel ou tel projet. Finalement, c'est un peu le dépassement du concept de réseaux sociaux pour arriver à un nouvelle façon d'interagir sur le web dans sa globalité.</p>
<p>J'ai peut-être un peu de mal à trouver les mots. En tout cas, je trouve la proposition très chouette.</p>
<h4>Sur les incompatibilités annoncées</h4>
<p>Il est fait mention du fait que Pleroma ne pourra pas communiquer avec un site créé grâce au projet Streams, ce qui peut sembler étonnant dans la mesure où ActivityPub est supposé être géré des deux côtés. Honnêtement, je ne sais pas à quoi ça tient, je ne peux que supposer que c'est dû à des façons différentes d'envisager l'utilisation du protocole. J'ignore à quel point cette problématique peut relever ou non de l'insurmontable.</p>
<p>Pour ce qui est de Diaspora*, c'est plus clair, puisque pour le moment il n'est pas question que ce projet implémente le protocole ActivityPub, qui est présentement le plus utilisé au sein du fediverse. On imagine donc que le protocole Nomad est encore moins à l'ordre du jour pour Diaspora*, même s'il est le seul à permettre une véritable identité nomade (en gros, le fait de disposer d'un compte n'étant pas obligatoirement lié à un site donné, et même de pouvoir déménager celui-ci d'un site à l'autre en toute transparence pour ses contacts).</p>
<h4>Logiciel libre ou propriétaire</h4>
<p>La question de l'absence de licence pour le logiciel disponible sur le dépôt Streams pourrait paraître problématique à certains. Il me semble qu'elle ne l'est pas, et qu'il n'y a pas vraiment besoin de le justifier. Le commentaire de mike sur ce point me semble suffisant, sans devoir creuser plus loin.</p>
<h4>Mes interrogations quant à la suite</h4>
<p>C'est assez court, puisqu'il n'y en a pas. J'avoue attendre avec une certaine impatience le moment où je pourrai installer mon premier site en commençant par cloner le dépôt Streams, mais je n'ai pas d'attentes particulières. Je verrai bien le moment venu en quoi cela sera différent de Zap. J'ai tendance à penser que, pour commencer, cela ne changera pas grand-chose, et que le projet deviendra tout simplement ce que les utilisateurs en feront. On verra bien.</p>
Feuille de route du projet
Chers utilisateurs francophones de Zap et sa famille, de Hubzilla ou de tout logiciel permettant d'accéder au réseau fédéré qu'on désigne sous le mot-valise de "fediverse", je vous propose ci-dessous la traduction d'une publication récente de @mike, dont vous pourrez trouver la V.O. non sous-titrée en suivant ce lien.
Feuille de route du projet
Cela faisait un moment que je n'avais pas publié de feuille de route. Voici où nous en sommes...
<table class="table"><tbody><tr><td>Nom :</td><td>Support jusqu'à :</td></tr><tr><td>Zap</td><td>2022-12-31</td></tr><tr><td>Mistpark</td><td>2022-12-31</td></tr><tr><td>Osada</td><td>2022-12-31</td></tr><tr><td>Redmatrix</td><td>2022-12-31</td></tr><tr><td>Roadhouse</td><td>2022-12-31</td></tr></tbody></table>
Un premier aperçu de Streams est en passe de pouvoir être présenté publiquement et une date de sortie officielle est actuellement envisagée pour le 01/07/2022. Les canaux de n'importe quelle autre plateforme compatible avec Zot6, y compris Hubzilla, peuvent être clonés vers Streams, la migration depuis Hubzilla n'étant cependant effectuée qu'une fois sans synchronisation ultérieure. Un script sera fourni pour mettre à jour intégralement votre site Zap (etc.) vers Streams.
Une fois l'installation effectuée, le nom "Streams" disparaîtra et le logiciel prendra l'identité de votre site ou instance pour devenir une entité unique représentant votre site (et ses utilisateurs) dans le fediverse. Votre logiciel utilisera le multicode par défaut (HTML, markdown et bbcode combinés), communiquera en utilisant les protocoles Nomad et ActivityPub et se fédérera avec toutes les plateformes fediverse/ActivityPub connues, à l'exception de Pleroma qui ne souhaite apparemment pas communiquer avec nous, et de Diaspora, qui ne souhaite communiquer avec personne d'autre que lui-même. Un driver Zot6 est également fourni pour communiquer avec les logiciels qui utilisent ce protocole. Vous disposerez d'une authentification unique sur Internet, de groupes, d'aspects (NdT : un classement de contacts par catégories), de médias privés, d'un système de protection de la vie privée/permissions/modération/prévention du spam et des abus, d'un "cloud" personnel, d'un chiffrage fort, d'une identité nomade et de toutes les autres fonctionnalités pour lesquelles cette famille de logiciels est connue depuis des années, avec une attention particulière accordée à la réduction ou à l'élimination de toute complexité inutile. Des personnalisations supplémentaires et des fonctionnalités spéciales sont fournies par des addons et des applications téléchargeables.
Ce logiciel nécessite Composer et PHP 8. Vous pouvez continuer à utiliser une plate-forme dérivée de Zap sur PHP 7.4 jusqu'à ce que PHP 7.4 atteigne sa fin de vie en novembre 2022. Après décembre, il n'y aura plus de correctifs de sécurité ni de mises à jour pour les projets basés sur Zap. Il y aura un seul projet et il n'aura pas de nom (le projet est virtuel ou éphémère), vous pouvez le trouver dans le dépôt Streams sur codeberg (https://codeberg.org/streams/streams). Ce projet ne sera ni open source, ni un logiciel libre, ni propriétaire, il n'a pas de licence. Il existe tout simplement.
Voilà. C'est dense. Très dense, même. Mais ça décrit un concept vraiment très intéressant. Dès que je le pourrai, j'ajouterai une petite explication de texte un peu plus précise concernant certains éléments du texte, soit dans les commentaires, soit dans une nouvelle publication.
Feuille de route du projet
Cela faisait un moment que je n'avais pas publié de feuille de route. Voici où nous en sommes...
<table class="table"><tbody><tr><td>Nom :</td><td>Support jusqu'à :</td></tr><tr><td>Zap</td><td>2022-12-31</td></tr><tr><td>Mistpark</td><td>2022-12-31</td></tr><tr><td>Osada</td><td>2022-12-31</td></tr><tr><td>Redmatrix</td><td>2022-12-31</td></tr><tr><td>Roadhouse</td><td>2022-12-31</td></tr></tbody></table>
Un premier aperçu de Streams est en passe de pouvoir être présenté publiquement et une date de sortie officielle est actuellement envisagée pour le 01/07/2022. Les canaux de n'importe quelle autre plateforme compatible avec Zot6, y compris Hubzilla, peuvent être clonés vers Streams, la migration depuis Hubzilla n'étant cependant effectuée qu'une fois sans synchronisation ultérieure. Un script sera fourni pour mettre à jour intégralement votre site Zap (etc.) vers Streams.
Une fois l'installation effectuée, le nom "Streams" disparaîtra et le logiciel prendra l'identité de votre site ou instance pour devenir une entité unique représentant votre site (et ses utilisateurs) dans le fediverse. Votre logiciel utilisera le multicode par défaut (HTML, markdown et bbcode combinés), communiquera en utilisant les protocoles Nomad et ActivityPub et se fédérera avec toutes les plateformes fediverse/ActivityPub connues, à l'exception de Pleroma qui ne souhaite apparemment pas communiquer avec nous, et de Diaspora, qui ne souhaite communiquer avec personne d'autre que lui-même. Un driver Zot6 est également fourni pour communiquer avec les logiciels qui utilisent ce protocole. Vous disposerez d'une authentification unique sur Internet, de groupes, d'aspects (NdT : un classement de contacts par catégories), de médias privés, d'un système de protection de la vie privée/permissions/modération/prévention du spam et des abus, d'un "cloud" personnel, d'un chiffrage fort, d'une identité nomade et de toutes les autres fonctionnalités pour lesquelles cette famille de logiciels est connue depuis des années, avec une attention particulière accordée à la réduction ou à l'élimination de toute complexité inutile. Des personnalisations supplémentaires et des fonctionnalités spéciales sont fournies par des addons et des applications téléchargeables.
Ce logiciel nécessite Composer et PHP 8. Vous pouvez continuer à utiliser une plate-forme dérivée de Zap sur PHP 7.4 jusqu'à ce que PHP 7.4 atteigne sa fin de vie en novembre 2022. Après décembre, il n'y aura plus de correctifs de sécurité ni de mises à jour pour les projets basés sur Zap. Il y aura un seul projet et il n'aura pas de nom (le projet est virtuel ou éphémère), vous pouvez le trouver dans le dépôt Streams sur codeberg (https://codeberg.org/streams/streams). Ce projet ne sera ni open source, ni un logiciel libre, ni propriétaire, il n'a pas de licence. Il existe tout simplement.
Voilà. C'est dense. Très dense, même. Mais ça décrit un concept vraiment très intéressant. Dès que je le pourrai, j'ajouterai une petite explication de texte un peu plus précise concernant certains éléments du texte, soit dans les commentaires, soit dans une nouvelle publication.
Yay, displaying the nombre of likes/dislikes now works! Thanks to @Zap for the hint.
(And yes, being entirely based on Redbasic, the theme is responsive)
(And yes, being entirely based on Redbasic, the theme is responsive)
Hi people! I'm glad to show you a first screenshot of the theme I've been working on for a few weeks. Here's what it looks like:
Some parts may remind you Pixelfed or even Instagram. At least, I hope so.
For the moment it uses the Gallery addon available in Zap to get the tiled gallery. You need it to get this view, otherwise you'll get full sized pictures (I mean as wide as the main column). I'm not even sure that the tiling would actually work with sites that don't use the exact same theme. I'll do some more tests and keep updated those interested.
The main bugs/improvements I have spotted for the moment are the followwing:
- When writing the post, the preview doesn't work as intented as it looks quite different from the published post, I need to investigate this.
- There is a blank space below the tiled gallery, I haven't figured out how to make it disappear for the moment.
- The spaces between the icons are not regular while in the CSS file the margins are supposed to be exactly the same, I don't know if I'm missing something or if it needs hyprasubtle settings different for each icon.
- The Gallery addon could probably be replaced but, it seems awfully complicated to me. Using JS and/or pure CSS within the theme would not allow followers from other servers to obtain a tiled view, so it would have to be done differently, and I can't see how it could be done in a simple way.
Any thoughts?
Some parts may remind you Pixelfed or even Instagram. At least, I hope so.
For the moment it uses the Gallery addon available in Zap to get the tiled gallery. You need it to get this view, otherwise you'll get full sized pictures (I mean as wide as the main column). I'm not even sure that the tiling would actually work with sites that don't use the exact same theme. I'll do some more tests and keep updated those interested.
The main bugs/improvements I have spotted for the moment are the followwing:
- When writing the post, the preview doesn't work as intented as it looks quite different from the published post, I need to investigate this.
- There is a blank space below the tiled gallery, I haven't figured out how to make it disappear for the moment.
- The spaces between the icons are not regular while in the CSS file the margins are supposed to be exactly the same, I don't know if I'm missing something or if it needs hyprasubtle settings different for each icon.
- The Gallery addon could probably be replaced but, it seems awfully complicated to me. Using JS and/or pure CSS within the theme would not allow followers from other servers to obtain a tiled view, so it would have to be done differently, and I can't see how it could be done in a simple way.
Any thoughts?
Oh, talking about improvements, I forgot: for the moment, on the post's header, you can only see if the post was liked/disliked, but to know by how many people, you need to move the cursor over the icon. Not very convenient. I'd like to show just the number next to the icon, but haven't found how to do that. This TPL syntax is like a foreign language to me. If anyone has an idea...
A few days ago I decided to start working on a new theme for Zap. At first I thought I'd just write schemes for Redbasic (the default theme), but as the CSS files grew bigger and bigger, it appeared that creating a new theme was more relevant. I ended up with something rather similar to Redbasic, perhaps just a little less austere:
After creating four schemes with a light background, I thought it could be a good idea to have something a little darker. I can't remember why, but I decided to work on schemes based on single color, starting with green:
This reminded me of the old monitors that were in use decades ago when I was still a kid. I thought that adding some kind of blurry effect would really be nice to improve this "retro" look, but had no idea on how to do that. If only it could be just as easy as editing a CSS file to get the colors your want...
Turns out it is:
I could have stopped there. I mean how further could you go? Rendering the images in black & green monochrome was the only missing thing to make it a really vintage theme. But doing this using the CSS filters seemed rather unlikely.
Or did it?
It took me a few hours, but I must say I'm quite satisfied with the result. Which doesn't mean some important changes can't still be made. For instance I don't know if using a different font would be a useful addition. Switching to an even more old school one seemed like a good idea, but maybe it is too much:
Anyhow, I now have three variations of this theme: Green, Orange and Black & White. All of theme have some schemes that allow you to be more or less "radical" in terms of aspect.
As I'm proud enough to think that maybe a person or two could be interested in using those themes, I made them available throught a git repo. Though I consider them to be usable on a daily basis, some improvements are certainly possible: for example the CSS files are awfully messy, the few PHP lines I wrote probably need to be reviewed and/or rewritten by people who know what they're doing, and so on...
So, I will dare to ask: any comments on this?
P.S.: The git repo is named Zap_Themes, the themes are most probably also usable with Roadhouse, Misty and perhaps Osada and Redmatrix. With a little extra work it may be possible to use them with Hubzilla.
After creating four schemes with a light background, I thought it could be a good idea to have something a little darker. I can't remember why, but I decided to work on schemes based on single color, starting with green:
This reminded me of the old monitors that were in use decades ago when I was still a kid. I thought that adding some kind of blurry effect would really be nice to improve this "retro" look, but had no idea on how to do that. If only it could be just as easy as editing a CSS file to get the colors your want...
Turns out it is:
I could have stopped there. I mean how further could you go? Rendering the images in black & green monochrome was the only missing thing to make it a really vintage theme. But doing this using the CSS filters seemed rather unlikely.
Or did it?
It took me a few hours, but I must say I'm quite satisfied with the result. Which doesn't mean some important changes can't still be made. For instance I don't know if using a different font would be a useful addition. Switching to an even more old school one seemed like a good idea, but maybe it is too much:
Anyhow, I now have three variations of this theme: Green, Orange and Black & White. All of theme have some schemes that allow you to be more or less "radical" in terms of aspect.
As I'm proud enough to think that maybe a person or two could be interested in using those themes, I made them available throught a git repo. Though I consider them to be usable on a daily basis, some improvements are certainly possible: for example the CSS files are awfully messy, the few PHP lines I wrote probably need to be reviewed and/or rewritten by people who know what they're doing, and so on...
So, I will dare to ask: any comments on this?
P.S.: The git repo is named Zap_Themes, the themes are most probably also usable with Roadhouse, Misty and perhaps Osada and Redmatrix. With a little extra work it may be possible to use them with Hubzilla.