A few suggestions for MastoHost
[Hugo Gameiro, admin of MastoHost, invited isolateByoblu for suggestions about MastoHost Terms of Service, which recently changed. We propose our suggestions here too, with the aim to open a discussion among MastoHost users and the broader fediverse inhabitants. We agreed not to publish the current post on isolateByoblu blog [i] since the SocialByoblu instance shut down [ii] and we look forward to broading the scope of our analyses beyond the fediverse.]
«[...] MastoHost Terms of Service [ToS] has made a leap forward since [their recent update],  and de‑platforming Byoblu  contributed to make the fediverse a better place. We hope you do not mind if we are late to suggest the following points as improvements for the ToS.
1. We collected the information [about Byoblu] along our six‑month long (at that time) initiative in the fediverse, but we knew from the very beginning SocialByoblu was against MastoHost terms of service. Yet, we found too late that MastoHost hosted SocialByoblu, and our lack of knowledge prevented us to take action in better time. Instance policies should contain a reference that the given instance is hosted by MastoHost, and that the instance complies to MastoHost ToS. That is, in turn, similar to what you write in the ToS about OVH. To us, it is a small measure with a significant impact. [adde: see P.S.]
2. The utmost part of the Italophone fediverse de‑federated SocialByoblu on sight. However, it happened that toots from the blocking instance arrived to the blocked one. To us, that was inexplicable until we realized that one instance in particular – the predatory MastodonUno run by the owner of a web 2.0 company [adde: link is mine], which by chance is also hosted by you – still federated SocialByoblu. Our humble technical understanding is that toots are somehow copied when they are boosted. In a three‑instance case scenario where one instance is blocking another and a third instance federates with both, an account in the middle instance and followed by any account of the blocked instance can boost a toot in the blocking instance making it visible to the blocked one. The phenomenon might not be new for you. Anyway, we link to our isolateByoblu FAQ with a self‑explanatory picture.  One could argue that public toots are public, hence one cannot expect safety (ActivityPub is flawed in that regard) if the cordon sanitaire around the de‑federated instance is not observed by every previously‑federating instance. Nevertheless, we deem there is a huge difference between I)one logs out on purpose and directly reads public toots on the blocking instance, and II)all the accounts of the blocked instance automatically receive the boosted toot directly in their home or federated timeline. In the second case, people's toots are exposed against the timeline of the whole user base on the blocked instance, and that draws a much greater number of unsolicited attentions than the first case. Also, the de‑federation might mislead a safety self‑assessment, where perception is the key. Since a technical solution to this problem is yet to come, we suggest to broaden the unacceptable content proviso towards the pods federated by your guest instances. That way, one could expect the users of the guest instance will stay alert. A non‑compulsory block list might be shared among guest instances as an extra‑policy solution.
3. We finally bring to your attention two cases which might lead to further clarify the unacceptable contents in the ToS. 3a. We are writing an article about a Byoblu guest claiming that UN steers an “homosexual agenda”  against the “traditional [heterosexual] family”. Her lines of argument roughly follows the ones contained in the Russian federal law “for the Purpose of Protecting Children from Information Advocating for a Denial of Traditional Family Values”, a.k.a. the “gay propaganda law”.  The Byoblu guest plays the victim card, arguing that the “myth of the oppressed minority” (!) serves as hegemonic tactics to impose a fringe point of view to the whole society. In a way, the guest claims there exists a “reverse discrimination”  against heterosexual families. We found similar thinking by masculist (MRA) pods about “sexism against men”. In light of these examples, how is the “reverse discrimination” considered according to MastoHost ToS? 3b. The debate about “conspiracy theories” is open. We would like to point out that conspiracies have always existed. Here two articles of anti‑conspiracist media: a liberal‑leaning point of view  and an extra‑parliamentary left‑wing one.  In particular, the latter distinguishes “factually substantiated conspiracy theories” – i.e. theories about actual conspiracies – from “conspiracy speculation” or “conspiracy fantasy”. Therefore, is MastoHost against any conspiracy theory or just the unsubstantiated one? (i.e. conspiracy fantasies)
We would really like to read your opinion about our feedback. Take care, isolateByoblu – 19th May 2021»
P.S.: Gameiro noted that «it would be good practice for admins to disclose where they host their servers [but] some admins may have privacy or security valid reasons to not want to disclose that information». We consider this a strong argument against making disclosure compulsory as per ToS. However, if people experience unacceptable contents by a guest service (admins, mods, or users), the host and the people will act as if there exists no hosting ToS at all since: people do not know who hosts the guest instance (and that the instance shall comply to the hosting ToS); and the host does not know about the content. They can only report to the instance admin, but what if that admin is complicit in the unacceptable content? Or the admin themself promotes contents/gatherings around the unacceptable topics? Instead of a compulsory visibility of MastoHost ToS, a moral suasion could put the safety and the privacy together. Something along the following line: «I invite you to make visible in your instance policy that the MastoHost terms of service hold too. If any issue about MastoHost visibility on your policy arises, then you are encouraged to reach me privately. I will keep the communication with strict confidentiality». This way, the privacy/security reasons are kept confidential or even unknown by the host. At the same time, the host knows anybody will make more efforts to report ToS violations for the given guest instance.