Quand je vois certains dire "Mais il ne faut pas bloquer Threads, pensez à ces pauvres utilisateurs sur Facebook/Insta/Threads !"
C'est un peu comme dire "Mais il faut faire du commerce avec l'Iran ! Regardez ces pauvres Iraniens !"
Alors fondamentalement oui, ces pauvres iraniens.
Mais ça n'excuse pas de faire du commerce avec ceux qui les enferment.
On peut avoir pitié pour un peuple sans pour autant accepter leur oppresseurs.
@captain_niglo@sebsauvage ils ne peuvent pas plus collecter tes données que n’importe quelle autre instance mastodon (et j’ai l’impression que beaucoup de gens oublient cette possibilité), les pubs ne sortirons certainement pas de threads, pour moi, tous les problèmes cités (sauf la modération, qui peut être une cause de blocage) sont ceux de leurs utilisateurs, pas les nôtres, en se fédérant, on donne à ces utilisateurs la possibilité de regagner en liberté, sans se compromettre nous même.
@sebsauvage@Flop_Ysh mais il faut absolument supposer aujourd’hui que le fédiverse est aspiré par tout un tas d’entreprises et de services de renseignements, ce n’est pas un espace privé, n’importe qui qui crée une instance récolte par défaut énormément de contenus. Il faut sans doute utiliser l’api pour reconstituer les graphs, mais je suis quasi certain que des gens le font déjà.
L’arrivé de Méta devrait clairement être une opportunité de rappeler ça aux gens.
@folkerschamel@davidism as your project grows bigger, it really helps with avoiding inconsistencies that could almost work for long enough that you don't detect bugs until it becomes really hard to fix them.
Type dynamism is really nice when you get started, you can experiment fast, but once the project stops cleanly fitting in your head, you need type declaration to help you.
You know what, chances are that X is someone who meticulously prepares their talk and busts their ass rehearsing it over and over and over. Recognise and appreciate their effort, and its results.
Apparently even though the online poster session for the ALAN light pollution conference isn't for 2 weeks, I have to get my poster uploaded by tomorrow.
Which means I get to spend ALL DAY frantically putting together a poster on satellite pollution and stewing about how much I HATE Starlink. I am going to need to smash something very badly when I'm done with this poster...
@sundogplanets Don't worry, i'm sure AI will fix that problem. Or maybe you'll just have to move your telescope to Mars, i hear it's going to be pretty cheap to go pretty soon.
@osc well, they see it as a threat to the fediverse, so it's not really what they mean, i think. I agree the arguments i have seen to justify that fear are not really compelling, but they are not entirely baseless either.
@osc i do agree with that, i see a lot of very thinly justified panic, and calls to arms that are potentially harmful or at best ineffective, because they are not based on clearly identified problems, but rather on the general sense of a vital threat.
@osc well, ideological or not, this is tribe behavior to me, meta is identified as the enemy, so the thing we are running from, so when they get close, this is war. This requires a very simplified vision of what Meta is, we know all there is to know about it, it's bad, and we have the recipes, yes, meta is a bad company, so that's all there is to know about it.
But even accepting it as the enemy, even going to war with it, requires understanding it and preparing the playbook.
@HistoPol@osc I know Meta did terrible, terrible things, even arguably helping at least one genocide. Yes, it’s a harmful company.
That doesn’t say anything about the arm it can do to the Fediverse, with intents or not (that doesn’t matter), and how blocking the thread app helps.
It’s a very knee-jerk reaction, for understandable reasons, but things are not so simple indeed, and we need to understand the actual threats to the fediverse, if we want to have a chance at preventing them.
@HistoPol@osc if anything, the arrival of Meta/Threads should be a great opportunity to explain to people that no the fediverse is not a private space, it might be more or less "safe", because moderation prevents most attack in this place, but it doesn’t keep the information in, any company, gov entity or even individual can create for modest costs, an instance that will archive everything happening in the fediverse, and be able to search that DB.
@HistoPol@osc this doesn’t even begin to address how using mastodon has any way changed regarding your PII since Threads joined, nor how blocking them will change anything.
Because this fails to address how all the data you post on mastodon is already public, and what more is gaining (from you, not from its users) by joining the fedi with an app.
If mastodon users are not-infosec-savy, they are already into trouble, they were the instant they joined mastodon.
@HistoPol@osc yeah, the question is more fuzzy to me about how easy it is to currently fetch/maintain a global social graph of the fediverse, i think you have to either talk to each server’s API, being careful about hitting rate limits, or scraping the instance webpages, though i’m sure a motivated actor could certainly build a relatively up to date version with smart refresh rates and distributed workers.
It is certainly something to keep in mind at least for activists.
But there is no reason to think blocking them is actually going to achieve anything to "protect" us from them, not until there are clearer understanding of what bad behaviors to expect from them, and how federating with them would enable them.
For now, all the examples of abuse from meta i seen suggested, were based on meta threatening to de-federate us, so de-federating them in the first place is just getting there right away.
Threads website is sort of live? Clean, but somewhat bare. One positive thing is the domain name right after the username. Looks like the Fediverse connection isn't just talk.
Je me demande si il est possible de voir une instance qui concentre une grosse partie du trafic et après avoir aspiré du monde, de mette en place une forme d'exclusion progressive du fediverse des utilisateurs.
(il y a pleins de manières d'y arriver : app propriétaire avec des fonctionnalités, mise en place d'une politique antispam de plus en plus restrictive, interdire les redirections si un utilisateur veut migrer sur une autre instance, etc)
@sossalemaire@MonsieurBidouille mais là c'est comme si tu bloquait gmail d'entré, donc pour parler avec des gens chez gmail, il faudrait que tu crée un compte gmail, je ne vois pas ce que tu gagne!
Pour les extensions propriétaires, je pense que ça peut dépendre de la coopération avec le fédiverse, si on les rejette massivement, ben ils n'auront pas grande motivation a respecter le protocole, alors qui si c'est un réel atout, une coopération est imaginable, pas certaines, mais imaginable.
@sossalemaire@MonsieurBidouille oui, par contre, pour des raisons d'économies d'échelles, de professionnalisation, et même de protocol (ventiler les mêmes messages à des milliers de serveurs, c'est brutal) il y a très certainement une pression à la concentration, mais d'un autre coté, il y a un ethos très fort dans la communauté contre ça, encouragent les gens a quitter les instances les plus grosses pour se diriger vers des plus petites. On verra où l'équilibre se trouvera…
@sossalemaire@brvier@MonsieurBidouille. Si on veut lutter contre cette concentration, il faut penser a quoi faire pour rendre les petites instances plus viables.
solutions juridiques clé en main? (eula standard par pays/zone, par exemple)
meilleurs outils de modération (détection auto d'instances a bannir via des analyse antispam, bayes classique ou llm?)
optimisation pour qu'avoir une instance même bien connecté pour quelques centaines d'utilisateurs soit viable économiquement.
What is your opinion on PRIMARY KEYs for database tables that are append-only (i.e. for logging) and have no natural primary key and are not referenced?
@louis funny how nobody provided a rational for the winning option. Feels very much like a mantra "all tables should have a PK with autoincrement", that cannot be questioned.
@louis well, what would you select on? If it's not your PK, then not having it makes no difference, and you can still have indices (on timestamp for example, or anything you'll commonly search/order by, but careful with write heavy tables) to filter on (and update/delete), or for a log, full text search might be an interesting thing to enable. PK makes sense for relational data, here you don't seem to treat it as such, and i don't see what you lose for not having it.
@louis in fact that’s why i think the winning option makes the least sense of all, as you are never going to want log row 128141578, but you might want all the log rows between 2023-06-25T00:25:20 and 2023-06-25T00:30:00 or something, and having an index on that, (probably cheap to maintain, especially if you never delete ?).
While a PK would mean that every insert waits for a lock on the table to be able to get the next value of the series, which can be a bottleneck.
@louis no worries, i guess i wasn’t clear 😆 i think PK-less table can make sense to a bit more than tables where you never update or delete, as long as your criteria for selecting/updating/deleting do not require a PK, (so impossible to know if you match one or multiple rows, but that’s not a problem for the use case), then it’s fine.
I see PK as providing unicity and indexing, if you don’t need the unicity, bust an index on the fields you need to search for efficiently is cheaper.
Don’t kid yourself. “Artificial intelligence“ is just Big Tech’s way of saying “hey, it’s not our fault. It’s the machine’s!“ In point of fact, every malign use of “AI“ is really just some human-composed algorithm doing something that maximizes profit or control at the expense of people. We must not let these companies off the hook. They’re in charge. Not the machine. Pay attention to the man behind the curtain.
