If these are too strict, I want to hear about it, but "safe against major data loss" should not be an unattainable goal...

Everyone who is hosted on masto.host, all the requirements except the first one are automatically met

@Tyrent The crux is in the screenshot already. Some extras would be: Daily backups, at least one extra person with access to the infrastructure (bus factor), and a committment to announce server closure at least 3 months in advance (no overnight disappearance)

@Gargron @Tyrent those seem like super good rules! glad you are thinking about this!

@Gargron Can’t wait to know more. If there was a good package on #yunohost I’d jump on board ASAP! Please please @aleks @bram 🙏🙏🙏🤗🤗🤗

@imacrea
#mastodon for #yunohost has been updated to 2.7.4 two days ago, 2.82 is in testing branch and will be merged in a few days.
You can jump ;)

@yalh I saw that one Yalh thank you very much but as it is not (yet?) an official package and I’m quiet a beginner with YH I’m not so sure about trying this.. :/

@imacrea
There won't be no more official packages. It has been replaced by `High Quality app` and `Featured app` https://github.com/YunoHost/Apps/#lists

@yalh Ah? this is not what I understood from the app page on YH Admin dashboard. Ok I’ll look into that, thank you!!

@imacrea @yalh I like pizza

@imacrea @aleks we aren’t in the app team you know 😅 and they are already working super hard and for free so it willb e for when someone will dedicate time to that :/ (or new volunteers joins in) @Gargron

@bram @aleks @Gargron Sorry I didn’t know ☺️ I know it’s volunteer work, I subscribed to donate on your YH Liberapay btw :) Any way to support app team maybe? 😊

@imacrea @aleks @Gargron well, a part of the app team is already in the liberapay, I don’t know if all of them are ‘-’ (I haven’t checked that much)

Thanks a lot for your support ❤️❤️❤️❤️

@imacrea @bram @aleks @Gargron oki

Hey, @hugo. Do you have any comments about the technical side of what @Gargron said for @mastohost -hosted instances, please?
Specifically, about #2 and your part about #4?

@masoud @hugo @Gargron

Both 2) and 4) are applied in Mastodon.

I have daily databases running in a remote server of everything both media and databases, It's a nightmare to run but I have it and it works (I tested it).

About four, obviously I will give time in advanced for people to move to a different hosting.

@mastohost @hugo @Gargron
Thanks for your response, this is definitely reassuring 😀
What about #3? From my part, I can (and will) find an emergency person as a substitute for my role as the instance admin. But do *you* have such person for the server infrastructure?

@mastohost @masoud @hugo @Gargron yeah

@masoud @hugo @Gargron @mastohost +1 for this. Also #3; would whatever ops team Mastohost has qualify, or is this more of in terms of instance moderation/administration?

@Gargron These are not strict at all, IMHO. It is the base line for a reasonable and reliable Mastodon instance. I like it.

@Gargron I'm not sure if "at least one other person with emergency access to server infrastructure" is possible in my case, since nobody else in my house knows how to computer

@Gargron although people who meet the requirements to join my instance (living in the same basement as me) probably don't need to find out via a website

@ben hahaha 😂

@ben Online friends? What happens if you go on vacation and have no ssh access and something bad happens on the server?

@Gargron one time the internet at my house went out for an entire week

and if I don't have SSH access, I also don't have email or phone access because all of those can be done via all of my devices.

@ben

Just my personal take on this, but home hosted devices, not because they are hosted at home, but because they are usually not properly secure (i.e. no security around 24/7) and as you mentioned no "guaranteed internet connection" (in worst case) will provide a bad experience in some cases and should rather not be added to this list.

Maybe @Gargron wants to extent the policy for that.

@Gargron
Please consider adjusting!

1) A server policy to recognize the inherent human dignity of every person.

Reason: history shows labels (e.g. homophobia) are misused, often thrown around recklessly against those of opposing political or religious beliefs.

2) through 4)

Overkill as a rule for startup and other small instances. Unenforceable. Better: require instances to *state* their policy for administration, backup and shutdown notice.

@gms But do those instances need to be listed?

@WAHa_06x36 @gms why does it need to be anything more complicated than a list of gargron and crew's "approved" instances?

1 - simply having a server policy stating XYZ doesn't mean anything unless an admin personally goes through as many posts as possible, or users actively self-police. (even "private" messages that aren't really private). but again it really doesn't mean anything just to have a public notice somewhere saying "we promise to be nice"

2 - how is Gargle supposed to verify our daily backups? do we need to install a rootkit? make a git repo of sqlite dumps? (besides part of the point of fediverse is that if an instance is temporarily down, users and posts can still circulate)

3 - again... how is this possible to vet , why is it even useful. if the primary admin is afk or in jail or whatever, nothing makes it certain that a secondary admin can put out fires. two is such an arbitrary number

4 - also again it doesnt mean anything for an admin to say "we promise to give you a 3 months heads up before we close". good admins will already do this when possible. neutral / unlucky / bad admins pull the plug when it's time to pull the plug, shrug, and move on,

good federation and resiliency doesn't just mean letting your users export/import their own following lists, it also should make it trivial for users to dump their own tweet history, this arbitrary "have 2 admins and give people a 3 months heads up, and claim you won't tolerate racism someplace" are really silly

why not have a policy against untagged NSFW and spam .... and why are only racism and sexism prohibited, why are scams or death threats or gambling not forbidden, etc etc

Gargle and friends should just make "list of our best buddies :)" and have one URL listed per line , and dump the stupid pretense of these 4 arbitrary requirements

@pox Take your personal beef elsewhere, please. I have no interest in your weird internet anger.

@WAHa_06x36 not sure why you are calling this "beef" im simply pointing out that a list of instances that the team likes doesn't need to be anything more complicated than that.

these 4 "requirements" to join literally don't mean anything -- me pointing this out is not "weird internet anger" or "personal beef" it is engaging in open discussion, which is the point of fediverse :--) just because someone has a dissenting opinion does not make them a troll or "hater" or bully, this is children's mentality

@gms It's not enforceable but it's not meant to be. If someone deliberately lies about having backups that's on them.

@Gargron @gms I like the idea of displaying it, however.

What about cllecting that criteria ina JSON and then you ust filter out the ones, you like? This way, you can still change the criteria/run tests or so.

@Gargron a server should just have good moderation policies in general, no?

@Gargron On (2), is it vital that's it's daily? My DigitalOcean droplet does weekly backups, and I'm not sure if there's an easy way for me to up that frequency.

ping @tierce and @Ilja We should work on daily backups and code of conduct, then we would be fine :)

@HgO @tierce Huh? Don't we already have both?

@Ilja Nope, there is a daily db backup, but it stays on the server, so that's not what I call a real backup. And for the CoD, it's on your todo list : https://pad.pirateparty.be/p/mastodon-welcome 😅

@tierce

@Gargron /cc @sebastian ?

@Gargron As long as you can commit the money. Iirc the terms were kind of clear on instances going down if you stop paying for the service. (?)

@Gargron But also, thanks. Good to know.

@habmala @Gargron
Not saying they do this, but imo the best option here would be to make instances read-only if unpaid, with deletion after 90/120 days. Gives everyone a chance to download their archives.

@Gargron I noticed open registrations is not on that list. In the past, social.coop hasn't been eligible for joinmastodon.org because we have a sign up process. Am I understanding correctly that is no longer a barrier?

@datatitian I can put you in the database but to *show up* registration must be possible. Approval-mode is acceptable. I don't know if that would work for your coop.

@Gargron oh awesome I think that approval mode serves exactly what we were trying to do with our registration process.

@Gargron I think it's also the case for the instances hosted on your infrastructure @CobaltVelvet?

@Sylvhem @gargron 2 and 3 yes, 1 depends on the instance of course (i'm pretty sure all those i host do), 4 is a goal and pretty stable for now but i can't guarantee in extreme events

@CobaltVelvet Thank you :).

@Gargron

@gargron the fourth one?

@Gargron How about instances running on VPSs or DO?

@Gargron

As for number 2, would server replication count?

Hackers.town is replicating to two other hosts, one offsite.

@TheGibson @gargron ehhhh i'd say replication isn't backup as much as raid isn't backup. do you have something in case ie someone gets to empty the database (or the replications replicates a failure, or the replication fucks up)

the main feature i see in backups is "at least one point in time that you know worked"

@CobaltVelvet @Gargron

Fair.

I keep the offsite on a 24 hour differential for this reason.

I'll look into setting a backup script in place this week then.

@TheGibson @gargron ye unless you can't react in 24h that would do the job. daily read-only backups to an external servers are what i'd recommend (i'm currently satisfied with borg and borgbase)

@CobaltVelvet @Gargron

Sure, easy enough to do... current arrangement has worked well for us so far... but can't hurt to back it up too.

@Gargron @mdbraber you should sign up the mastodon.nl instance.