First they will add loads of new users and become the dominant instances. Then, they will add their own proprietary features that other instances cannot support. Finally, their extensions become the new de-facto standard, marginalizing the original implementations.
Since Meta has proven itself to be an evil company that does not act in good faith, it is better to not federate with them from the start.
Exactly this. In a federated network, the instance with the majority of users could dictate the protocol, forcing the smaller issues to continually adapt or die. See this post for a very real example of this.
But why do the current lemmy instances have to die if facebook decides to make ActivityPub+goldextra? We’ll just stay on our branch, maybe lose a few users who should know better. Facebook isn’t even making use of ActivityPub’s federation anyway, which is why we are here.
I’m actually afraid that they won’t defederate at some point but find some way to track the activities of the federated servers.
Becsuse you don’t move to the next phase until you reach a milestone. The embrace is the first step, to convert a small percentage of users of the original platform. Once you have those, you extend your features to have those users recruit more users to that specific instance or implementation, since they are more feature-rich or stable or whatever. Then once you have a critical point of users on your instance, you defederate from all others and develop your walled garden which now has all the users and the content.
I have no questions, but I want to let people here know that there are two excellent websites related to this: http.cat and http.dog, for looking up HTTP status codes.
For an example, if http.cat/418 doesn’t brighten your day, I don’t think there’s much that can.
I think it’s excellent out here. I was stuck on Reddit for the longest time, and this recent debacle has pushed me to explore the networks at the edge; this feels a lot more like the Internet of old. The analogy of email is apt, I think, with the accounts on multiple servers and the interplay between.
It’s great: the Internet should have a bit of that sense of whimsy, and knowing that there’s official support in many libraries for “you’re asking me for coffee, but I’m a teapot” is one of those things that gets me through the day.
That’s actually the topic of the talk! Around 1995-96, HTTP was picking up all kinds of use outside the academic community, and people were tacking extensions on left and right; one of the biggest was file upload support, which was done by throwing HTTP and email into a room and having them fight it out. Which is how we ended up with the monstrosity that is “sending emails over HTTP”, also known as “posting a form”.
The author of HTCPCP decided to codify some of his concerns with these, partly as a joke; I noticed long afterward that his joke was only standardized for coffee, which Personally Offended me as a citizen of a tea-drinking nation.
The number one question I would ask about HTTP would be: Why was the “Referer” header initially added and why wasn’t it removed from standard to this day. In my opinion the server, I’m going to, should never know where I came from.
I’ve just done some quick browsing to see if there’s a written-down motivation for Referer existing, and there’s this on the Wikipedia: “Many blogs publish referrer information in order to link back to people who are linking to them, and hence broaden the conversation.”
Which I guess makes sense, in the context of the original use of HTTP as an academic publishing protocol, but it’s gained cruft and nefariousness since wider adoption came about.
There are good arguments for stripping Referer from the standard, and yours is one of the most cogent; if Referer is still a thing in another 30 years, I’d be surprised.
There are far more robust methods of fingerprinting to spy on users anyway (adding up all the details of screen size, available fonts, language, os, etc, etc), so I don’t think removing the user agent would have much impact in reducing fingerprinting alone. It’s also useful as a quick and simple way to check the type of device, os, or browser the user is on and serve the correct content (download link for one’s OS) or block troublesome clients (broken bots)
Someone explained it really, really well on Reddit some years ago:
Hexbear.net started out as chapo.chat - a replacement for the defunct r/ChapoTrapHouse community after it was banned from Reddit. It launched one year ago today, based on a modified version of the Lemmy source code. At the time, Lemmy itself was only around a year old, and in an alpha state. Since r/ChapoTrapHouse had accumulated a long list of enemies in its time, a dozen or so members of the community did about a month-long sprint hardening Lemmy and adding features that reflected the needs of the community.
The developers of Lemmy maintained a pretty low-profile community, while the Chapo refugees were the exact opposite of low-profile, so the communities had divergent priorities. It wouldn’t be fair to demand the Lemmy developers drop everything they were doing to satisfy the Chapo refugee’s needs, but the needs of the Chapo community still had to be met for the project to be successful.
The process was very chaotic, and as a result, the fork of Lemmy used for Hexbear.net will likely never be capable of federating with the wider network of Lemmy instances. A handful of changes were contributed upstream, but many of them likely will never be accepted. None the less, it still abides by the AGPL license and the code is publicly available on git.chapo.chat.
The relationship between Hexbear.net and Lemmy is basically that the Chapo refugees decided Lemmy was the most viable platform to work with, and the Lemmy developers were completely blindsided. The Chapo git repository recorded about 2000 changes within the span of a month and not all of the changes were ideal or appropriate to adopt upstream. Within a week or two of launching, chapo.chat had more users than the flagship Lemmy instance. This was also before federation was officially supported upstream, even though that was always the goal of the project. Had the timing worked out differently, Hexbear might have been federated before adding additional features for their instance, but that’s not how things turned out.
undefined> The process was very chaotic, and as a result, the fork of Lemmy used for Hexbear.net will likely never be capable of federating with the wider network of Lemmy instances
actually hexbear is currently on Lemmy v0.17.0, when they update to version 0.18.0 they will be able to federate
This is crazy to me. All this time there’s been a 20k user instance out there just chilling by itself, and we may all start talking to each other one day.
As ice cream sales in the United States increase, so do deaths in in developed parts of Africa.
I use this fact to explain to students how true information can be used to mislead people into drawing wild, deranged conclusions.
The commonality in these events is the rise in temperature during the summer. But if you leave that out, there’s an absurd argument to be made about how purchasing ice cream is inherently evil.
I don’t think it’s an amazing example of what OP is talking about, but as an example, I like how simple and easy to follow it is. Great for junior high level kids.
Correlation at least tries to imply they’re related. As lottery sales go up in your household so does credit card debt. Not always a cause but they’re related
You’re looking for spurious correlations which is when numbers have no business even being used in a comparison
asklemmy
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.