wowana.me

website source


commit b7e40396bb43fec58eafe277ae5c1e2e28c0272b
parent 34295c628c5566f1e91920ebc2d486ea3dc6229f
Author: opal hart <opal@wowana.me>
Date:   Mon,  9 Aug 2021 20:08:27 +0000

new blog post: "toward a healthier federation"

Diffstat:
Asrc/blog/toward-a-healthier-federation.md | 423+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 423 insertions(+), 0 deletions(-)

diff --git a/src/blog/toward-a-healthier-federation.md b/src/blog/toward-a-healthier-federation.md @@ -0,0 +1,423 @@ +# toward a healthier federation +<!--[time 202107090728.01]--> + +it's been a while since I've given a proper update on how I'm doing +personally, but things have slowed down enough this week, to the point +where I can properly reflect on recent happenings and my general +bearing. after almost a year of unemployment, I am optimistic in finally +landing a job—in retail, but the pay is good, and I'm not tasked to +coerce computers to do anything by means of satanic rituals. this means +that I finally know what to focus on, ever since I [asked what I should +be doing with my life][1]; but don't worry, after I get comfortable +earning a stable income, I can slowly start focusing more on the side +projects I wanted to finish, and I don't have to feel pressured to turn +it into a living. I want to enjoy my ambitions and not worry about +risk/return for any of it. I should be able to fund, both the time and +the money required for my goals, out of my own pocket, and not have to +ask anyone else for help. + +I've also decided to focus more on *my own* projects rather than other +people's. so far, I have been in charge of hosting people's websites and +communities; Hidden Answers is a notable example since I had to head +adminship after the original owner left. I feel out of place in these +situations, I have a warped sense of indebtitude, I believe I owe people +to run services that I never personally wished to head. this is an +unhealthy approach to running communities and only serves to negatively +impact everyone involved. so, I am going to make efforts to transition +control of those communities over to people more suited to run them, or +I will even consider letting them go entirely. + +this leads nicely into my main talking point: after lengthy +consideration, I believe I am tired of certain communities in general. + +[1]: </blog/rfc-which-projects-are-you-interested-in.xht> + +## case study: an anime website + +[anime.website][] is a [fediverse][] server with the stated goal of +being free to use and open to discussion about any topic protected by +law. starting in 2018, I have had a lot of fun discovering fedi, feeling +like I found a great alternative to twitter—a microblogging platform +where I was free to be myself, to say what I want, without fear of +report brigades deciding my fate to be removed from the platform. I +wanted to share this feeling with others, and besides, the domain was +fairly expensive, so I figured I would give it its money's worth. I +opened registration early on, to anyone who wished to join, regardless +of their beliefs or even whether they respected me personally. + +this was fine for a while. I was able to handle the occasional rift in +the tide from certain new users who decided to exploit my generosity and +patience for their own benefit. however, in 2021 my sentiment changed +drastically after receiving *a lot* of new registrations from certain +groups who were being chased off twitter and other platforms, and were +looking for a place to settle. + +the people who have been paying closer attention already know exactly +what I am talking about. paedophiles (<q><abbr title="minor attracted +person">MAP</abbr>s</q>) were the main demographic attracted by the +freedom on anime.website as well as my tolerance and indifference to +their beliefs and attractions. and for a while it was relatively fine. +the existing users on anime.website were fairly prepared for a new wave +of users like this—vocal /pol/ users would have been the other option, +but they seem to have fit in better with other communities on fedi—but +at some point, the influx of new users and their adamancy to post +untasteful (yet legal) content reached a tipping point, and +anime.website had its own eternal september. older users grew tired of +the constant disregard that paedophiles had for the external criticisms +we were facing, by people who were concerned about their views, whether +they would post illegal content, and their insistence to start shit with +random others. + +as an aside, this behaviour, this phenomenon, is in no way exclusive to +paedophiles; there have been a lot of user influxes that fedi has faced, +including kiwifarms, gab, and mass twitter storms; but the fact that +these people were attracted to children, *did* undeniably serve as a +catalyst for pissing people off. thankfully, I have only had to deal +with one occurrence of child pornography on my server, but people were +still really sensitive about how I handled this crowd of users, about +how I dare show indifference to lending these guys a platform, and as +such, my and my instance's reputation took a thorough hit. I believe +that most of this external feedback is a result of <q>cancel culture</q> +and mob mentality, where people refuse to understand certain taboos, and +they will apply a guilt-by-association to anyone who does show any form +of indecisiveness, indifference, or tolerance to such groups. however, +that doesn't mean I think they're completely full of shit, especially +hearing some of the same complaints from my older users—some of them my +friends—about how they are enjoying anime.website less, now that these +new people stormed in and claimed it as their own. I began to share that +sentiment over time as well. + +[anime.website]: <https://anime.website/> +[fediverse]: </blog/federated-social-networking.xht> + +## death to the community + +first of all, I never intended anime.website to form any sort of +community; I intended for it to be a platform, a carrier. in hindsight, +anime.website evolved into a sort of community anyway, for a few +reasons. + +the instance utilises [Pleroma][] as its ActivityPub software +implementation, which models after the older [GNU social][] with ideas +such as microblogging, public timelines, and an overall feel of a +twitter interface. public posts are divided into two timelines: one +containing posts from users on that instance, and another which accounts +for *any* public post that the server has ever come across. the +instance-specific timeline has a tendency to promote a community; people +use it to welcome new users to an instance, to find users that may have +similar interests, and to develop a general image of what that instance +consists of. I have been guilty of using the timeline as well, despite +advocating for people to follow accounts they wish to keep up with, +regardless of what instance they're on. + +in addition, I neglected to consider that the rules alone would attract +or deter people from my instance. that in itself is a signal, a tribal +call to assimilate people with similar values, and as such it will +attract people who are usually likeminded enough to be likely to form a +more-specific community. + +I have also modeled anime.website based on my previous experience with +twitter, as well as my time on imageboards such as 4chan. the name +itself is a nod to a meme on 4chan, and that alone has caused people to +register because they were <q>in on the joke</q> and felt comfortable +there. + +I made a mistake—not because I failed to discourage the formation of a +community, but because I did not account for the fact that a community +surrounding a platform is *inherent* in some form. going forward, I need +to adjust my expectations in response to this. it's important to +understand how platforms grow, how they must evolve, what their critical +mass is before they begin to deteriorate. + +truthfully, I did enjoy the community aspect of anime.website while it +lasted. I made a few friends, even developed a few relationships, and +met people I otherwise would not have, had I not created the instance as +I had. but, I still treat this as an experiment rather than a final +product I can be happy with. the software alone has been a result of +many headaches, and in general I handled administration in a haphazard +manner, enough to negatively impact how I myself and others have been +able to enjoy the instance. + +in general, some aspects of fedi and social networking tire me, so I +don't know my future as far as that is involved. I do want to stay +involved with fedi if I can find continued worth in it, because I have +enjoyed it for a while; this year has just made it very difficult to see +how useful and rewarding it *can* be, because of all the technical and +social issues it currently has to face. hopefully these can be fixed, +but they will take a lot of time, effort, and combined involvement. the +internet, and especially social media, are still very new, and we still +experience growing pains trying to adjust our interactions and +expectations so that we can exist in harmony with everyone else out +there. I have plenty of difficulties with this as well. + +I'll focus on other platforms and technologies for a while and then +hopefully come back to social media with a clearer mind, to decide +whether I want to pursue it and give it another shot, but this time in +another direction than I took with anime.website. + +[Pleroma]: <https://pleroma.social/> +[GNU social]: <https://gnusocial.network/> + +## an end to free, open registration + +for a while, I have been approaching the conclusion that <q>free</q> +services—open for anyone to register—are ultimately harmful both to +users and to networks at large. the oft-repeated adage that <q>there is +no such thing as a free lunch</q>, or simply put, <q>freedom ain't +free</q>, hold true for a number of reasons. + +free services rely on a form of sustinence to make up for the fact that +users don't pay for the services. on the corporate scale, a service may +choose to enact advertising; selling of <abbr +title="personally-identifiable information">PII</abbr> or other +sensitive data, metadata, and analytics; tiered subscriptions or paid +features; or a combination of these. sites such as pastebin and imgur +follow this pattern—while they started out truly free, eventually +reality set in and they had to compromise on their initial promises in +order to continue service. at a smaller scale, administrators (usually +hobbyists) may ask for donations or quit entirely, once they can no +longer support running a free-for-all service. + +the issue is exacerbated by netizens who have been accustomed to free +services and believe they are entitled to access. this promotes a +leecher culture, as well as a growing schism between users and +administrators, which results in an unhealthy dynamic akin to parents +and their spoiled kids. such a dynamic cannot be well-sustained and +commonly results in, yet again, admins compromising on their initial +values, or burning out entirely, unwilling to continue hosting their +services. users need to be reminded: you get what you pay for. for a +free service, you are not owed anything in return, and you should not +act like you are. + +aside from these issues, free services do not scale for another major +reason: it is more difficult for administrators to stem abuse from +their platforms, since with a free service, there is relatively little +cost for registering and almost no punishment for burning through +accounts (or in the case of anonymous services, virtually no cost at +all). this places an increasing burden on administrators to increase +their moderation by means of additional human moderators; filtering +solutions such as captcha, account approval, or automated moderation; a +combination of these; or even shutting off from new registrations +entirely. + +and since the community aspect is virtually unavoidable, there is always +a critical mass that, when exceeded, deteriorates the community +profoundly and forces a service to drift entirely from its founding +goals, caving to the new users' wishes. that is of course, unless the +service decides to close off entirely, much like the consequences of the +above issues. + +in comparison, invite-only services do away with these problems in part +or in full. there is a cost associated with joining the service, whether +it is monetary or social. additionally, it is expensive to lose an +account due to the registration requirement. this disincentivises abuse, +allowing for easier moderation. this also increases an administrator's +motivation: new users are almost guaranteed to be a net addition to the +community, rather than a coin toss. monetary payment guarantees that the +service can be more-easily sustained financially, and social proximity +allows for a better chance for admins and users to mutually benefit. + +invite-based services can take on a range of forms: it may be someone +providing a service for a group of friends; it may require a fee or +donation to join; it may be based off a preexisting community or shared +interest; it may involve an invite tree such as those used by lobste.rs +and private filesharing groups. all of these perform variably, but they +share a common goal of vetting new users to prevent growth spurts and +stem abuse. + +## f2f networking + +closed services do not equate to centralisation; quite the opposite, +since they coexist perfectly in federated networks. the network as a +whole can take on a natural and efficient dynamic, where each peer can +specialise in moderating their own group. + +with open federation, there still exists a need to trust that a +network's administrators have a common goal to ensure that federation +remains healthy and beneficial to all involved. this incurs a cost +requirement—a barrier to entry—for the creation of a new federated +service, however, which of course deters new people from deciding to +self-host. currently, for any service, the barrier usually involves +needing an always-on server with a public IP address, which thankfully +is fairly inexpensive and accessible, but still requires a time and +monetary investment, research, and ability to compare and vet various +hosting providers. also, this requirement presents another issue: +centralisation of hosting providers themselves. ideally, hosting from +home will be a more viable solution in the future for this reason. + +most platforms will need a domain as well, which again can be found +fairly cheaply, but individuals are prone to common traps due to the +lack of public, well-curated knowledge required to select, purchase, and +configure a domain. projects such as [OpenNIC][] aim to lower the +barrier of entry for registering a domain and even hosting public +nameservers, with the caveat that such domains are *only* accessible to +other OpenNIC users. this is going to be an unacceptable solution for +most people who want their platform to be as accessible as possible. + +additional barriers mostly depend on the type of service being hosted. +for example, the hurdle to overcome for hosting a mailserver is steeper +than for other services. this can partly be overcome by providing +accessible documentation and tools for setting up new services. + +open federation sees varying degrees of success. on the optimistic end, +XMPP has done very well to remain a cohesive network with few +interoperability issues. they have adapted quickly to modern security +standards, requiring the use of verified server-to-server TLS +connections (made easier with Let's Encrypt certification) and various +protocol extensions. conversely, E-mail has issues with introducing new +standards, and large mail providers are reluctant to push optional +features as crucial for interoperability. that, coupled with the problem +with how providers handle abuse in a myriad of ways, results in a +confusing landscape that is difficult to navigate without extensive +research into the subject. the fediverse suffers a similar fate, but +the issue is not so much about technical differences, but social +expectations. almost every fediverse administrator has their own goal +with federation, which often directly conflicts with the desires of +other administrators. this equally leads to a schismatic, unhealthy, and +inaccessible network. + +potentially, there is a unique approach to some of these issues: +friend-to-friend networking. the option for f2f topology exists +primarily in peer-to-peer filesharing such as [Freenet][] and +[Retroshare][], but [anoNet][] happens to be the project I am most +familiar with. anoNet is a friend-to-friend overlay network that +utilises VPN technologies, and nodes peer with one another by exchanging +information beforehand. access to the network is always possible if you +know at least one <q>friend</q> who is willing to peer with you, which +in theory raises the cost of abusing the network while at the same time +preserving freedom and autonomy in the network as a whole. [dn42][] is a +similar project—more mature but with a more-centralised governance, +unlike anoNet's ad-hoc, entirely anarchist model. protocols such as +[cjdns][] and [Yggdrasil][] have also emerged and have a similar peering +model. + +time will tell if the f2f model ultimately prevails, but I see it as a +promising middle ground between centralisation and open federation. this +issue is fundamentally a social one, and at some point people will have +to agree on what best fits their needs, making necessary compromises +along the way. + +[OpenNIC]: <https://www.opennic.org/> +[Freenet]: <https://freenetproject.org/> +[Retroshare]: <https://retroshare.cc/> +[anoNet]: <http://www.anonet.org/> +[dn42]: <https://dn42.net/> +[cjdns]: <https://github.com/cjdelisle/cjdns> +[Yggdrasil]: <https://yggdrasil-network.github.io/> + +## Postel's law + +be conservative in what you send and generous in what you receive. +originally a principle used in the design of TCP, this equally applies +to social networks in general. how well it applies has been up to +debate, however. + +for technical protocols, the robustness principle has the benefit of +tolerating implementation variations that arise from tolerances or +omissions in the original protocol specification. unfortunately, this +presents the risk of such deviations to be cemented into the <i +lang="la">de facto</i> specification, thus limiting future +implementations' freedom to deprecate such tolerances and create a +stricter conformance to the protocol. this also makes way for buggier +code overall, since there are more edge cases to consider. + +from a social standpoint—more specifically, from the standpoint of +federation—this implies that individual peers are expected to play nice +with the rest of a network, while at the same time tolerating issues +that arise from remote peers. this results in additional overhead for +administrators who wish to curate their node, as they not only have to +moderate their own users' activity, but also any activity from the rest +of the network, since not all admins will see eye-to-eye on what is +allowed. + +generally, though, I believe a baseline for conduct goes hand-in-hand +with Postel's law; namely, nodes and their users should follow an opt-in +principle for interaction. most people have a sense of what spam +entails, and they do their best to address the issue appropriately, but +there is still significant nuance regarding what exactly passes for +spam. in my eyes, any form of unsolicited interaction with other users +is spammy and should be discouraged. this is a highly situational rule +of thumb, a subjective one, but it is an unavoidable social issue that +cannot be resolved by technical means alone. + +other than that, I adhere to a <q>live and let live</q> approach, where +users on other nodes may be doing things I don't agree with, but I +retain the freedom not to hear from them, and others retain their +ability to interact with them at their own risk. + +## administrators are not cops + +commonly, I see administrators who excuse the content they delete as +<q>being on the safe side of the law</q>. while I understand this +sentiment, and while it is entirely valid to have this concern, it is +not the way things should be. many countries enact safe-harbour and +neutral-carrier laws in order to *absolve responsibility* that online +platforms have for their users' content, and ideally, administrators +only need to comply with law enforcement requests for information or +data removal. + +instead of desiring to push back against the pressure to do law +enforcement's job, administrators unfortunately seem complacent to +self-censor, thus setting a precedent toward actually being responsible +for user-generated content. while laws generally allow administrators to +take a best-effort approach toward curating their content, I know that +U.S. law *does not require this* and there has been at least one motion +to modify or repeal Section 230, which would require platforms to take a +completely hands-off approach (which was common practice in the early +days of the Internet) unless they want to be held responsible for user +content. + +administrators often worry about proxied content for similar reasons, +which is an important concern for federated platforms, since the +majority of content will originate from remote servers and be cached +locally. it is not anyone's responsibility to ensure that a huge network +is clean of all illegal content, and nobody should worry about such +proxied content landing on their servers. it should be dealt with at the +source, punishing the user who actually posted that content. + +my issue with all this, is that it places more pressure on services and +organisations that do not have the luxury to afford a legal team to deal +with uploaded content. ideally, law enforcement exists so that the +general public doesn't have to enforce the law. in addition, it is +better to properly handle a situation by reporting it to law +enforcement, rather than destroying evidence by deleting content or +banning users immediately. + +people don't want to be arrested due to the actions of others, and nor +do I. that much I understand. but I believe we should be working toward +a way to handle this issue better, rather than censoring ourselves +because we are deathly afraid of the consequences of self-hosting. this +is a huge barrier for many people who want to set up a platform, since +it quickly sets in that, yes, this is the Internet, and people love to +abuse it. + +one goal I hope to achieve, is to provide administrators with affordable +legal counsel in a similar manner to how the EFF handles privacy- and +Internet freedom-related cases <i lang="la">pro bono</i>. hopefully this +will be a way to ease people's concerns about their self-hosted +platforms, encouraging hobbyists to dive right in and have fun online, +rather than being worried and taxed by unnecessary responsibilities. + +## summary + +collectively, we have a lot of work before we can reach an ideal of +self-hosting, making it more accessible to newcomers and a more +sustainable model on the Internet. I have had enough experience with my +responsibilities and projects, and enough time to mull this over, that I +am more confident in my direction going forward. I will be more focused +on my own passions, and less focused on providing services that I never +strongly believed in. I do not want to accomodate for people who give me +little in return; I wish to pave my own road and let others follow me if +they share my ambition. and I think everyone should take care to do +this, so we can begin forming a healthier ecosystem—one that is driven +by the community, for the community, and not controlled by corporations +with ulterior interests that disalign with their userbases. + +while I extensively talk about federated networks, and my personal focus +is on federation, I also keep an eye on peer-to-peer developments (and +have a strong interest in some of them, such as BitTorrent), but p2p is +*much* harder to get right, and I believe that we won't approach a +pure-p2p solution for a long while. federation is a step in the right +direction, with the tools we have, and it has been a longstanding +cornerstone on the Internet, proving its effectiveness and relative ease +to implement.