Mi sa che non riesco a venire 
Comunque, siccome alla fine mi pare che l’idea di pescare i toot per la tl “autogestione” dai vari endpoint “…/timelines/public” delle istanze sorelle non sia praticabile (perché non vedo un modo per evitare che i toot dell’utente X dell’istanza A che ha bloccato l’utente Y dell’istanza B siano visibili a Y sulla tl “autogestione” di B, e forse ci sarebbero altri problemi cui non ho pensato), mi pare che la tua idea del “follow bot” sia meglio, e ne ho fatto uno in php che ho messo su lattuga. Gira su una singola macchina, che può anche non essere nessuna di quelle su cui stanno le istanze che considera (potremmo metterlo in cron job, a girare tipo una volta ogni mezz’ora o un’ora, su bida3, ovvero la macchina che ospita mastodon.help e questo discourse); non richiede account admin su nessuna delle istanze che considera, ma solo un normale account utente su ciascuna, dichiaratamente bot o anche no, con il token di un’app configurata con privilegi di follow; pesca gli account da far seguire ai bot sulle varie istanze dall’api endpoint pubblico che lista gli account presenti nella “directory dei profili” di ciascuna istanza, e così è in qualche modo “opt-in” per l’utent*. L’ho provato dal mio piccì tra due utenti miei, uno su nebbia.fail e uno su mastodon.bida.im, e mi pare funzioni bene: il mio utente “keminu” su “mastodon.bida.im” ora segue tutti gli account che stanno nelle “directory dei profili” di nebbia.fail, mastodon.cisti.org, puntarella.party, sociale.network e stereodon.social, e il mio utente “agadi” su “nebbia.fail” ora segue tutti gli account che stanno nelle “directory dei profili” di mastodon.bida.im, mastodon.cisti.org, puntarella.party, sociale.network e stereodon.social. Insomma funge 
Solo con gancio (gancio.cisti.org e lapunta.org) non funge, credo perché gancio non implementa per ora la “directory dei profili” e il relativo api endpoint. Comunque insomma se vogliamo possiamo già metterlo su bida3 e abilitarlo a usare account (dichiaratamente) bot su nebbia.fail, mastodon.bida.im e le altre istanze; se vogliamo posso fare tutto io (potrei farlo anche se non fossimo tutt* d’accordo, MUAHAHAHAHAH!, ma, non lo farò). In questo caso, pensavo che gli account bot sulle varie istanze sorelle potrebbero chiamarsi tutti allo stesso modo: autogestionebot@nebbia.fail, autogestionebot@mastodon.bida.im, ecc.; nella bio potrebbero riportare tutti una breve descrizione di cosa fanno e a cosa servono, tipo «Un bot che da [nome istanza] segue automaticamente tutti gli account presenti nelle “directory dei profili” delle istanze sorelle [elenco delle istanze sorelle]; ce n’è uno analogo su ognuna delle istanze sorelle; insieme, questi account bot aumentano la probabilità di incroci tra lə utentə delle istanze sorelle, popolando la timeline federata e la timeline autogestione (se presente) di ciascuna istanza con i toot pubblici dellə utentə il cui account è elencato nelle “directory dei profili” delle rispettive istanze» … oppure qualcosa di più succinto, con un link di rimando a una pagina che spieghi più estesamente. Si potrebbe anche pensare a un’immagine di profilo analoga per il bot “autogestionebot” sulle varie istanze, personalizzata per ciascuna.
Se invece volessimo fare un’alternativa che facesse seguire a un bot su ciascuna istanza tutti gli account delle altre istanze, e non solo quelli “pubblicati” nelle rispettive “directory dei profili”, mi pare sarebbe inevitabile e necessario avere un account admin su ciascuna delle istanze. Se lo volessimo fare “centralizzato”, cioè che gira su una sola macchina, significherebbe che chi lo gestirebbe avrebbe accesso admin a tutte le istanze “sorelle”, cosa che mi pare da evitare. Lo si potrebbe fare “distribuito”, ovvero che gira su ciascuna delle istanze “sorelle”, e in questo modo si eviterebbe il problema di cui sopra; io sarei in grado di farlo, ma solo in php, e non so se php è disponibile su ciascuna delle istanze sorelle, perciò prima di fare lavoro inutile chiedo , anche perché magari ci piace di più questo che già c’è e che è meno “invadente” e più “opt-in” per l’utentə.
