This is, in my opinion, the most severe problem with the Fediverse.

- The fediverse is almost optimized for tricking people into starting instances without realizing how the resource/moderation burden will scale as it grows

- The fediverse therefore makes the single chief operators of a server a single point of failure

- Offers those operators no options for dealing with overextension/burnout/cost growth other than shutting down

- And offers the users no facility for saving either their usernames or their post histories when the shutdown inevitably happens

@mcc a sentiment I see on fedi is "posts are impermanent, just wipe them" and I couldn't disagree more. why would I bother to make posts that are worthless

@mcc Proposal: the Mastodon server software should, by default, have a fundraising thermometer at the top, with notches at "shoestring sustainable" and "ramen profitable" milestones. Admins should be required to configure this to get it to boot.

You can operate an instance that is below minimum expenses-covered sustainability but, by default, it should add a 10ms delay to every post for every cent below that threshold.

Ironically this would probably not help botsin.space *specifically*.

@whitequark It depends on the usecase. Is this a publishing system or a chat system (yes, I know one of your major projects is persistent logging for chat systems but I haven't been awake long enough to frame this better)

@glyph I think my argument would be that the documentation for the mastodon admin interface should begin with instructions on how to start a co-op

Like, fundraising is only one problem. The problem is the trust relationship is with one operator. If more instances were run by organizations, like mastodon.social, there would be continuity AND the ability to rotate staff

I dunno, maybe this would be a good @evan project. Create a co-op-in-a-box "restructure your instance as an org" package.

@glyph @evan Like if that were the standard way of organizing instances we'd still have the normal nonprofit problem of Evil Boardmembers taking the thing over and doing something bad, but this only increases the value of a set of best practices and instructions for how to organize a cooperative instance governing body with representation from the users. (Then the big threat just becomes cliques, and instances have this problem already.)

@whitequark Posts are not worthless, they are just not meant to last for eternity. If you want something to endure with time, write it down, long form. elsewhere.

Words should be able to be lost on the wind, and conversations should be allowed to expire. to let you be unburdened of the past, and let the things it held, be free once more.

If something specific needs to be preserved, it should be treated differently, as the exception, not the rule.

@zanagb @mcc do you feel the same way about your memory? because dissociative amnesia means, for me, that posts are the only memory I'll have for much of my life.

I *hate* people who assert that my memory should expire.

@mcc @evan Also an excellent idea. Ultimately the problems of cliquishness and governance takeovers bottom out on the hard ground of "we live in a society" and I think we could be leaps and bounds ahead of where we are if we at *least* tried to extremely uncreatively copy the state of the art in basic small-organization governance rather than attempt to poorly speedrun 1000 years of the history of the development of administrative technologies

@glyph @mcc @evan

Speaking as someone arguably in the middle of that speedrun, this is compounded by the technical slant to many (most?) Fediverse communities.

I strongly suspect that, on the median admin team, there is a lot more expertise in, e.g., running Postgres than in small-organization governance. And that carries over to the types of guides that are written up and general advice.

@mcc the last point seems key: "user A used to be on server X, but that server is gone, and if you try to look those posts up you will find their new home on server Y" needs to be a feature if we're serious about this lasting long term.

@MrCheeze this is a feature… until server X goes down. But server X going down is exactly what we are afraid of

@mcc @MrCheeze I'm pretty sure there are people today running ActivityPub profiles on redundant servers or using distributed identities, but I have yet to understand how that works for post availability and retention, like how I would know where to go to read their stuff if the place I know them from is gone.

@julian @MrCheeze I don't think there's a systematic infrastructure for it. Bluesky on the other hand is built around a systematic architecture for that exact thing (although as I mentioned it has other decisions I don't like)

@mcc @MrCheeze Define systematic infrastructure? Mitra exists as a practical implementation compatible with Mastodon, and it implements https://codeberg.org/silverpill/feps/src/branch/main/c390/fep-c390.md and https://codeberg.org/silverpill/feps/src/branch/main/ae97/fep-ae97.md. So you can divorce your identity from your AP instance today if you like. I just don't fully understand what that gets us.

If you decide to take your Bluesky PDS down, does their relay keep serving cached copies of your posts forever? Is that a good thing, do we want that?

@mcc @whitequark would a service that subscribes to your posts and writes them out to an archive automatically (private, or public and indexable) be interesting for the permanence of posts concern? This seems relatively doable.

@julian @mcc @MrCheeze

>Mitra exists as a practical implementation compatible with Mastodon, and it implements...

The main specification is FEP-ef61, which describes how decentralized ("nomadic") identity works. FEP-c390 is an older idea and it doesn't provide full data portability. FEP-ae97 is about combining FEP-ef61 with ActivityPub Client-to-server API.

>I just don't fully understand what that gets us.

You can clone your account to multiple servers, and those multiple accounts would work as one! And more: peer to peer, local-first applications.
Mitra's implementation is actually incomplete, I recommend also checking out Streams, which supports FEP-ef61 and non-ActivityPub nomadic identity (Nomad protocol; this is where the "nomadic identity" comes from).

@silverpill Thanks, that helps me a bit. So I'd set up my client to send the posts I write to all of my multiple servers, and if one of them goes down I'm still reachable on the others with all my stuff? And the idea is that people who reply to me send their replies to all of my servers, or do my servers synchronize themselves on their own?

Maybe I just need to read up on this more...

@mcc @MrCheeze

@silverpill @mcc @julian @MrCheeze Sorry if this is not a right place to ask. I'm interested in FEP-ed61 but I'm stuck at Webfinger and gateways. What if a user only knows a webfinger handle [email protected] but a gateway example.com is dead? The Webfinger section of FEP-ef61 reads like you somehow know the actor's gateway before you look up the actor.

@julian I think servers should synchronize data between themselves, but the other approach where clients write to multiple servers (as they do in Nostr) is also fine

@mcc @MrCheeze