Fabio ManganielloJul 2, 2023

#Twitter going rogue has much deeper implications than the Musk saga with all of its daily bullshit.

Let's not forget that, before the buffoon oligarch took over, Twitter used to be a place where government and scientific entities used to post (and they still post) information that may be crucial for the population. Twitter used to be the primary place for announcements about earthquakes, eruptions, pandemics, tsunamis, weather alerts, shootings etc.

How does that cope with a reality where external APIs are basically shut down, their unofficial frontend API is no longer working either, viewing is only possible through registered accounts, and even those accounts have a cap on the number of posts that they can consume?

How can a service with such heavy constraints around monetization still be considered a viable way of delivering messages that matter for the whole population?

As an example, one of the few Twitter accounts that I still follow (mirrored on the Fedi) is the one of INGV - the Italian Institute for geology and vulcanology.

I've got my good reasons, as I was born in a city (Naples) that may be soon blown up by the eruption of the largest European supervolcano (Campi Flegrei).

As my parents and relatives are now sitting just 1-2 km above several square km of magma, I obviously follow any updates that the INGV Twitter account posts about earthquakes in the area, with an automated system of alerts in place.

How does that cope with a service that lets users see only a few hundreds of tweets per day, and where you need bullshit like being registered, verified etc. to reliably access the content?

Can you imagine a tsunami alert system in Japan that alerts only those who paid for a platinum alert subscription, and only if they haven't already consumed their budget of 5 yearly alerts?

Twitter must be abandoned RIGHT NOW by any institutional accounts that post stuff that can make the difference between life and death of people.

Show threadLisPiJul 2, 2023
@blacklight We should all just go back to #RSS / #Atom + #email (in other words, pull + [optionally] push), as that stuff should always have been.
Show threadSeirdyJul 2, 2023
@lispi314 @blacklight Isn’t that basically how the OStatus ecosystem worked?
Show threadLisPiJul 2, 2023

@Seirdy @blacklight I couldn't say, I hadn't heard of it prior to now (or at least hadn't looked in it it at all).

#OStatus seems (https://en.wikipedia.org/wiki/OStatus) to indeed rely on those technologies I mentioned and looks complementary with them.

OStatus - Wikipedia

Show threadFabio ManganielloJul 2, 2023

@lispi314 @Seirdy I think that the first requirement here is "an emergency alerting system should be something dumb-proof that ideally should come pre-installed on any device with a SIM card without any further configuration".

I mentioned NL-Alert (the alerting system we have in the Netherlands) because it's simple, it works on any phone that has the "emergency broadcast" enabled in the settings (which AFAIK is kind of the default), and it only relies on the broadcast messages implemented by all the mobile carriers to deliver content - almost nothing is running on the software side, except the OS handler that receives those messages and shows an alert. As a result, 94% of the Dutch have it enabled.

If we want more tweaking, of course we can grab OStatus or any messaging broadcast standard - even ActivityPub itself. Even something as simple as a lightweight RSS/Atom feed with a tight polling would do it - and if you want to go fancier you can also configure something based on UnifiedPush like ntfy to deliver real-time mobile notifications without relying on Firebase etc.

But that would increase adoption barriers for anyone who isn't fluent in tech - and you really want an alerting system to be configurable by literally everyone with a single tap in their OS settings. If a volcano blows up would I want only those who know how to configure notifications on an RSS feed to be saved? Well, better not ask this question to my cynical twin I guess...

Also, the least amount of software is involved, the best. If you were to release a real-time government alerting system for all the citizens as an app, that app will immediately become the favorite target for hackers - besides risking being mistrusted by those who would mistrust any 3rd-party app on their phones released/sponsored by the government. It definitely has to be implemented on the OS side, like the existing emergency broadcast settings or the COVID-19 exposure notifications engine.

Show threadLisPiJul 2, 2023

@blacklight @Seirdy I can agree to a point with the alerting system, but not in exclusivity (both is good) as that is entirely unusable for those without functional mobile phones or with phones that require proprietary software to make that functional whom have removed that software.

As for software trustworthiness, making it verifiable #FreeSoftware would go a long way.

The Covid stuff failed to do that here because they insisted on tying it into Google's infrastructure for no real reason.

Show threadSeirdyJul 2, 2023
@lispi314 @blacklight These options are not mutually exclusive
Show threadLisPi
@Seirdy @blacklight Indeed, a plurality of options along with sane defaults is the way to go, I'd think.
Jul 2, 2023 at 9:12pmWeb
Show threadFabio ManganielloJul 2, 2023

@lispi314 @Seirdy The COVID exposure notification system is actually a good case study.

Europe proposed DP-3T, that still I consider to this date a good solution. It was an open and transparent protocol, there are even open-source servers for it (https://github.com/RadarCOVID/radar-covid-backend-dp3t-server), and, unlike its main competitor (PEPP-PT), it didn't even require uploading contact logs to a centralized server.

However, time was tight, a pandemic was raging, and Apple+Google at some point went like "look, do we want to spend a couple of months/years to reach consensus on an open protocol, and make sure it's implemented properly by all the vendors, or just the two of us go ahead, pick some ideas from DP-3T, implement them on-the-fly, et voila', you have >95% of the smartphone users in the world immediately covered?"

I still consider it a very painful trade-off. Of course I would have liked to see an open protocol with 100% FOSS software to be in charge of it, but the pragmatic side of me knows that, in that situation, it would have taken away more precious time.

The thing is that ideally we shouldn't have reached that stage. You shouldn't think of how to alert everyone during an emergency only when emergency strikes. But I guess that it's part of human nature to dismiss any danger that we perceive as unlikely and always be unprepared when it strikes...

GitHub - RadarCOVID/radar-covid-backend-dp3t-server: DP^3T Radar COVID fork

DP^3T Radar COVID fork. Contribute to RadarCOVID/radar-covid-backend-dp3t-server development by creating an account on GitHub.

GitHub
Show threadLisPiJul 2, 2023

@blacklight @Seirdy I don't consider facilitating corporate spying & tie-in to be less harmful. Particularly since a lot of people just didn't use the app anyway here without any concern for the ethics of it, so it's not like purposely ignoring the corposcum (instead of incidentally) would've been all that much of a problem.

As for the lack of preparedness and waiting to be against the wall, that habit annoys me profoundly.

It's not like this is our first time either, we know better.

Show threadLisPiJul 2, 2023

@blacklight @Seirdy Our governments all saw what SARS did before, and the polio, influenza and tuberculosis pandemics before that.

There is absolutely no excuse for not having mandated better HVAC filtering & sanitation before.

Show threadFabio ManganielloJul 2, 2023

@lispi314 @Seirdy > those with phones that require proprietary software to make that functional whom have removed that software.

In a world where DP-3T became the widely adopted solution, you wouldn't have needed Google Play Services/Apple crapware to run the service. Being an open and distributed protocol, anybody could have implemented both the server and the client. It's a problem that can be solved by construction :)

> those without functional mobile phones

Well I guess we have to find a cutoff at some point.

For a system based on Bluetooth beacons like the exposure tracking service, a smartphone is obviously needed (or a battery-powered RaspberryPi in your bag if you really want to go the geek way).

If you want to get notifications about tsunamis, earthquakes or tornadoes around you, anything based on GSM and the likes should work - even a $25 phone that only makes calls.

And you could also leverage alerts over specific AM/FM frequencies if you also want to make sure that other radio devices can pick them.

If you don't own any form of phones nor radio devices, I guess that the last resort would be wailing loudspeakers all around the city if something is going very wrong - and in the Netherlands we actually have those too.

Show threadLisPiJul 2, 2023

@blacklight @Seirdy > If you want to get notifications about tsunamis, earthquakes or tornadoes around you, anything based on GSM and the likes would work - even a $25 phone that only makes calls.

Why should I have to get a GSM dongle for my desktop when it has a perfectly fine ethernet connection and I have a dbus-connected notification message daemon active?

One doesn't need to be out & about to know it's a good idea to pack one's shit & leave as fast as possible or shelter in place.

Show threadLisPiJul 2, 2023

@blacklight @Seirdy It'd be a lot more complicated and expensive to acquire SDR or generic packet radio equipment to attach to it than just poll an RSS endpoint periodically.

As for conventional AM/FM, the air tends to be filled with junk instead of just silent between alerts.

Show threadFabio ManganielloJul 2, 2023

@lispi314 @Seirdy > It'd be a lot more complicated and expensive to acquire SDR or generic packet radio equipment to attach to it than just poll an RSS endpoint periodically.

You're assuming that your only receiving device will be a desktop/laptop connected to a network, which is not the case for most of the folks.

Things aren't mutually exclusive. I would assume that any serious broadcast alert system should have an RSS feed (that should be literally the step zero for any public notification-based communication that others can build automation upon), and ideally support an open protocol for notification delivery like UnifiedPush, so thousands/millions won't have to poll the same URL all the time.

But, again, designing these things isn't like designing a DIY project. The first thought should be about the use-case that >99% of the population is most likely to use.