Reader

[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], [0] and de‑platforming Byoblu [1] 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. [2] 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” [3] 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”. [4] 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” [5] 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 [6] and an extra‑parliamentary left‑wing one. [7] 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.

[i] Blog by isolateByoblu: https://qua.name/isolateByoblu [ii] Toot by isolateByoblu (post is TBA): https://mastodon.social/@isolatebyoblu/107099727580087708 14/10/2021 [0] Hugo Gameiro, New changes to the Terms of Service and Privacy Policy, MastoHost https://masto.host/new-changes-to-the-terms-of-service-and-privacy-policy/ 6/11/2020 [1] isolateByoblu, RIGHT WING. Youtube shuts down Byoblu: our viewpoint, https://qua.name/isolatebyoblu/youtube-shuts-down-byoblu-our-viewpoint 1/6/2021 [2] isolateByoblu, #isolateByoblu FAQ: If you de-federate their instance, why should we de-federate them too?, Lattuga Git Repository, https://git.lattuga.net/isolateByoblu/isolateByoblu/wiki/%5Ben%5D+FAQ#q-if-you-de-federate-their-instance-why-should-we-de-federate-them-too-arent-you-safe-enough-yet 11/8/2020 [3] Various authors, Homosexual agenda, English-language Wikipedia, https://en.wikipedia.org/wiki/Homosexual_agenda [4] Various authors, Russian gay propaganda law, English-language Wikipedia, https://en.wikipedia.org/wiki/Russian_gay_propaganda_law [5] Various authors, Reverse discrimination, English-language Wikipedia, https://en.wikipedia.org/wiki/Reverse_discrimination [6] Des Freedman, In defence of (some) conspiracy theory, openDemocracy, https://www.opendemocracy.net/en/opendemocracyuk/in-defence-of-conspiracy-theory/ 17/08/2018 [7] Florian Cramer and Wu Ming 1, Blank Space QAnon. On the Success of a Conspiracy Fantasy as a Collective Text Interpretation Game, giap https://www.wumingfoundation.com/giap/blank-space-qanon/ 30/10/2020 (revised)

El tutorial oficial explica la solución a este problema, pero en este artículo demostraré formalmente la propiedad que se explota para resolverlo.

Resumen del enunciado

-Entrada: Un grafo conexo no dirigido con $n$ vértices y $m$ aristas, además de $q$ consultas $a$ y $b$, dos vértices distintos del grafo. Ninguno de los valores supera $3 \cdot 10^5$.

-Salida: Determinar si existe un conjunto de $q$ caminos simples, cada uno entre los vértices de una consulta distinta, tal que cada arista haya sido usada un número par de veces (en el enunciado se menciona que cada aparición de la arista en un camino aumenta su peso en $1$, partiendo desde $0$). Si es el caso, entonces imprimir dichos caminos, y en caso contrario, imprimir el número mínimo de consultas adicionales necesarias para poder crear un conjunto de caminos que cumpla con la condición.

Vamos por partes

Lo primero a determinar si es posible escoger $q$ caminos simples tales que cada arista del grafo aparezca en un número par de dichos caminos. Claramente la respuesta es NO si $q = 1$, porque cada arista debe ser usada por al menos $2$ caminos.

Observando los casos de ejemplo, podemos darnos cuenta que en el primero cada vértice aparece un número par de veces en la parte de las consultas y la salida es “YES...”, mientras que en el segundo los vértices $1$, $2$, $3$ y $5$ aparecen un número impar de veces y la salida es NO.

¿Qué nos dice esto?

En cada camino simple, un vértice $v$ tiene tres posibilidades:

-No aparecer en el camino -Aparecer como el primer o último vértice del camino -Aparecer en medio del camino.

El primer caso es despreciable. En el segundo caso la suma de los pesos de todas las aristas incidentes a $v$ aumenta en $1$ (porque necesitamos usar exactamente una de ellas para el camino), y en el tercero aumenta en $2$ (porque necesitamos una arista para entrar al nodo y otra para salir). Notar que si $v$ aparece en una consulta, debe ser el primer o último vértice del camino, y si sale en un número impar de consultas, entonces la suma de los pesos de todas las aristas incidentes a $v$ es impar porque el tercer caso no cambia la paridad de dicha suma. Dado lo anterior, una de esas aristas tiene peso impar porque en caso contrario la suma sería par. Luego, si existe $v$ que aparezca en un número impar de consultas la respuesta es que no se pueden satisfacer las condiciones.

¿Si 'impar $\rightarrow$ NO', entonces 'par $\rightarrow$ YES'?

La suma de los pesos de las aristas incidentes a cada vértice es par, pero falta demostrar que cada uno de esos pesos también es par en caso de que cada vértice aparezca un número par de veces en las consultas (la llamaremos propiedad $P$).

Para hacer las cosas simples, construyamos un árbol recubridor del grafo. Cada arista no perteneciente al árbol tendrá peso nulo. Por lo anterior sólo hay un camino existente entre cada par de vértices del árbol. Entonces el problema se reduce a demostrar que para cualquier árbol de $n$ vértices se cumple la propiedad $P$.

Si $n = 2$ entonces cada consulta consiste en el mismo par de vértices, que aparecen un número par de veces en total (por hipótesis), y el único camino posible para cada consulta ocupa la única arista del árbol. Como el número de consultas es par (consecuencia de la hipótesis), entonces el peso final de la arista es par.

Supongamos que la propiedad $P$ se cumple para todo árbol con $k \leq n$ nodos. Añadiendo un nuevo vértice $v{n+1}$ al árbol (junto con una arista $en$ incidente al nuevo vértice $n+1$) y una lista cualquiera de consultas válidas.

Ok, ¿pero cómo sé que consultas adicionales debo hacer?

Primero hay que darse cuenta que no hay que encontrar las consultas, sólo el número de éstas, por lo que el problema se hace más fácil.