commit 3572d508bbccd4fe8cd47bb299d8dd3964fd0c74
parent 7f67a761735e297ceafdab7c129d7b5d439a63b6
Author: rra <rscmbbng@riseup.net>
Date: Tue Jan 7 19:02:57 +0100
merge previous edits and add links to archivers
Diffstat:1 file changed, 9 insertions(+), 15 deletions(-)
diff --git a/on-not-scaling-lurk/on-not-scaling-lurk.md b/on-not-scaling-lurk/on-not-scaling-lurk.md
@@ -23,20 +23,19 @@ In terms of long-term sustainability, the growth of the space is a consideration
-Since the start, we tried to focus on quality over quantity on post.lurk.org. This has meant that we try to maintain a healthy diversity—across genders, creative practices, cultural backgrounds —rather than aiming at opening the door to a large number of people vaguely connected or interested in digital media and cultural practices. This is to a large extent because we do this for the sake of it and in our spare time, so we want this to remain an interesting place and hub for communities of practice that inspire us, rather than a chore. At times, and since last November 2022, particularly that has meant that we need to engage the brake on new sign-ups to be able to make sure that this sentiment keeps on being shared by everyone. At the same time, this means we have had to exclude some folks, who, as a consequence, felt left out. We're not saying that the way we're doing things is perfect, and it's difficult to communicate about this choice, hence this long text. It can be a bit discouraging when from the outside, and from peers we had to decline, we hear that this reticence of letting more, and more-of-the-same, people is perceived as an attempt to create some exclusive cool kids club (true story).
+Since the start, we tried to focus on quality over quantity. This has meant that we try to maintain a healthy diversity—across genders, creative practices, cultural backgrounds —rather than aiming at opening the door to a large number of people vaguely connected or interested in digital media and cultural practices. This is to a large extent because we do this for the sake of it and in our spare time, so we want this to remain an interesting place and hub for communities of practice that inspire us, rather than a chore. At times, and since last November 2022, particularly that has meant that we need to engage the brake on new sign-ups to be able to make sure that this sentiment keeps on being shared by everyone. At the same time, this means we have had to exclude some folks, who, as a consequence, felt left out. This sucks, we know it sucks, and it's the consequence of refusing to scale.
-Nevertheless, we feel that this strategy has paid off. For us, one of the great things about having been involved in post.lurk.org is the quality of the space and how generative it has been for our practices versus how little time we, as an admin team, have to put into it to keeping it running. That is something we want to maintain and something that is at risk when growing the instance more and more. Still, we want a mechanism where people can join post.lurk.org. After all, even if we want to not grow, there is also the fact that some people join and eventually leave, some just join and never use their account. Some simply disappear into the ether after a while. That's cool. But this means that we could potentially welcome new people occasionally, without compromising on our way of running the instance.
+Nevertheless, we feel that not-scaling has paid off. For us, one of the great things about having been involved in post.lurk.org is the quality of the space and how generative it has been for our practices versus how little time we, as an admin team, have to put into it to keeping it running. That is something we want to maintain and something that is at risk when scaling the instance. Still, we want a mechanism where people can join post.lurk.org. After all, even if we want to not grow, there is also the fact that some people join and eventually leave, some join and never use their account and some simply disappear into the ether after a while. That's cool. But this means that we could potentially welcome new people occasionally, without compromising on our way of running the instance.
-Until now, we did this is in a relatively unstructured way, opening applications every now and then, and receiving suddenly a huge wave of messages from people explaining to us why our instance is meaningful to them. Filtering these applications is one of the most unrewarding and stressful things about this approach, all the while having to make important but also, at times, arbitrary selection. Part of the issue is because of the crappy interface for selection—there is no possibility to respond to an application outside accept or reject, for instance—but a larger part is based on the arbitrariness of it. The secret LURK truth is more often than not, people we found exciting based on their application turned out to not be super engaged (if at all), and likewise, people we let in on a whim have become some of the nicest LURKers! Of course, we’re not naive, and this is a social process that is not that surprising in community building. The point is that we feel that the application method is not only
-stressful, but also doesn’t add anything to existing social processes emerging in online communities. Let’s try something else!
+Until now, our onboarding was ad-hoc.Opening applications every now and then, and receiving suddenly waves of messages from people explaining to us why our instance is meaningful to them. Filtering these applications is one of the most unrewarding and stressful things about this approach, all the while having to make important but also, at times, arbitrary selections. Part of the issue is because of the crappy interface for selection—there is no possibility to respond to an application outside accept or reject, for instance—but a larger part is based on the arbitrariness of it. The secret LURK truth is more often than not, people we found exciting based on their application turned out to not be super engaged (if at all), and likewise, people we let in on a whim have become some of the nicest LURKers! Of course, we’re not naive, and this is a social process that is not that surprising in community building. The point is that we feel that the application method is not only stressful, but also doesn’t add anything to existing social processes emerging in online communities. Let’s try something else!
-One of the decisions we made in November 2022 is to cap the number of accounts on post.lurk.org at 666 (keeping with our tradition of using Meaningful NumbersTM™). The past years we stuck with that and it has felt pleasant. And here is the plot twist, starting now, we will automatically remove unused accounts. We will warn (of course!) accounts that have not logged in for 12 months and delete them after 13 months of inactivity. This allows more people to join post, and automatically and slowly open up new spots for others to join, as people lose interest or move on, which is fine really—please send postcards, though. We will hand out invites to you if you request them, but we *really* still want to privilege both diversity *and* people that are not yet on the fedi. You will be for sure lectured about it once more by the Helpful Heron when you ask for an invite URL!
+One of the decisions we made in November 2022 is to cap the number of accounts on post.lurk.org at 666 (keeping with our tradition of using Meaningful NumbersTM™). The past years we stuck with that and it has felt pleasant. And here is the plot twist, in the future, we will automatically remove unused accounts. We will warn (of course!) accounts that have not logged in for 12 months and delete them after 13 months of inactivity. This allows more people to join post, and automatically and slowly open up new spots for others to join, as people lose interest or move on, which is fine really (please send postcards, though!). We will hand out invites to you if you request them, but we *really* still want to privilege both diversity *and* people that are not yet on the fedi. You will be for sure lectured about it once more by the Helpful Heron when you ask for an invite URL!
-It's also important to say that, next to running the LURK instances and its other services, we are also active developing and offering workshops for communities to onboard the fediverse, not just as users of an existing instance, but as collective administrators of their own instance [^runyourown]. And this is really the key thing that cultural workers need to understand about decentralised and federated social media, namely the promise of having a balance between online communities of practice that are humanly scaled, and still be able to connect and reach out to many many many others. For instance, very recently, it was very exciting to see the new [social.toplap.org](https://social.toplap.org) instance emerge to give a proper hub for live coders, who until now tended to flock to LURK or similar places where algorithmic and software art is welcome (like [merveilles.town](https://merveilles.town) and [sonomu.club](https://sonomu.club) instances). Running your instance is not trivial, but it's not impossible for a small group of motivated people, as we've seen in our workshops. And this instance mitosis is the kind of scaling we'd like to see more happen on the Fediverse instead of the emergence of heavily centralised and large instances.
+It's also important to say that, next to running the LURK instances and its other services, we are also active developing and offering workshops for communities to onboard the fediverse, not just as users of an existing instance, but as collective administrators of their own instance [^runyourown]. And this is really the key thing that cultural workers need to understand about decentralised and federated social media, namely the promise of having a balance between online communities of practice that are humanly scaled, and still be able to connect and reach out to many many many others. For instance, very recently, it was very exciting to see the new [social.toplap.org](https://social.toplap.org) instance emerge to give a proper hub for live coders, who until now tended to flock to LURK or similar places where algorithmic and software art is welcome (like [merveilles.town](https://merveilles.town) and [sonomu.club](https://sonomu.club) instances). Running your instance is not trivial, but it's not impossible for a small group of motivated people, as we've seen in our workshops. And this instance mitosis is the kind of scaling we'd like to see more happen on the Fediverse instead of the emergence of unsustainable and large instances.
@@ -49,14 +48,10 @@ Surely, there is an alternative timeline where LURK is run as a super structured
Concerning financial sustainability, one of the ways we have been receiving (and gladly accepting) a tremendous amount of support is in terms of donations. We started an [Open Collective](opencollective.com/lurk) in 2021 and have been amazed at how people have chipped in. Because we are small, frugal, anti-cloud and get some of our infrastructure sponsored[^sponsored], we have historically spent very little costs regarding infrastructure. The reason we started collecting donations was to see if we could compensate for maintenance labour instead, and hopefully demonstrate the value of such a tactic at a time when Big Tech and a misunderstanding of open forms of software production have led us to believe that the digital commons and digital solidarity are a thing falling from the sky. This is
-even crucial for us, as, like discussed earlier, we are often helping other
-cultural workers to run things themselves and pretending that the economic dimension does not exist is incredibly dishonest. (Post-)Free culture evangelism has to stop sounding like an obscure hypocritical pyramid scheme
-with only the most privileged ones who are able to play the game. To our surprise, soliciting donations has worked so far, and we have been using the majority of donations to compensate for sysadmin and moderation labour
+even crucial for us, as, like discussed earlier, we are often helping other cultural workers to run things themselves and pretending that the economic dimension does not exist is incredibly dishonest. (Post-)Free culture evangelism has to stop sounding like an obscure hypocritical pyramid scheme with only the most privileged ones who are able to play the game. To our surprise, soliciting donations has worked so far, and we have been using the majority of donations to compensate for sysadmin and moderation labour
of the team. We believe we are one of the few instances where donated funds are used primarily to pay people, rather than cloud companies.
-However, we also realize that this can raise expectations on what LURK as a project will become, and we want to be explicit that we are not planning to change the nature and scale of our operation. We will use the funds to continue to pay for labour, keep a buffer for these moments where we suddenly need to fix something urgently. If there is any surplus, we aim to donate upstream. This can be to either Servus (who hosts one of our servers for free until now), or to Hometown the modified version of Mastodon we use (which is difficult as, probably for the same reason as LURK, has no formal structure), or to useful Mastodon clients, or to other FLOSS and related projects we rely on. We are still trying to figure out how we will make it work and it will likely take a couple of years before we have something that works. Fermentation. To be honest, it’s difficult to
-get a clear idea of our operational expenses in terms of labour, and as a result, how to best use the buffer. Before asking for donations we spent two years carefully writing down all the time we spend on maintaning LURK
-infra to get an idea of how much labour would need to be supported. At the moment we're still juggling with things. For instance, we’ve now noticed that it only takes a few days of technical or moderation clusterfuck for
+However, we also realize that this can raise expectations on what LURK as a project will become, and we want to be explicit that we are not planning to change the nature and scale of our operation. We will use the funds to continue to pay for labour, keep a buffer for these moments where we suddenly need to fix something urgently. If there is any surplus, we aim to donate upstream. This can be to either Servus (who hosts one of our servers for free until now), or to Hometown the modified version of Mastodon we use (which is difficult as, probably for the same reason as LURK, has no formal structure), or to useful Mastodon clients, or to other FLOSS and related projects we rely on. We are still trying to figure out how we will make it work and it will likely take a couple of years before we have something that works. Fermentation. To be honest, it’s difficult to get a clear idea of our operational expenses in terms of labour, and as a result, how to best use the buffer. Before asking for donations we spent two years carefully writing down all the time we spend on maintaning LURK infra to get an idea of how much labour would need to be supported. At the moment we're still juggling with things. For instance, we’ve now noticed that it only takes a few days of technical or moderation clusterfuck for
our buffer to empty very fast. What is sure is that your ongoing support in the form of donations will allow us to continue this fermentation of community server maintenance for the long term. <3
@@ -65,10 +60,9 @@ Last but not least, at the intersection of financial and ecological sustainabili
-One of the things we do on post.lurk.org to counteract this is to frequently prune this cache on the server. That however, has some implications: only the most recent remote posts are visible instantly, and,
-remote profiles that haven’t been interacted with in a while will not have avatars or profile headers. When we remove remote users from the database that have not been active in a long time, this can this can also mean that you lose followers. Or, to be more precise, the “followers” counter will be suddenly lower, since you likely already lost those followers as the remote accounts will have stopped using the fediverse a long time before we remove them. Having said that, things like favourites and bookmarks are not deleted, and we also won't delete your personal data (unless your profile becomes inactive for longer than a year, and we send you a warning before that).
+One of the things we do on post.lurk.org to counteract this is to frequently prune this cache on the server. That however, has some implications: only the most recent remote posts are visible instantly, and, remote profiles that haven’t been interacted with in a while will not have avatars or profile headers. When we remove remote users from the database that have not been active in a long time, this can this can also mean that you lose followers. Or, to be more precise, the “followers” counter will be suddenly lower, since you likely already lost those followers as the remote accounts will have stopped using the fediverse a long time before we remove them. Having said that, things like favourites and bookmarks are not deleted, and we also won't delete your personal data (unless your profile becomes inactive for longer than a year, and we send you a warning before that).
-The reason to discuss this is that, at the end of the day, it also impacts the user experience, especially when the cloud mindset of “everything at my fingertips forever” is the default. Some of you use a feature of Mastodon to automatically delete old posts based on some conditions. At the time of writing we haven't really decided or discussed seriously if it's something we should encourage everyone to do and if yes, what would be the default strategy as it can be configured in many ways ([have a look](https://post.lurk.org/statuses_cleanup) to get an idea of all the options!). Keeping things constantly online that are essentially ephemeral, or low value, feels wrong since it uses actual resources. If you need to keep an archive, you can export it from the configuration panel, and with all the clever LURKers around, perhaps someone can make a masto2static script to serve your glorious toots elsewhere (and perhaps this is something we should put some LURK funds towards or crowdfund?).
+The reason to discuss this is that, at the end of the day, it also impacts the user experience, especially when the cloud mindset of “everything at my fingertips forever” is the default. Some of you use a feature of Mastodon to automatically delete old posts based on some conditions. At the time of writing we haven't really decided or discussed seriously if it's something we should encourage everyone to do and if yes, what would be the default strategy as it can be configured in many ways ([have a look](https://post.lurk.org/statuses_cleanup) to get an idea of all the options!). Keeping things constantly online that are essentially ephemeral, or low value, feels wrong since it uses actual resources. If you need to keep an archive, you can export it from the configuration panel and either [explore it](https://s427.github.io/MARL/), [explore it some more](https://purr.neocities.org/), or [turn them in to a web site](https://codeberg.org/oliphant/posty).
We want to mention this because one of the big unknowns at this point is whether we can continue running the server as we have done before as the entire network grows in size. For instance, one way the network will drastically grow, is if/when Facebook's Instagram's Meta's Threads becomes fully interoperable.
