> Superfest, also called CV-Glas[1] or Ceverit[2] until 1980, was a brand of drinking glasses in the GDR. Due to being made of chemically strengthened glass, they were almost unbreakable. The Superfest glasses were produced between 1980 and 1990 in what was then State-owned Sachsenglas Schwepnitz.
@mia@shrimp@arcana@sun it can't decide if I have horseface or not, "noticeably long midface" + "slightly too short philtrum" + "perfect mouth to nose ratio" + "perfect facial width to height ratio"
Had a dream last night in which I was at a place with a couple of my second cousins and one of them had made LSD cupcakes. Putin was visiting the place for some reason and got given one before starting to act rather unusually.
I also had a dream that was foundational for an absolutely amazing idea
Recent events have spurred some great discussion of fediverse safety and the ways that we can improve it. I'm thrilled to see the growing interest in this problem, but there's one specific angle that concerns me. Specifically, the push for allow-list federation.
First, some background information. Federation between instances is usually controlled by restricting which remote instances (identified by domain name) can send or receive messages from the local instance. In the majority of fedi servers, this is implemented with a "deny list" - a list of instance domains that should be blocked. When using a deny list, all unlisted domains can communicate by default.
This is in contrast with an "allow list", which specifies the domains that should not be blocked. When using an allow list, all unlisted domains are blocked and can not communicate. Deny-list federation is open except for specific routes, and allow-list federation is closed except for specific routes. There are other approaches, but these are by far the most common.
Now, moving on to my actual point. I've recently seen some discussion of using allow-list federation as means to improve user safety. This idea, while very well-intended, is unfortunately flawed and could easily cause more harm than it prevents.
This idea suggests that by limiting federation to known, approved domains, then it becomes easier to block sources of abuse, hate, and illegal content. This is actually quite effective, and some instances are already using allow lists to great effect. They experience minimal contact with dangerous instances, and those that slip through are easy to identify and block. It's a great strategy for specific communities. Unfortunately, however, this approach cannot scale.
Allow-list federation works well for a minority of instances, but only because the majority do not use it. This is due to the network effect. Just as a centralized social network can collapse if there are too few connections between users, a federated social network can collapse if there are too few connections between nodes (instances).
With open or deny-list federation, all nodes are connected to all others. This forms a very strong network - so strong that small and even single-user nodes are possible. The open federation ensures that there are always sufficient connections to keep the network useful.
The same is not true of allow-list federation. In this mode, the network nodes are only connected to a limited subset of others. As the percentage of allow-list nodes increases, the number of connections decreases exponentially. The resulting network is weak and unstable enough to collapse under pressure. A bigger problem, however, is not the network weakness but rather the loss of small instances.
In my experience, it's rare to see a federation allow-list with more than 1,000 entries. Fediverse index websites currently show around 25,000 active instances, which means that most allow-list instances are connected with only 4% of others. We can assume that the 4% is biased towards medium-to-large instances because of their increased visibility. After all, an instance cannot allow-list another node until they've encountered it through a mutual. Larger instances have more mutuals, and thus a greater chance to be discovered.
Over time, this creates an imbalance where larger instances benefit from a richer and broader network than smaller nodes, who have limited reach and reduced federation. Any new instance must somehow maintain a user base while faced with network isolation. This becomes a significant barrier to entry for the fediverse.
This barrier effect is bad enough, but there's another angle to consider. Fedi is large enough to have a constant churn of small instances starting up and shutting down. Currently, more instances are forming than closing, which leads to positive growth in the number of nodes - a good thing for network health. But if it was harder to start a new instance? That ratio would drop or even reverse, causing the network to shrink instead of grow. Reduced network size increases the network effect, which expands the inequality, which strengthens the barrier, which decreases the growth, which reduces the network size. A classic feedback loop.
This process would be devastating for fedi. The cycle would continue until there's no new instances at all, by which point we'd have lost the rich ecosystem of tiny communities that make fedi unique. Large instances can never provide a truly safe space, and often foster a community much like Twitter - problems included. The small, diverse instances are what make this network special. If we lose that, then we lose the fediverse.
@HaruEb@hazelnoot allowlist would make some sense if there was some mechanism to notify admins and mods of a new instance for review (to check if it isn't dedicated spam/harassment/illegal material, etc). Or at least some way to add a new entry on request when an user sees a broken thread or boost. I'm running an allowlist instance on the side and it's honestly barely usable.
devs these days fear sql thats why they use all these shitty bloated slow json or documents databases for EVERYTHING now because they can just offload to some IaaS or some nodejs wrapper and dump and take without any consideration for optimization or how things should be done they might as well be writing to the filesystem
Table "public.activities"
Column | Type | Collation | Nullable | Default
-------------+--------------------------------+-----------+----------+------------------------------
id | uuid | | not null |
data | jsonb | | not null |
inserted_at | timestamp(0) without time zone | | not null |
updated_at | timestamp(0) without time zone | | not null |
local | boolean | | not null | true
actor | character varying(255) | | |
recipients | character varying(255)[] | | | ARRAY[]::character varying[]
I mean it’s not all raw json and I wasn’t entirely serious with that, but yeah, the pleroma db is somewhat famous for doing that.
i dont get why anamanaguchi is so well known for their miku song... :blobcatgoogly: they have such good music, i for example love this one: https://www.youtube.com/watch?v=F65GFoH4V_A
