4 ms·

Federated networks like Mastodon and Lemmy are going to get people well-acquainted with websites shutting down. It's hard work (time, money, etc.) to run these

Federated networks like Mastodon and Lemmy are going to get people well-acquainted with websites shutting down. It's hard work (time, money, etc.) to run these things for people, and people start to really lean on them. It's almost novel now days getting sucked into something that shuts down. killedbygoogle.com is a meme partly I think because websites shutting down is just so uncommon in areas that we get personally invested in. I run my own Lemmy instance just for my self and even that can be trying sometimes. I enjoy using it instead of reddit, but one day I will probably shut it down and be sad.

hifikuno 2y ago
I, too, ran my own instance. I enjoyed it for some time but I've now moved to the omg.lol ecosystem. I feel that by paying a little money for it that I have a higher chance of the server not shutting down.
- joeross 2y ago
  +1 for omg.lol, it’s a great community.
OgsyedIE 2y ago
Besides the monetary costs of operating small fora there are also significant competence hurdles. Site owners who manage to hit a couple thousand users have to figure out spam handling, automated content moderation (including photoDNA and the required reporting if they host images), registering a DMCA agent with the copyright office, setting up an LLC, assessing their needs for COPPA, GDPR and CCPA, their site's tax situation and anything they may want to do involving employing others (such as T&S) without getting burnt out. The median size for a forum getting its first subpoena is 4,300 users. Managing all of that is easily learnable in a couple months if they have time, disposable income and few distractions but surprisingly few people who have site management thrust upon them know about these things in advance. To most people who think about running an internet anything the above are unknown unknowns. You can't go looking for things you don't know exist, so burnout is high.
- kstrauser 2y ago
  Citation highly needed. I'm close to quite a few people who run larger instances than that, including my own, and none of them have ever told me about getting subpoenaed. That's exactly the kind of war story we'd tell each other, too. I've seen no evidence that running a fediverse server is nearly so legally fraught.
  - OgsyedIE 2y ago
    I'll go looking for the citation and it may take a couple hours but I'll point out that FWIW my info is drawn from some academic surveying vBulletin and Xenforo site owners in the 2010s so I wouldn't be surprised if they aren't applicable anymore.
    - OgsyedIE 2y ago
      Update: My apologies. I've totally confabulated old blog posts from Antone Johnson with TSPA articles and some Steven Myers papers. The actual figure is a median of 1 subpoena per annum per 430k users if the majority of the users are under 30.
      - kstrauser 2y ago
        No problem. I thought that seemed on the high side but didn’t have any stats to counter with. Which paper does 430k come from? I’d like to squirrel that away for later.
    - immibis 2y ago
      Note that getting a subpoena isn't "legally fraught". You're being called on to assist in an investigation of someone else, not in trouble yourself.
      - deleted 2y ago
        [deleted]
jchw 2y ago
I'm starting to think nostr was barking up the right tree after all. Put as much complexity into the client as possible and make the servers dumb and completely uncoordinated, utterly interchangeable. Spam your broadcasts to any relay that will listen. No idea if it actually works (I've read a lot about nostr and AT proto but never used either of them) but I think it's very obvious that any system that deeply relies on some company that everyone becomes extremely reliant on (including AT proto/Bluesky) is only a couple steps away from the same sort of problems as centralization. Of course, the real gold standard would be P2P, if only it could work. But... mobile phones can't burn battery running P2P clients in the background, everyone's under a NAT these days, and some types of software (like microblogging networks) would be horrifically intractable as a P2P system. Oh well. At the very least, I really love the concept of Decentralized Identifiers (DIDs). I'd like to see more stuff like that.
- pfraze 2y ago
  The atproto team came from the p2p space. We had a lot of experience running client-side computation. There are challenges you can try to solve in that design -- key sync, key recovery, reliable hosting, reliable discovery, etc -- but what you can't get around is the need to run queries against aggregations of data. Even scales that we consider "mid" start to strain on the client-driven model. Federated queries might be able to solve it, but it's extremely challenging to get reliable performance out of that. The design we landed on was replaceable big nodes. The common comparable people raise is email/gmail, but we used the DID system and account portability to try to get a better outcome on provider migration. It's hopefully more like web/google -- which still has the centralizing pressures of scale benefits, but hopefully injects enough fluidity in the system to move the situation forward. Sometimes, you pick the design that moves the ball down the field, not the one that guarantees a touchdown. If somebody wanted to improve on what we've done, I'd tell them to focus on the federated queries problem.
  - jchw 2y ago
    In theory AT proto doesn't seem like a bad design. I've read a fair bit of the docs, although mostly skimming. (I've been meaning to read the paper on Merkle Search Trees so I can figure out what exactly is going on with PDSes.) On the other hand, in practice it seems like the AT proto infrastructure is still very centralized for now. DIDs are excellent in theory, but everyone is using PLC DIDs, which depends on the centralized plc.directory. You can run your own PDSes, but there's only one relay for now (that I am aware of.) I also don't think there is more than one instance of the Bluesky AppView, and the official instance is locked into the Bluesky Moderation Service, which seems to limit the usefulness of some of the censorship resistance of the protocol. I'm not sure how much of that is social problems rather than technical, but I worry that since Bluesky and AT proto are gaining massive popularity with this status quo (millions of users!) it'll have a problem akin to Matrix.org, where in practice almost everyone is using the same infrastructure anyways. It's still relatively early days, but millions of people is definitely enough to where you start to hit problems with having everyone under one roof. I really hope we get to see how things play out when more of the network is operated independently.
qudat 2y ago
ActivityPub seems to require a lot of hardware resources in order to run properly, which is unfortunate. It’s not something I would ever want to run myself, especially to the public.
- rtpg 2y ago
  I wonder how much of that is endemic to ActivityPub or how much is about the software stack itself I don’t mean to be glib, just wondering if things can be “done better”
  - qudat 2y ago
    I'm guessing the syncing process between instances is really brutal on resources. Imagine constantly syncing external databases for your service to function properly.
    - rtpg 2y ago
      I thought AP was push-based though? Might be wrong of course, and I think stuff like media is its own thing
    - jeroenhd 2y ago
      AP is push based (which actually causes the "every instance has its own set of comments" problem). You can run pullers on a small instance to get a better experience if the remote sides support listing posts, but the standard sync process is no more than receiving HTTPS calls and storing the JSON contents in the right place. There's some additional overhead (doing HTTPS calls for verifying signatures, for instance) but that information can be cached pretty effectively. Pushing contents is no more than posting HTTPS calls to every server in your follow lists, and possibly exposing said content in a GET API for pullers, though that's entirely optional. Mastodon is heavy because of the way the backend is written (I blame Ruby on Rails for tha one), but there are fully featured ActivityPub servers out there that are orders of magnitude more efficient. Mastodon devs prefer the ease of development over performance but that's a choice, not an inherent problem of ActivityPub.
- 2y ago
mschuster91 2y ago
> Federated networks like Mastodon and Lemmy are going to get people well-acquainted with websites shutting down. It's hard work (time, money, etc.) to run these things for people, and people start to really lean on them. Mastodon is filled with such utterly basic UX issues. You move instances because the old one announces a shutdown? No old posts visible, no import possible. You want to see the history of an old account on another instance? The oldest toot you'll see is the first one that your instance picked up from that account. You have to switch to their instance to see old toots - there's a helpful link at the end of the feed, but it's still annoying. "Trending" topics only carry stuff happening on your server, and most of it is days old garbage. Search is horribly broken and inconsistent.
- zimpenfish 2y ago
  > You move instances because the old one announces a shutdown? No old posts visible, no import possible. But this isn't "utterly basic" to solve on the backend due to how ActivityPub (currently) works. First you have to allow backdated posts[0] (not supported in the spec) which requires a mechanism to stop them being sent out (else they'll appear in current timelines[0]) but also you need a mechanism to send them out (to update the old URLs except how does the new instance know where the old instance sent the status? And how do you prove that you have the right to even request the change?) These are probably not insurmountable but they do require a lot of thinking about! [0] I ran into these importing an old Twitter bot into my Akkoma instance. I had to modify the server code and it was not a fun time.
  - mschuster91 2y ago
    > But this isn't "utterly basic" to solve on the backend due to how ActivityPub (currently) works. They're basic for the user. I know a few people who left Mastodon for good after the second or third time they had to shift servers. That kind of stuff should have been thought of from the beginning... > to update the old URLs except how does the new instance know where the old instance sent the status? And how do you prove that you have the right to even request the change? The same way an account move is currently reported to the instances where followers reside and handled there - the account-move operation would only need to do a full re-scan of the old profile. That's a ton of traffic for people with followers from many instances, I agree, but the source instance could trigger the creation of something like a data dump that destination instances can download without hitting the API.
deleted 2y ago
[deleted]
happosai 2y ago
Eh, it's not new to federated sites. Many of the web sites I frequented a decade a go are dead. Or enshittified useless so I visit them rarely anymore. It was sad to see say, the "user friendly" webcomic go away. But I enjoyd it in the time. Just live the moment. Don't expect even the big websites and apps of today to last - not at least in the form you enjoy.
immibis 2y ago
https://wiki.archiveteam.org/index.php/Deathwatch https://wiki.archiveteam.org/index.php/Deathwatch

hifikuno 2y ago

I, too, ran my own instance. I enjoyed it for some time but I've now moved to the omg.lol ecosystem. I feel that by paying a little money for it that I have a higher chance of the server not shutting down.

joeross 2y ago
+1 for omg.lol, it’s a great community.

OgsyedIE 2y ago

Besides the monetary costs of operating small fora there are also significant competence hurdles. Site owners who manage to hit a couple thousand users have to figure out spam handling, automated content moderation (including photoDNA and the required reporting if they host images), registering a DMCA agent with the copyright office, setting up an LLC, assessing their needs for COPPA, GDPR and CCPA, their site's tax situation and anything they may want to do involving employing others (such as T&S) without getting burnt out. The median size for a forum getting its first subpoena is 4,300 users. Managing all of that is easily learnable in a couple months if they have time, disposable income and few distractions but surprisingly few people who have site management thrust upon them know about these things in advance. To most people who think about running an internet anything the above are unknown unknowns. You can't go looking for things you don't know exist, so burnout is high.

kstrauser 2y ago
Citation highly needed. I'm close to quite a few people who run larger instances than that, including my own, and none of them have ever told me about getting subpoenaed. That's exactly the kind of war story we'd tell each other, too. I've seen no evidence that running a fediverse server is nearly so legally fraught.
- OgsyedIE 2y ago
  I'll go looking for the citation and it may take a couple hours but I'll point out that FWIW my info is drawn from some academic surveying vBulletin and Xenforo site owners in the 2010s so I wouldn't be surprised if they aren't applicable anymore.
  - OgsyedIE 2y ago
    Update: My apologies. I've totally confabulated old blog posts from Antone Johnson with TSPA articles and some Steven Myers papers. The actual figure is a median of 1 subpoena per annum per 430k users if the majority of the users are under 30.
    - kstrauser 2y ago
      No problem. I thought that seemed on the high side but didn’t have any stats to counter with. Which paper does 430k come from? I’d like to squirrel that away for later.
  - immibis 2y ago
    Note that getting a subpoena isn't "legally fraught". You're being called on to assist in an investigation of someone else, not in trouble yourself.
    - deleted 2y ago
      [deleted]

jchw 2y ago

I'm starting to think nostr was barking up the right tree after all. Put as much complexity into the client as possible and make the servers dumb and completely uncoordinated, utterly interchangeable. Spam your broadcasts to any relay that will listen. No idea if it actually works (I've read a lot about nostr and AT proto but never used either of them) but I think it's very obvious that any system that deeply relies on some company that everyone becomes extremely reliant on (including AT proto/Bluesky) is only a couple steps away from the same sort of problems as centralization. Of course, the real gold standard would be P2P, if only it could work. But... mobile phones can't burn battery running P2P clients in the background, everyone's under a NAT these days, and some types of software (like microblogging networks) would be horrifically intractable as a P2P system. Oh well. At the very least, I really love the concept of Decentralized Identifiers (DIDs). I'd like to see more stuff like that.

pfraze 2y ago
The atproto team came from the p2p space. We had a lot of experience running client-side computation. There are challenges you can try to solve in that design -- key sync, key recovery, reliable hosting, reliable discovery, etc -- but what you can't get around is the need to run queries against aggregations of data. Even scales that we consider "mid" start to strain on the client-driven model. Federated queries might be able to solve it, but it's extremely challenging to get reliable performance out of that. The design we landed on was replaceable big nodes. The common comparable people raise is email/gmail, but we used the DID system and account portability to try to get a better outcome on provider migration. It's hopefully more like web/google -- which still has the centralizing pressures of scale benefits, but hopefully injects enough fluidity in the system to move the situation forward. Sometimes, you pick the design that moves the ball down the field, not the one that guarantees a touchdown. If somebody wanted to improve on what we've done, I'd tell them to focus on the federated queries problem.
- jchw 2y ago
  In theory AT proto doesn't seem like a bad design. I've read a fair bit of the docs, although mostly skimming. (I've been meaning to read the paper on Merkle Search Trees so I can figure out what exactly is going on with PDSes.) On the other hand, in practice it seems like the AT proto infrastructure is still very centralized for now. DIDs are excellent in theory, but everyone is using PLC DIDs, which depends on the centralized plc.directory. You can run your own PDSes, but there's only one relay for now (that I am aware of.) I also don't think there is more than one instance of the Bluesky AppView, and the official instance is locked into the Bluesky Moderation Service, which seems to limit the usefulness of some of the censorship resistance of the protocol. I'm not sure how much of that is social problems rather than technical, but I worry that since Bluesky and AT proto are gaining massive popularity with this status quo (millions of users!) it'll have a problem akin to Matrix.org, where in practice almost everyone is using the same infrastructure anyways. It's still relatively early days, but millions of people is definitely enough to where you start to hit problems with having everyone under one roof. I really hope we get to see how things play out when more of the network is operated independently.

qudat 2y ago

ActivityPub seems to require a lot of hardware resources in order to run properly, which is unfortunate. It’s not something I would ever want to run myself, especially to the public.

rtpg 2y ago
I wonder how much of that is endemic to ActivityPub or how much is about the software stack itself I don’t mean to be glib, just wondering if things can be “done better”
- qudat 2y ago
  I'm guessing the syncing process between instances is really brutal on resources. Imagine constantly syncing external databases for your service to function properly.
  - rtpg 2y ago
    I thought AP was push-based though? Might be wrong of course, and I think stuff like media is its own thing
  - jeroenhd 2y ago
    AP is push based (which actually causes the "every instance has its own set of comments" problem). You can run pullers on a small instance to get a better experience if the remote sides support listing posts, but the standard sync process is no more than receiving HTTPS calls and storing the JSON contents in the right place. There's some additional overhead (doing HTTPS calls for verifying signatures, for instance) but that information can be cached pretty effectively. Pushing contents is no more than posting HTTPS calls to every server in your follow lists, and possibly exposing said content in a GET API for pullers, though that's entirely optional. Mastodon is heavy because of the way the backend is written (I blame Ruby on Rails for tha one), but there are fully featured ActivityPub servers out there that are orders of magnitude more efficient. Mastodon devs prefer the ease of development over performance but that's a choice, not an inherent problem of ActivityPub.
2y ago

mschuster91 2y ago

> Federated networks like Mastodon and Lemmy are going to get people well-acquainted with websites shutting down. It's hard work (time, money, etc.) to run these things for people, and people start to really lean on them. Mastodon is filled with such utterly basic UX issues. You move instances because the old one announces a shutdown? No old posts visible, no import possible. You want to see the history of an old account on another instance? The oldest toot you'll see is the first one that your instance picked up from that account. You have to switch to their instance to see old toots - there's a helpful link at the end of the feed, but it's still annoying. "Trending" topics only carry stuff happening on your server, and most of it is days old garbage. Search is horribly broken and inconsistent.

zimpenfish 2y ago
> You move instances because the old one announces a shutdown? No old posts visible, no import possible. But this isn't "utterly basic" to solve on the backend due to how ActivityPub (currently) works. First you have to allow backdated posts[0] (not supported in the spec) which requires a mechanism to stop them being sent out (else they'll appear in current timelines[0]) but also you need a mechanism to send them out (to update the old URLs except how does the new instance know where the old instance sent the status? And how do you prove that you have the right to even request the change?) These are probably not insurmountable but they do require a lot of thinking about! [0] I ran into these importing an old Twitter bot into my Akkoma instance. I had to modify the server code and it was not a fun time.
- mschuster91 2y ago
  > But this isn't "utterly basic" to solve on the backend due to how ActivityPub (currently) works. They're basic for the user. I know a few people who left Mastodon for good after the second or third time they had to shift servers. That kind of stuff should have been thought of from the beginning... > to update the old URLs except how does the new instance know where the old instance sent the status? And how do you prove that you have the right to even request the change? The same way an account move is currently reported to the instances where followers reside and handled there - the account-move operation would only need to do a full re-scan of the old profile. That's a ton of traffic for people with followers from many instances, I agree, but the source instance could trigger the creation of something like a data dump that destination instances can download without hitting the API.

deleted 2y ago

[deleted]

happosai 2y ago

Eh, it's not new to federated sites. Many of the web sites I frequented a decade a go are dead. Or enshittified useless so I visit them rarely anymore. It was sad to see say, the "user friendly" webcomic go away. But I enjoyd it in the time. Just live the moment. Don't expect even the big websites and apps of today to last - not at least in the form you enjoy.

immibis 2y ago

https://wiki.archiveteam.org/index.php/Deathwatch https://wiki.archiveteam.org/index.php/Deathwatch