Morning thoughts, open ears and I wanted to briefly skip through yet stayed for most of the episode so far:

"... And what local-first is, is a principle for designing this kind of collaboration software so that the primary copy of the data is not somewhere in the cloud, but on your own machine. You have a copy of the data locally on your own machine, which means that you can access it while offline, for example, and you can just keep using the software without an internet connection, and it'll just resync the next time you come back online again. ..."

I haven't been listening to tech and software architecture podcasts that often recently but remembering rather well reading through the "Designing Data-Intensive Applications" book back then (which was a concise and great read, like most of the O'Reilly books used to be and maybe still are), speaker got my interest started and I remained there nodding again more often than I probably should. Talking making applications independent of particular cloud vendors. Talking making cloud services useful support tools that can be changed without being tied to them altogether. Giving users the autonomy and full control over their data, specifically also non-technical users. Spreading features absolutely familiar to software developers, such as the fully self-containing autonomy of git repositories, the change tracking and revision history, to other domains (such as social networks, talking ATProto / Bluesky again). Worth following up on.

https://www.infoq.com/podcasts/increasing-users-data-agency/ 

#linkdump #podcasts #social_technology #data_architecture

Alte Dokumente aus noch älterer Software, neue Anforderungen und verführerische Zufallsfunde in dem Bereich, in dem beides aufeinanderzupassen scheint. Manchmal verkürzen sich Wege, manchmal haben kürzere Wege ihre eigenen Herausforderungen. Geschichten von Problemen, Lösungen und goldenen Hämmern.

Remote conversations for the road:

"In this episode Mike Masnick gives us a history of the early internet — starting with what was called the Eternal September, when millions of AOL users flooded the scene, creating a messy, unpredictable, exciting ecosystem of open protocols and terrible UIs."

Enjoyed listening to this. I do have a mixed opinion on that protocols-over-platform point of view but there's a ot of stuff in here to wrap head around for a bit. Specifically, that kind of looking back at the early internet, at how things transformed from a per-se decentralized, fragmented environment to a set of services that were actually fun to use and made technology accessible to a whole wider load of human beings before eventually turning into shady, despicable structures one should rather avoid. Specifically, too, that looking back at how a certain group of people nowadays tends to ignore that part of the story and opts to limit things to the negative aspects that came along later. Specifically, too, that ATProto / Bluesky approach of trying to learn from both - decentralization as a crucial aspect for being in power, in control, and usability, accessibility for less tech-savvy people being an undisputable requirement to make technology that serves a particular purpose. Worth checking out.

https://www.themaybe.org/podcast/nodestar-the-eternal-september-w-mike-masnick 

#podcasts #social_networks #social_technology #mike_masnick #the_maybe

Browsing old histories: Clearly delineated paths. Fragile passages. Dangling links, blurred broken images, missing domains, 40x error codes. A loosely knit mesh, not really up to stand the test of time. The melancholy of ephemeral traces, the technological bias towards things being incomplete and temporary. (Filed under: Difficult recommendations, poor tooling evaluations, things one would be grateful to have known in advance. And in particular missing that moon.)

Reading through this made me nod more often than I probably should:

A key reason for the continued effectiveness of DDoS attacks lies in organizational structures. Systems are often put into operation under time pressure, as temporary solutions or pilot projects. Security aspects take a back seat as long as functionality is guaranteed. Such temporary installations are rarely dismantled or revised if they remain inconspicuous in everyday use. Over the years, this results in unsupervised components that are neither monitored nor updated.

https://www.igorslab.de/en/30-years-of-ddos-why-a-structural-problem-persists/ 

As I'm running various pieces of infrastructure on my own, I also happen to then and now see which software does connect to my environments, including version fingerprints that have been considered old, unmaintained, unpatched for months if not years. And as I'm interested in this kind of stuff, I then and now tend to listen to podcasts or read through articles dealing with self-hosting of more or less complex pieces of infrastructure, most of them just all too often boiling down to the idea that it's all "trivial" and "just" takes will and a bit of dedication to do it - and even in some of these podcasts once in a while I'm negatively impressed to hear how little real experience in managing infrastructure is shining through and how much of this is more or less happy-path about initially installing a piece of software on a VPS or a shared hoster. And then I'm painfully reminded of the early 2000s and trying to keep our corporate mail server and other pieces of infrastructure safe from numerous more or less distributed DoS attacks mostly conducted by poorly maintained, unpatched, vulnerable installations of typo3, wordpress and similar pieces of software one "just" used to install at some point and left at this state for a random amount of time. This feels quite concerning, over and over again.

(Another coffee. A first meeting canceled, a first service shut down for now. Data moved elsewhere, documentation workflow, a feeling of achievement and still ashamed in light of small steps. 8am, slowly on.)

Re-occurring bad gut feeling about IndieWeb: There's a good amount of folks in this community who have a hard time accepting or understanding the learning curve they succeed making, before. The time and effort it took. And maybe the privileges of having been able to take it. 

Too, xsnow has seen an upgrade today and I thoroughly wonder what it might be about. Also, briefly remembering the days when we used to write e-mails limited to plain text with at most 68 chars per line to include every kind of technology attached to this particular network and so much has changed ever since.