@aurynn I still remember being amazed by a similar video in 1994, when I was a student in tectonics, but back then you could only back to 200 millions years!!
"A fundamental flaw occurred in our design; we over-valued the role that instances should play altogether. While there is nothing wrong with blocking an instance or two, the network effect of having this be the foundation is re-centralization."
This paper by @cwebber is so good. It analyzes foundational problems inherent in the current state of federated social networks and then looks toward developing a solution.
CW: Sexual harassment in STEM
Re-posting this 🐤 thread from 2018 which, sadly, is still relevant:
THE NINE TYPES OF REPLY GUYS 🧵
#1: THE LIFE COACH
Dis tonton, c’est quoi le problème avec le jeu antifa ?
The #kubernetes registry is moving!
Images for control plane components, as well as for the "pause" container (used by the "pod sandbox" for every pod) are moving from k8s.gcr.io to registry.k8s.io.
This will give you faster image pull speeds (yay!) *but* might break some scenarios; e.g. if you have some IP address filtering in place for the registry.
For more details →
at some point maybe it would be worth doing a fediverse thread breakdown of the ideas in ocappub https://gitlab.com/spritely/ocappub/blob/master/README.org and how the work has continued over at @spritelyinst because everything I wrote in 2019 is now super, incredibly relevant
(I am anticipating a crash/collapse of the fediverse in its current form at a not too distant future; hopefully we'll have more answers ready by then, but this is a multi-year project)
Having run my own test mastodon server, I can tell you that boosting is REALLY important. That's how posts propagate between servers that are not federated together.
I may get a bit technical, and it can be hard to describe but it's something like this:
Let's say that you have 2 servers, A and B that are not connected. They have their own federated timelines that is vastly different.
let's assume they have their users @a@A and @b@B that are mutuals. If user @a@A sees something interesting on theirs federated timeline and boosts it, user @b@B will see that on their own home page. But more importantly server B will now know about and download that post, and everyone else on B server will be able to see that post on their own federated timeline!
And that's why you boost, guys! It helps posts to spread.
transgirls take over the future of the p2p internet
My dear friend @mikaylam did a fresh implementation of the blog example code from Heart of Spritely for finishing her undergrad capstone https://spritely.institute/static/papers/spritely-core.html
We did a multiple-stakeholder-interests-upheld demo with (for convenience) a very minimal web rendering also, from this section of the paper https://spritely.institute/static/papers/spritely-core.html#guest-post-review
This is fully peer to peer, using Spritely's distributed networking code. It might not look like much, but it's an awesome moment. Mikayla had to be able to understand all the core ideas of Spritely and independently implement and explain each to get to this point. Nice work.
Oh, and... just wait till you see what the text says. @mikaylam took a better screenshot of that, I'll let her follow up with it.
Beautiful illustration of where people are concentrated.
If you squint, you can see Australia and New Zealand.
Je vais faire un petit point sur une polémique qui agite le monde de la « lutte contre la désinformation » autour de « Facts and Furious ». Si vous ne savez pas de quoi il s’agit, faites qqes recherches sur Twitter et YouTube (taper Idriss Aberkane + Facts and Furious par exemple).
Il s’agit d’une polémique qui montre hélas très bien les angles morts du « tout au factchecking » que nous sommes plusieurs à pourfendre depuis des années. Cc @juliehaviland2 @stephlamy
A private instance for now :-)