My general view for now on the issue of Threads integration with #Mastodon is that it may make sense in terms of making it easier for Threads users to follow Mastodon users (given the topology and complications of the Mastodon model), but it makes little sense for Mastodon users to follow Threads users via such an integration, rather than simply following them on Threads and avoiding "cross-contamination" of the very different operational models and standards involved. My sense is that Mastodon will ultimately be on the losing end of this arrangement. Why? One word: "Zuck."
@dalias@_L1vY_@lauren Correct, I do not foresee a way for them to really destroy NetNews and other highly-asynchronous communication networks.
"The (Use)net interprets censorship as damage and routes around it" line, essentially.
They would most likely manage to kill ActivityPub, because most of its implementations have little to no tolerance for disruption, have garbage support for transport-diverse networking and do not properly support #AsynchronousCommunication... but a lot of other options, some newer and some a lot older, do have very good support for those things.
I have complicated feelings regarding #Usenet and #NNTP due to some server-centric aspects.
Granted due to message #gossip the death of any given instance isn't catastrophic and moving is largely unnoticeable, but it still puts some hurdles on usability in adverse conditions.
It still fulfills most of the #AsynchronousCommunication characteristics handily, but that's still a nagging thought, since /most/ instances demand fairly high-uptime to peer and don't allow such instability from peers.
I really can't help but look at this whole blocklist drama with some amusement tinged with exasperation.
Anyone who has done remotely any reading on #P2P systems and #federated systems just has that flaw jump to their eyes when the state of #ActivityPub implementations is seen, and in general how no importance is given to #AsynchronousCommunication communication in the spec and nearly as little to P2P use.
Basically, what did you expect? Of course it'll devolve into petty fiefdoms.
It's amazing and horrifying how many devs I speak to who don't realize how much #privilege their #infrastructure and #hardware reliability assumptions involve, or that their disregard of some things as inconsequential #DataLoss isn't a decision for them to make, it is for the user to determine the actual importance of anything lost from a malfunction.
They don't like that because it puts a much higher burden of care than they want to bother with.
@Elizafox#GNUnet (for all its many faults) does support the entire network stack down the lowest layers, all you need at that point is a signalling substrate (#DIY#FSO like #RONJA is cool).
Zulip is absolutely underrated as a chat platform for teams. Its automatic threading makes it so much easier to catch up on previous conversations than with Slack, Teams or Discord. In my opinion, Zulip is ideal for distributed teams who prefer to work and communicate asynchronously -- like my team, for example.
I tried using Email but the onboarding was very confusing. I have to choose a server? And I'm at the whims of server admins having petty disputes for if my posts are delivered to my friends?
Most systems implementing/supporting it are de-facto P2P, but that isn't a hard requirement (it is technically an orthogonal property, it has similar but not exactly identical implications to "delay-tolerant").
"Irish households have reduced their demand for electricity by 9% over the past couple of years. In contrast, electricity demand from data centres has soared by 31%. A truly astonishing 18% of Ireland’s electricity now goes to feed over 80 already active data centres. 14 more are already under construction and an additional 40 have received planning permission. A further 12 are awaiting such permission."
@pvonhellermannn@gerrymcgovern Much of the issue with the absurd reliability requirements datacenters have to deal with are due to the current and bizarre trend of disregarding #AsynchronousCommunication as the primary mode of interaction between programs, people and businesses.
Such communication is much more tolerant to disruption and delays, and can be explicitly strengthened in those aspects.
A theme I saw yesterday & unwittingly contributed to: Old protocols are perfectly satisfactory. The issue is that as technology is brought to the masses it gets filtered through the lens of capitalism!
Personally I quite like:
HTTP
HTML (caveats)
CSS (caveats)
RSS
XMPP
eMail
I tend to be quite cynical about what gets sold as innovations, but I won't say there ever was a golden era of computing we've fallen from grace from.