Prima di tutto @pong grazie per il codice. Ieri in hackmeeting, a margine del talk, ne abbiamo un po’ parlato. C’erano delle perplessità anche sugli autogestione bot. Alcun* ritengono che non ha senso far finire nella timeline autogestione utenti che non interagiscono.
Non so, è da ragionarci
Boh ma i bot servirebbero proprio ad aumentare la probabilità di interazioni interistanza, almeno tra istanze affini. E se un(’)utente non interagisce, nel senso che non scrive, in timeline autogestione non ci finisce comunque, pure se seguit* da un bot. E se Pippo nuovo utente di nebbia (per es.) non è seguit* neanche dai bot delle altre istanze sorelle, nella timeline autogestione delle istanze sorelle non ci finisce (perché già non finisce nemmeno nella timeline federata delle stesse), nemmeno se e quando scrive, e nemmeno se viene boostato (i boost vengon visti solo nella home di chi segue chi li fa). I bot + la timeline autogestione per me dovrebbero servire proprio ad aumentare le probabilità di interazioni interistanza, almeno tra chi scrive e almeno tra istanze affini; senza i bot, per come è adesso, la timeline autogestione è solo un “sottoinsieme” della federata, non rende più probabili le interazioni (è comunque utile come “vista comoda”, ma senza i bot non rende più probabili le interazioni).
Lavando i piatti mi è venuta in mente una cosa: forse quello che non piace è esser seguit* automaticamente da bot di altre istanze, anche se sorelle, anche se quei bot pescano solo dalle directory dei profili, che sono pubbliche, e così avere i propri toot, anche se solo quelli pubblici, sulle federate (e, se presenti, sulle timeline “autogestione”) delle altre istanze. Così mi è venuta in mente un’idea che mi piace un sacco: un bot, che per il momento chiamo “pippo”, che sta su botsin.space e gestisce (ha il token) di altri bot omonimi (o anche no) che stanno su altre istanze; nel nostro caso, diciamo, bida nebbia cisti puntarella sociale.network stereodon; qualsiasi utentə di queste istanze, facciamo pluto@nebbia.fail, può mandare a pippo@botsin.space un toot con una sintassi semplice tipo: “Seguimi da mastodon.bida.im, puntarella.party, mastodon.cisti.org”, così che poi i suoi toot pubblici (i toot pubblici di pluto@nebbia.fail) finiranno sicuramente nelle timeline federate, e nelle timeline “autogestione” quando ci saranno, di queste istanze; però il tutto sarà a discrezione di pluto@nebbia.fail, che poi in qualunque momento potrà anche mandare a pippo@botsin.space un toot in cui gli dice per esempio “Smetti di seguirmi da puntarella.party, mastodon.cisti.org” (a parte che questa parte potrebbe farla anche autonomamente, pippo@nebbia.fail). Se vogliamo poi si tratterebbe di comunicare all’utent* delle stesse istanze che possono usarlo, tipo con gli annunci periodici. Boh mi pare che sarebbe bello e che potrei farlo abbastanza facilmente in php, con quel che ho imparato fin qui sviluppando brigitta e poco più (lo script “dietro” pippo@botsin.space potrebbe stare su bida3).
Allora, lo script di cui ho scritto al post precedente l’ho fatto, testato, e funziona benone.
Però poi mi è venuto in mente che c’è un problema a monte, secondo me, nell’idea dei follow-bot, in qualsiasi modo la si voglia implementare: il problema è che l’account di qualsiasi bot apparterrà sempre a qualche uman*. Facciamo che l’account bot è “idefix@istanza” e che appartiene all’umano Gimmi; quando l’utente Pippo sarà seguito automaticamente da idefix@istanza, oppure si farà seguire da idefix@istanza, Gimmi, entrando su “istanza” come “idefix”, potrà leggere non solo tutti i toot pubblici di Pippo, ma anche i suoi toot “followers-only”. E magari Gimmi sta o starà sulle balle a Pippo, e allora Pippo, per avere una possibilità pratica (quella di essere letto dalla timeline federata e dalla timeline “autogestione” dell’istanza di Gimmi), potrà abbozzare e accettare che Gimmi possa leggere i suoi toot, anche quelli “followers-only”, da “idefix@istanza”; oppure potrà decidere di farsi unfolloware da “idefix@istanza” e magari pure di bloccarlo, ma allora perderà la possibilità pratica di cui sopra. Insomma, legare una maggiore possibilità pratica di relazionarsi con altr* a una faccenda di fiducia/sfiducia, simpatia/antipatia nei riguardi di uno/una, non è il massimo. Quindi per me alla fine si torna all’ipotesi “timeline autogestione” come “aggregatore delle locali di tutte le istanze coinvolte” (invece che come filtro sulle federate di ciascuna, com’è adesso, che non aumenta la possibilità di nuovi incroci), che però dovrebbe evitare di mostrare all’utente eventuali toot di chi eventualmente l’avesse bloccat*/silenziat*. Non so se è possibile farla con questa caratteristica, provo a indagare meglio.
Allora, pare proprio sia fattibile: qui nella documentazione dell’api di mastodon è descritto questo endpoint https://mastodon.example/api/v1/accounts/relationships che permette a pippo@mastodon.example di sapere se è bloccato ([blocked_by]=>true) da uno o più altri account, se li sta bloccando, se li sta silenziando, e altro. 
Tra l’altro, siccome lavoriamo sul codice del frontend ufficiale di Mastodon, e non su un client di terze parti, credo sia molto probabile che si possan pescare quelle info direttamente dal database, invece che dall’api, sveltendo assai il tutto; però non lo posso verificare perché non ho più l’istanzina mia di prova e non ho accesso ad alcuna macchina su cui giri un’istanza mastodon.
(Grazie a @diorama che qualche giorno fa ha insistito che secondo lui si poteva fare e così poi ho verificato che in effetti si )
@jops mi è venuta in mente una cosa cui non avevo pensato, mannaggia a me, riguardo ai follow-bot, che mi sembra ridimensioni parecchio il difetto che mi pareva avere la soluzione “follow-bots” che a un certo punto avevi suggerito che poi ho implementato prima in brigitta (che secondo me resterebbe una soluzione troppo invadente) e poi in idefix (che invece è gentile e fa seguire l’utente solo se l’utente glielo chiede): in pratica si può fare che le credenziali di ciascuno dei bot su ciascuna delle varie istanze sorelle ce le hanno solo gli admin (anche solo un@) di ciascuna istanza: chi gestisce il bot principale, quello a cui l’utent* posson mandare toot chiedendo di esser followat* o unfollowat* dai bot sulle varie istanze sorelle, non ha bisogno delle credenziali dei rispettivi account, ma solo, per ciascuno degli stessi, del token di un’app con soltanto privilegi di “follow” sull’account del bot. In questo modo l’utente sa che facendosi seguire dal follow bot su bida si sta facendo seguire da un(’)admin di bida, ecc.: se poi al limite gli starà sulle balle continuare a farsi seguire dall’admin di bida, potrà farsi unfolloware solo dal follow bot di bida e continuare a farsi seguire dai follow bot sulle altre istanze.
Stando così le cose, secondo me ci starebbe mettere la timeline autogestione sulle istanze sorelle già così com’è adesso, che di per sé sarebbe solo un filtro sulla federata di ciascuna istanza che la implementasse, e poi “pubblicizzare” che lə utentə se vogliono possono assicurarsi che i propri toot ci finiscano effettivamente (nelle timeline “autogestione” delle varie istanze sorelle) mandando un toot (privato o pubblico) al bot principale (che sarebbe tipo così: “@botprincipale@istanza.xyz seguimi” - poi ci sono altri comandi di follow e unfollow più selettivi, vedi se ti va il README.md di idefix).
E poi magari lavorare con più calma alla soluzione “timeline autogestione che mostra all’utentə tutti i toot pubblici dalle locali delle istanze sorelle, al netto di eventuali blocchi e silenziamenti”, che secondo me resterebbe comunque da fare, perché sarebbe comunque una soluzione più pulita, mi pare, e perché mi sembra che ci darebbe qualche chance in più che il fork fosse poi effettivamente integrato nel Mastodon “ufficiale”.
@pong idefix mi sembra un ottimo lavoro. E centra molte criticita’. Appena finisco e ho un attimo ci guardo in modo piu’ approfondito.
1 Mi Piace
- TODO: attualmente non e’ previsto l’aggiornamento automatico della timeline autogestione. Prevediamo di modificare il file https://github.com/mastodon/mastodon/blob/main/app/javascript/mastodon/stream.js per far si che funzioni
1 Mi Piace
Io infrattanto, tra ieri e oggi, ho buttato giù un robo in php, orripilante e grezzissimo, con cui però ho verificato che la versione “tutti-i-toot (al netto di blocchi ecc.)” della timeline autogestione SI-PUÒ-FARE!, gh, senza minimamente modificare il protocollo. Il codice sta qui, e se si è malfident* o semplicemente curios* lo si può provare qui, ma la cosa che potrebbe essere d’aiuto (ci spero) è più che altro il testo del README.md leggibile al primo link, che spiega le 2 o 3 feature delle API di Mastodon su cui l’accrocchio si basa e su cui ci si potrebbe appoggiare per implementarlo per bene in un fork di Mastodon che sarebbe bello se fosse proprio quello su cui state lavorando voi, @jops, che ci capite qualcosa di Ruby. Una cosa importante da dire subito, anche se è spiegata nel README.md, è che sarebbe tutto “frontend-client side”, tranne qualche modifica al “backend” di Mastodon per permettere all’admins di un’istanza di abilitare la tl “autogestione” specificando quali altre istanze includervi, e la creazione di un nuovo API endpoint, o di una nuova voce in https://{dominio istanza}/api/v1/instance, che dovrebbe solo listare le istanze eventualmente incluse nella tl “autogestione” eventualmente attiva: basterebbe questo nuovo API endpoint o questa nuova voce in /api/v1/instance per permettere a chi sviluppa i client e i frontend web di implementare il supporto alle tl “autogestione”.
Siccome perché tutto ciò possa accadere sarebbe assai importante che il fork fosse a un bel momento integrato in “Mastodon ufficiale”, mi viene da ribadire una cosa: comunque pensiamo di portarlo avanti - anche se decidiamo di non farlo con “tutti-i-toot” -, penso che il nome attuale “timeline autogestione” non giocherebbe a favore dell’eventuale integrazione in “Mastodon ufficiale”, un po’ perché è troppo specifico, ovvero secondo me per una feature che potrebbe essere utile per tutt* riflette troppo uno “scenario d’uso” che è il nostro, un po’ anche perché: come lo si traduce in inglese e nelle altre lingue? Io di mio proporrei di rinominare la “timeline autogestione” in “timeline di vicinato” (“neighborhood timeline”) oppure “timeline sorellanza” (“sisterhood timeline” o “sorority timeline”), ma forse non van bene neanche questi e allora per me andrebbe comunque già meglio di “timeline autogestione” il “timeline subfederata” (“subfederated timeline”) che propose @diorama.
Prossimamente, comunque, ora che ho verificato grezzamente che SI-PUÒ-FARE!, gh, provo a vedere se mi riesce di capirci di più nel codice di questo fork, quindi in Ruby in generale e in questa pazza libreriona javascript che Mastodon usa.
arrivo con un briciolo di ritardo (un annetto, che vuoi che sia!) per dare il mio pollice su all’idea di @pong (peccato non si veda più in azione) e per dire che mi son reso conto solo ora (forse è grazie all’aggiornamento di qualche settimana fa?) che l’attuale timeline autogestione si riesce a pinnare! Il bug segnalato qui più in alto è risolto, TOP. Grazie rega <3
1 Mi Piace
Da un po’ riesco solo a seguire mastodon.help…