wowana.me

website source; use git clone git://wowana.me/wowana.me.git to clone this repository.


toward-a-healthier-federation.md (23642B)


      1 # toward a healthier federation
      2 <!--[time 202107090728.01]-->
      3 
      4 it's been a while since I've given a proper update on how I'm doing
      5 personally, but things have slowed down enough this week, to the point
      6 where I can properly reflect on recent happenings and my general
      7 bearing. after almost a year of unemployment, I am optimistic in finally
      8 landing a job—in retail, but the pay is good, and I'm not tasked to
      9 coerce computers to do anything by means of satanic rituals. this means
     10 that I finally know what to focus on, ever since I [asked what I should
     11 be doing with my life][1]; but don't worry, after I get comfortable
     12 earning a stable income, I can slowly start focusing more on the side
     13 projects I wanted to finish, and I don't have to feel pressured to turn
     14 it into a living. I want to enjoy my ambitions and not worry about
     15 risk/return for any of it. I should be able to fund, both the time and
     16 the money required for my goals, out of my own pocket, and not have to
     17 ask anyone else for help.
     18 
     19 I've also decided to focus more on *my own* projects rather than other
     20 people's. so far, I have been in charge of hosting people's websites and
     21 communities; Hidden Answers is a notable example since I had to head
     22 adminship after the original owner left. I feel out of place in these
     23 situations, I have a warped sense of indebtitude, I believe I owe people
     24 to run services that I never personally wished to head. this is an
     25 unhealthy approach to running communities and only serves to negatively
     26 impact everyone involved. so, I am going to make efforts to transition
     27 control of those communities over to people more suited to run them, or
     28 I will even consider letting them go entirely.
     29 
     30 this leads nicely into my main talking point: after lengthy
     31 consideration, I believe I am tired of certain communities in general.
     32 
     33 [1]: </blog/rfc-which-projects-are-you-interested-in.xht>
     34 
     35 ## case study: an anime website
     36 
     37 [anime.website][] is a [fediverse][] server with the stated goal of
     38 being free to use and open to discussion about any topic protected by
     39 law. starting in 2018, I have had a lot of fun discovering fedi, feeling
     40 like I found a great alternative to twitter—a microblogging platform
     41 where I was free to be myself, to say what I want, without fear of
     42 report brigades deciding my fate to be removed from the platform. I
     43 wanted to share this feeling with others, and besides, the domain was
     44 fairly expensive, so I figured I would give it its money's worth. I
     45 opened registration early on, to anyone who wished to join, regardless
     46 of their beliefs or even whether they respected me personally.
     47 
     48 this was fine for a while. I was able to handle the occasional rift in
     49 the tide from certain new users who decided to exploit my generosity and
     50 patience for their own benefit. however, in 2021 my sentiment changed
     51 drastically after receiving *a lot* of new registrations from certain
     52 groups who were being chased off twitter and other platforms, and were
     53 looking for a place to settle.
     54 
     55 the people who have been paying closer attention already know exactly
     56 what I am talking about. paedophiles (<q><abbr title="minor attracted
     57 person">MAP</abbr>s</q>) were the main demographic attracted by the
     58 freedom on anime.website as well as my tolerance and indifference to
     59 their beliefs and attractions. and for a while it was relatively fine.
     60 the existing users on anime.website were fairly prepared for a new wave
     61 of users like this—vocal /pol/ users would have been the other option,
     62 but they seem to have fit in better with other communities on fedi—but
     63 at some point, the influx of new users and their adamancy to post
     64 untasteful (yet legal) content reached a tipping point, and
     65 anime.website had its own eternal september. older users grew tired of
     66 the constant disregard that paedophiles had for the external criticisms
     67 we were facing, by people who were concerned about their views, whether
     68 they would post illegal content, and their insistence to start shit with
     69 random others.
     70 
     71 as an aside, this behaviour, this phenomenon, is in no way exclusive to
     72 paedophiles; there have been a lot of user influxes that fedi has faced,
     73 including kiwifarms, gab, and mass twitter storms; but the fact that
     74 these people were attracted to children, *did* undeniably serve as a
     75 catalyst for pissing people off. thankfully, I have only had to deal
     76 with one occurrence of child pornography on my server, but people were
     77 still really sensitive about how I handled this crowd of users, about
     78 how I dare show indifference to lending these guys a platform, and as
     79 such, my and my instance's reputation took a thorough hit. I believe
     80 that most of this external feedback is a result of <q>cancel culture</q>
     81 and mob mentality, where people refuse to understand certain taboos, and
     82 they will apply a guilt-by-association to anyone who does show any form
     83 of indecisiveness, indifference, or tolerance to such groups. however,
     84 that doesn't mean I think they're completely full of shit, especially
     85 hearing some of the same complaints from my older users—some of them my
     86 friends—about how they are enjoying anime.website less, now that these
     87 new people stormed in and claimed it as their own. I began to share that
     88 sentiment over time as well.
     89 
     90 [anime.website]: <https://anime.website/>
     91 [fediverse]: </blog/federated-social-networking.xht>
     92 
     93 ## death to the community
     94 
     95 first of all, I never intended anime.website to form any sort of
     96 community; I intended for it to be a platform, a carrier. in hindsight,
     97 anime.website evolved into a sort of community anyway, for a few
     98 reasons.
     99 
    100 the instance utilises [Pleroma][] as its ActivityPub software
    101 implementation, which models after the older [GNU social][] with ideas
    102 such as microblogging, public timelines, and an overall feel of a
    103 twitter interface. public posts are divided into two timelines: one
    104 containing posts from users on that instance, and another which accounts
    105 for *any* public post that the server has ever come across. the
    106 instance-specific timeline has a tendency to promote a community; people
    107 use it to welcome new users to an instance, to find users that may have
    108 similar interests, and to develop a general image of what that instance
    109 consists of. I have been guilty of using the timeline as well, despite
    110 advocating for people to follow accounts they wish to keep up with,
    111 regardless of what instance they're on.
    112 
    113 in addition, I neglected to consider that the rules alone would attract
    114 or deter people from my instance. that in itself is a signal, a tribal
    115 call to assimilate people with similar values, and as such it will
    116 attract people who are usually likeminded enough to be likely to form a
    117 more-specific community.
    118 
    119 I have also modeled anime.website based on my previous experience with
    120 twitter, as well as my time on imageboards such as 4chan. the name
    121 itself is a nod to a meme on 4chan, and that alone has caused people to
    122 register because they were <q>in on the joke</q> and felt comfortable
    123 there.
    124 
    125 I made a mistake—not because I failed to discourage the formation of a
    126 community, but because I did not account for the fact that a community
    127 surrounding a platform is *inherent* in some form. going forward, I need
    128 to adjust my expectations in response to this. it's important to
    129 understand how platforms grow, how they must evolve, what their critical
    130 mass is before they begin to deteriorate.
    131 
    132 truthfully, I did enjoy the community aspect of anime.website while it
    133 lasted. I made a few friends, even developed a few relationships, and
    134 met people I otherwise would not have, had I not created the instance as
    135 I had. but, I still treat this as an experiment rather than a final
    136 product I can be happy with. the software alone has been a result of
    137 many headaches, and in general I handled administration in a haphazard
    138 manner, enough to negatively impact how I myself and others have been
    139 able to enjoy the instance.
    140 
    141 in general, some aspects of fedi and social networking tire me, so I
    142 don't know my future as far as that is involved. I do want to stay
    143 involved with fedi if I can find continued worth in it, because I have
    144 enjoyed it for a while; this year has just made it very difficult to see
    145 how useful and rewarding it *can* be, because of all the technical and
    146 social issues it currently has to face. hopefully these can be fixed,
    147 but they will take a lot of time, effort, and combined involvement. the
    148 internet, and especially social media, are still very new, and we still
    149 experience growing pains trying to adjust our interactions and
    150 expectations so that we can exist in harmony with everyone else out
    151 there. I have plenty of difficulties with this as well.
    152 
    153 I'll focus on other platforms and technologies for a while and then
    154 hopefully come back to social media with a clearer mind, to decide
    155 whether I want to pursue it and give it another shot, but this time in
    156 another direction than I took with anime.website.
    157 
    158 [Pleroma]: <https://pleroma.social/>
    159 [GNU social]: <https://gnusocial.network/>
    160 
    161 ## an end to free, open registration
    162 
    163 for a while, I have been approaching the conclusion that <q>free</q>
    164 services—open for anyone to register—are ultimately harmful both to
    165 users and to networks at large. the oft-repeated adage that <q>there is
    166 no such thing as a free lunch</q>, or simply put, <q>freedom ain't
    167 free</q>, hold true for a number of reasons.
    168 
    169 free services rely on a form of sustinence to make up for the fact that
    170 users don't pay for the services. on the corporate scale, a service may
    171 choose to enact advertising; selling of <abbr
    172 title="personally-identifiable information">PII</abbr> or other
    173 sensitive data, metadata, and analytics; tiered subscriptions or paid
    174 features; or a combination of these. sites such as pastebin and imgur
    175 follow this pattern—while they started out truly free, eventually
    176 reality set in and they had to compromise on their initial promises in
    177 order to continue service. at a smaller scale, administrators (usually
    178 hobbyists) may ask for donations or quit entirely, once they can no
    179 longer support running a free-for-all service.
    180 
    181 the issue is exacerbated by netizens who have been accustomed to free
    182 services and believe they are entitled to access. this promotes a
    183 leecher culture, as well as a growing schism between users and
    184 administrators, which results in an unhealthy dynamic akin to parents
    185 and their spoiled kids. such a dynamic cannot be well-sustained and
    186 commonly results in, yet again, admins compromising on their initial
    187 values, or burning out entirely, unwilling to continue hosting their
    188 services. users need to be reminded: you get what you pay for. for a
    189 free service, you are not owed anything in return, and you should not
    190 act like you are.
    191 
    192 aside from these issues, free services do not scale for another major
    193 reason: it is more difficult for administrators to stem abuse from
    194 their platforms, since with a free service, there is relatively little
    195 cost for registering and almost no punishment for burning through
    196 accounts (or in the case of anonymous services, virtually no cost at
    197 all). this places an increasing burden on administrators to increase
    198 their moderation by means of additional human moderators; filtering
    199 solutions such as captcha, account approval, or automated moderation; a
    200 combination of these; or even shutting off from new registrations
    201 entirely.
    202 
    203 and since the community aspect is virtually unavoidable, there is always
    204 a critical mass that, when exceeded, deteriorates the community
    205 profoundly and forces a service to drift entirely from its founding
    206 goals, caving to the new users' wishes. that is of course, unless the
    207 service decides to close off entirely, much like the consequences of the
    208 above issues.
    209 
    210 in comparison, invite-only services do away with these problems in part
    211 or in full. there is a cost associated with joining the service, whether
    212 it is monetary or social. additionally, it is expensive to lose an
    213 account due to the registration requirement. this disincentivises abuse,
    214 allowing for easier moderation. this also increases an administrator's
    215 motivation: new users are almost guaranteed to be a net addition to the
    216 community, rather than a coin toss. monetary payment guarantees that the
    217 service can be more-easily sustained financially, and social proximity
    218 allows for a better chance for admins and users to mutually benefit.
    219 
    220 invite-based services can take on a range of forms: it may be someone
    221 providing a service for a group of friends; it may require a fee or
    222 donation to join; it may be based off a preexisting community or shared
    223 interest; it may involve an invite tree such as those used by lobste.rs
    224 and private filesharing groups. all of these perform variably, but they
    225 share a common goal of vetting new users to prevent growth spurts and
    226 stem abuse.
    227 
    228 ## f2f networking
    229 
    230 closed services do not equate to centralisation; quite the opposite,
    231 since they coexist perfectly in federated networks. the network as a
    232 whole can take on a natural and efficient dynamic, where each peer can
    233 specialise in moderating their own group.
    234 
    235 with open federation, there still exists a need to trust that a
    236 network's administrators have a common goal to ensure that federation
    237 remains healthy and beneficial to all involved. this incurs a cost
    238 requirement—a barrier to entry—for the creation of a new federated
    239 service, however, which of course deters new people from deciding to
    240 self-host. currently, for any service, the barrier usually involves
    241 needing an always-on server with a public IP address, which thankfully
    242 is fairly inexpensive and accessible, but still requires a time and
    243 monetary investment, research, and ability to compare and vet various
    244 hosting providers. also, this requirement presents another issue:
    245 centralisation of hosting providers themselves. ideally, hosting from
    246 home will be a more viable solution in the future for this reason.
    247 
    248 most platforms will need a domain as well, which again can be found
    249 fairly cheaply, but individuals are prone to common traps due to the
    250 lack of public, well-curated knowledge required to select, purchase, and
    251 configure a domain. projects such as [OpenNIC][] aim to lower the
    252 barrier of entry for registering a domain and even hosting public
    253 nameservers, with the caveat that such domains are *only* accessible to
    254 other OpenNIC users. this is going to be an unacceptable solution for
    255 most people who want their platform to be as accessible as possible.
    256 
    257 additional barriers mostly depend on the type of service being hosted.
    258 for example, the hurdle to overcome for hosting a mailserver is steeper
    259 than for other services. this can partly be overcome by providing
    260 accessible documentation and tools for setting up new services.
    261 
    262 open federation sees varying degrees of success. on the optimistic end,
    263 XMPP has done very well to remain a cohesive network with few
    264 interoperability issues. they have adapted quickly to modern security
    265 standards, requiring the use of verified server-to-server TLS
    266 connections (made easier with Let's Encrypt certification) and various
    267 protocol extensions. conversely, E-mail has issues with introducing new
    268 standards, and large mail providers are reluctant to push optional
    269 features as crucial for interoperability. that, coupled with the problem
    270 with how providers handle abuse in a myriad of ways, results in a
    271 confusing landscape that is difficult to navigate without extensive
    272 research into the subject. the fediverse suffers a similar fate, but
    273 the issue is not so much about technical differences, but social
    274 expectations. almost every fediverse administrator has their own goal
    275 with federation, which often directly conflicts with the desires of
    276 other administrators. this equally leads to a schismatic, unhealthy, and
    277 inaccessible network.
    278 
    279 potentially, there is a unique approach to some of these issues:
    280 friend-to-friend networking. the option for f2f topology exists
    281 primarily in peer-to-peer filesharing such as [Freenet][] and
    282 [Retroshare][], but [anoNet][] happens to be the project I am most
    283 familiar with. anoNet is a friend-to-friend overlay network that
    284 utilises VPN technologies, and nodes peer with one another by exchanging
    285 information beforehand. access to the network is always possible if you
    286 know at least one <q>friend</q> who is willing to peer with you, which
    287 in theory raises the cost of abusing the network while at the same time
    288 preserving freedom and autonomy in the network as a whole. [dn42][] is a
    289 similar project—more mature but with a more-centralised governance,
    290 unlike anoNet's ad-hoc, entirely anarchist model. protocols such as
    291 [cjdns][] and [Yggdrasil][] have also emerged and have a similar peering
    292 model.
    293 
    294 time will tell if the f2f model ultimately prevails, but I see it as a
    295 promising middle ground between centralisation and open federation. this
    296 issue is fundamentally a social one, and at some point people will have
    297 to agree on what best fits their needs, making necessary compromises
    298 along the way.
    299 
    300 [OpenNIC]: <https://www.opennic.org/>
    301 [Freenet]: <https://freenetproject.org/>
    302 [Retroshare]: <https://retroshare.cc/>
    303 [anoNet]: <http://www.anonet.org/>
    304 [dn42]: <https://dn42.net/>
    305 [cjdns]: <https://github.com/cjdelisle/cjdns>
    306 [Yggdrasil]: <https://yggdrasil-network.github.io/>
    307 
    308 ## Postel's law
    309 
    310 be conservative in what you send and generous in what you receive.
    311 originally a principle used in the design of TCP, this equally applies
    312 to social networks in general. how well it applies has been up to
    313 debate, however.
    314 
    315 for technical protocols, the robustness principle has the benefit of
    316 tolerating implementation variations that arise from tolerances or
    317 omissions in the original protocol specification. unfortunately, this
    318 presents the risk of such deviations to be cemented into the <i
    319 lang="la">de facto</i> specification, thus limiting future
    320 implementations' freedom to deprecate such tolerances and create a
    321 stricter conformance to the protocol. this also makes way for buggier
    322 code overall, since there are more edge cases to consider.
    323 
    324 from a social standpoint—more specifically, from the standpoint of
    325 federation—this implies that individual peers are expected to play nice
    326 with the rest of a network, while at the same time tolerating issues
    327 that arise from remote peers. this results in additional overhead for
    328 administrators who wish to curate their node, as they not only have to
    329 moderate their own users' activity, but also any activity from the rest
    330 of the network, since not all admins will see eye-to-eye on what is
    331 allowed.
    332 
    333 generally, though, I believe a baseline for conduct goes hand-in-hand
    334 with Postel's law; namely, nodes and their users should follow an opt-in
    335 principle for interaction. most people have a sense of what spam
    336 entails, and they do their best to address the issue appropriately, but
    337 there is still significant nuance regarding what exactly passes for
    338 spam. in my eyes, any form of unsolicited interaction with other users
    339 is spammy and should be discouraged. this is a highly situational rule
    340 of thumb, a subjective one, but it is an unavoidable social issue that
    341 cannot be resolved by technical means alone.
    342 
    343 other than that, I adhere to a <q>live and let live</q> approach, where
    344 users on other nodes may be doing things I don't agree with, but I
    345 retain the freedom not to hear from them, and others retain their
    346 ability to interact with them at their own risk.
    347 
    348 ## administrators are not cops
    349 
    350 commonly, I see administrators who excuse the content they delete as
    351 <q>being on the safe side of the law</q>. while I understand this
    352 sentiment, and while it is entirely valid to have this concern, it is
    353 not the way things should be. many countries enact safe-harbour and
    354 neutral-carrier laws in order to *absolve responsibility* that online
    355 platforms have for their users' content, and ideally, administrators
    356 only need to comply with law enforcement requests for information or
    357 data removal.
    358 
    359 instead of desiring to push back against the pressure to do law
    360 enforcement's job, administrators unfortunately seem complacent to
    361 self-censor, thus setting a precedent toward actually being responsible
    362 for user-generated content. while laws generally allow administrators to
    363 take a best-effort approach toward curating their content, I know that
    364 U.S. law *does not require this* and there has been at least one motion
    365 to modify or repeal Section 230, which would require platforms to take a
    366 completely hands-off approach (which was common practice in the early
    367 days of the Internet) unless they want to be held responsible for user
    368 content.
    369 
    370 administrators often worry about proxied content for similar reasons,
    371 which is an important concern for federated platforms, since the
    372 majority of content will originate from remote servers and be cached
    373 locally. it is not anyone's responsibility to ensure that a huge network
    374 is clean of all illegal content, and nobody should worry about such
    375 proxied content landing on their servers. it should be dealt with at the
    376 source, punishing the user who actually posted that content.
    377 
    378 my issue with all this, is that it places more pressure on services and
    379 organisations that do not have the luxury to afford a legal team to deal
    380 with uploaded content. ideally, law enforcement exists so that the
    381 general public doesn't have to enforce the law. in addition, it is
    382 better to properly handle a situation by reporting it to law
    383 enforcement, rather than destroying evidence by deleting content or
    384 banning users immediately.
    385 
    386 people don't want to be arrested due to the actions of others, and nor
    387 do I. that much I understand. but I believe we should be working toward
    388 a way to handle this issue better, rather than censoring ourselves
    389 because we are deathly afraid of the consequences of self-hosting. this
    390 is a huge barrier for many people who want to set up a platform, since
    391 it quickly sets in that, yes, this is the Internet, and people love to
    392 abuse it.
    393 
    394 one goal I hope to achieve, is to provide administrators with affordable
    395 legal counsel in a similar manner to how the EFF handles privacy- and
    396 Internet freedom-related cases <i lang="la">pro bono</i>. hopefully this
    397 will be a way to ease people's concerns about their self-hosted
    398 platforms, encouraging hobbyists to dive right in and have fun online,
    399 rather than being worried and taxed by unnecessary responsibilities.
    400 
    401 ## summary
    402 
    403 collectively, we have a lot of work before we can reach an ideal of
    404 self-hosting, making it more accessible to newcomers and a more
    405 sustainable model on the Internet. I have had enough experience with my
    406 responsibilities and projects, and enough time to mull this over, that I
    407 am more confident in my direction going forward. I will be more focused
    408 on my own passions, and less focused on providing services that I never
    409 strongly believed in. I do not want to accomodate for people who give me
    410 little in return; I wish to pave my own road and let others follow me if
    411 they share my ambition. and I think everyone should take care to do
    412 this, so we can begin forming a healthier ecosystem—one that is driven
    413 by the community, for the community, and not controlled by corporations
    414 with ulterior interests that disalign with their userbases.
    415 
    416 while I extensively talk about federated networks, and my personal focus
    417 is on federation, I also keep an eye on peer-to-peer developments (and
    418 have a strong interest in some of them, such as BitTorrent), but p2p is
    419 *much* harder to get right, and I believe that we won't approach a
    420 pure-p2p solution for a long while. federation is a step in the right
    421 direction, with the tools we have, and it has been a longstanding
    422 cornerstone on the Internet, proving its effectiveness and relative ease
    423 to implement.