Follow

You don't need to use other people's servers on Mastodon or the Fediverse. Anyone can set up their own server, even non-technical people. It's much easier than you think, and much cheaper too.

I run a website helping non-technical people create their own servers at growyourown.services and you can follow its account at @homegrown

There are many Fediverse server types you can set up without tech knowledge:

growyourown.services/grow-your

There's also an in-depth tutorial about making your own Mastodon server without tech knowledge, and most of it applies to any kind of Fediverse server:

growyourown.services/making-yo

@feditips @homegrown

That actually explains selfhosting and the diverse reasons for it very nicely.

Bookmarked as supplementary when somebody asks "But why?!" next time. 😅

@feditips @homegrown this is awesome! Besides using hosted providers, do you have tips for self-hosting maintenance in general? I always wanted to selfhost but terrified of the security and maintenance aspect.

@roq @feditips

Do you mean doing the techy stuff yourself instead of using a managed hosting service?

I've tried to skip those topics as there are already other sites doing that. (No one was covering managed hosting, that's why I started GYOS.)

The Related section on GYOS might be a good starting point? There are a number of projects trying to make it easier to install and maintain stuff yourself without using managed hosting:

growyourown.services/related-p

@roq @feditips I self host. If you don’t allow any other users than there is no moderation burden. It helps to have the technical admin skills, but I’d say mine are pretty minimal. I just self host a few other services and learned that way. You can also start on a raspberry pi and keep it small to get started. Just go for it.
For security: compartmentalize. Do not have anything critical on the host. Do not store financial or personal data on your app server. Harden the instance and host machine to a reasonable be degree (strong password for any apps, only allow private key access for the actual box, etc.)

For maintenance: Familiarize yourself with the update procedures for any services (if you can Dockerize them, so much the better) and the backup and restore options for the host. It would be nice if you can run a whole TEST environment but let's be honest, we're just throwing stuff into PROD and hoping it doesn't break too bad.

@feditips @homegrown As I can see this site ignores the elephant (or mastodon) in the room that particularly bothers me at the moment - that is how to comply with various regulation while self-hosting. A guide like "GDPR for Fediverse maintainers" would be much appreciated.

@Oytis @homegrown

Unfortunately I am not a lawyer, I am not allowed to give legal advice.

I've tried to mention this in the article, but there's really not much I can say beyond consulting an expert if you are unsure about a point of law.

I am not ignoring it, it is addressed, but free websites made by non-experts are usually not the best place to get legal advice.

@feditips @homegrown Yes, it absolutely makes sense not giving legal advice not being a lawyer. I was more addressing a point (before reading the whole article indeed) that anyone can bring up their own server. Technically, yes, but legally it's a minefield, reliable legal advice is much less available than technical one, and the risks are much higher than if one fails the technical part. I really wish it could be fixed somehow though.

@Oytis @homegrown

"reliable legal advice is much less available than technical one"

As far as I know, growyourown.services is the only site giving advice to people who want to run their own online services without doing techy stuff. I set it up because I couldn't find anyone else covering this topic, all the other sites were techy.

My take on legal issues is this (and this is on the site too):

If you want to run your own server just for yourself, that's the simplest and easiest option. No one else's personal data to worry about.

If you want to run it for your friends/family/colleagues it's a bit trickier, depending on how well you know each other.

If you want to run a server for strangers as a public service, you need to take things more seriously, including reading relevant laws and consulting an expert if needed.

This is true for anyone who deals with the public, whether online or offline. I volunteer offline and had to go through a course about relevant laws, for example.

Hi @Oytis , my experience is that most federated projects, especially social ones, were built with the mission of taking control of your information so normally they take privacy concerns very seriously. It could be said they're GDPR compliant by default. If they're not, an issue can be raised on their respective issue trackers and services can be taken online if they're not satisfactory.

If you're planning to provide a service, research the project before committing and find out how other service providers deal with GDPR. Every project deals differently with data so there's no one-size-fits-all solution, some legwork is reguired.
If you plan on self-hosting just for yourself, there's much less work required. You are your own data holder, you can do as you see fit unless you keep someone else's data.

A service hoster can take several steps to be fully compliant. There are some basic rules based on some experience I had over the years:

1) There's a distinction between essential and non-essential information. Error logs can be kept if they provide a useful service and aren't shared with anyone but yourself. Access logs are normally optional unless you care very much for continuous optimization.
Keeping non-essencial logs (i.e. track user's activity) can provide benefits for your service, but ensure you at least know how to delete them on request. I normally don't save apache/nginx access logs since they're not worth the effort.

2) Search for cookie information for a specific project, either by compiling a list of cookies by hand using browser extensions and following the pipeline from registration to first activity, or asking the developers on their main issue tracker for any essential and non-essential cookies, as well as their purpose. If developers can't answer it, jump ship. If there are non-essential cookies that can't be disabled, my main advice is to set up a cookie consent popup. There are some popup generators on the web, you can google them if you wish

3) Try to find out how user's data can be deleted, mainly if the user can delete their account in their preferences or if you can do it for them. They are not required by law to log in to delete their account.

4) Have a privacy policy link clearly visible in every page. A Privacy Policy should have at minimum the identification of the data holder (not real-life information, mind you) and a point of contact, normally an email, where someone can reach you to ask for their information to be deleted. A list of every essential and non-essential cookie would be great. Cookie consent popups are good but you can't fully rely on them

5) The law is usually lenient with best-effort cases, at least in Europe, but country laws might apply. You should not be worried if you do what you can to protect your user's data and ensure they always have a simple way to confirm who owns their their data, where it goes and how to request its deletion. You normally have some days to implement changes whenever you receive a GDPR notification.

6) Find the country your server is set up on and find a lawyer who specializes in data protection beforehand. You don't need to initiate contact but it's always good to know where to go if trolls try to sue you

Hope I helped clear some doubts and didn't bore you midway. I'm not a lawyer but I've handled some cases and had training regarding data protection.

@marcos @feditips @homegrown Thank you for your excellent summary, Marcos!

I wasn't going to host for other users at least for now, but still worrying about likes, follows, comments and like. I believe I just need to read the whole thing (GDPR that is) one moment before bringing up the server.

No need to keep up with GDPR for personal projects since the whole data protection enforcement isn't proactive. It's too much work for authorities to take action due to how opaque the whole process is and normally if you don't mess with shops there's nothing to worry about, at least until the 100 users mark. If it doesn't bring any personal profit or doesn't promote scams it's not even worth the effort to look deeper.

Your idea might bring many benefits to the ecosystem so it would be very sad to see you get concerned and abandon your idea due to something so opaque and hardly enforced. Nothing to worry about if you treat the data with respect.
Sign in to participate in the conversation
Mastodon 🐘

A general-purpose Mastodon server with a 1000 character limit.

Support us on Ko-Fi Support us on Patreon Support us via PayPal