Abbiamo implementato la nuova timeline “Autogestione” e stiamo cercando di testarla.
Vi chiediamo di inserire in questo thread errori, problematiche riscontrate, osservazioni e suggerimenti.
L’obiettivo è fare una pull request su questa issue Subfederation · Issue #13256 · mastodon/mastodon · GitHub
In locale sembra funzionare. Ora tocca capire se regge in un ambiete di produzione. Useremo l’istanza Bida per le prove
Ieri notte abbiamo corretto alcuni problemi visuali. Abbiamo ora un errore 500 dovuto a dei file che sembra non abbiamo importato. Stanotte tenteremo un nuovo rilascio.
La timeline Autogestione è funzionante
Al momento nella timeline finiscono i toot pubblici delle seguenti istanze:
mastodon.bida.im
nebbia.fail
Attualmente è visibile solo sull’interfaccia web.
Che figata! E’ quasi come l’avevo immaginata e proposta sul github di mastodon! Grazie mille a chi si sbatte per svilupparla! (Conoscessi Ruby darei una mano anch’io, ma non lo conosco neanche un po’).
Un po’ per migliorarla (secondo me), un po’ per avere più probabilità che venga inclusa in “mastodon ufficiale” e il suo frontend web, ho 3 propostine da fare + una che invece è grossetta. Prima le 3 propostine:
Ora la proposta “grossetta”: credo che attualmente la timeline “Autogestione” si porti un problema grosso, soprattutto rispetto alla possibilità di essere inclusa in “mastodon ufficiale” e il suo frontend web: così com’è adesso, qualsiasi istanza potrebbe aggiungere qualsiasi altra istanza (volendo, tutte le altre istanze!) alla sua timeline “Autogestione”, andando a pesare sulle risorse delle istanze aggiunte senza il consenso dei rispettivi admin o collettivi di gestione. Se non risolviamo questo problema credo che Eugenio non accetterà mai la modifica nel mastodon ufficiale e nel suo frontend.
Per risolverlo, la mia proposta è di implementare un meccanismo di “autorizzazione al following” tra istanze che dovrebbe funzionare così: (collettivo di) admin di istanza A richiede (per mail, per assemblea, per come vuole) a (collettivo di admin) di istanza B di poter “followare” la timeline locale dell’istanza B dall’istanza A, ovvero di poterne mostrare i toot sulla propria timeline “Autogestione”; se admin di istanza B è d’accordo, aggiunge l’uri dell’istanza A a una lista di uri di istanze che possono followare l’istanza B (se lo fa, ovviamente, può decidere in qualsiasi momento di togliere la uri dell’istanza A dalla stessa lista); se invece non è d’accordo, non l’aggiunge, e morta lì. Ovviamente admin di istanza B può decidere di richiedere la stessa cosa all’istanza A.
Al momento questo meccanismo non c’è, e da una qualsiasi istanza A (e da ovunque in realtà) è possibile seguire la timeline locale di qualsiasi altra istanza B (a meno che l’istanza B non abbia disabilitato l’anteprima pubblica, ma questo non ci interessa, è un altro par de maniche), chiamando l’api endpoint “https://[uri istanza B]/api/v1/timelines/public” (vedi qua).
Il meccanismo invece dovrebbe permettere a mastodon di rispondere con i toot della timeline locale solo se la chiamata arriva da un’istanza che è stata attivamente autorizzata a seguirla.
Secondo me Eugenio non ha già implementato un meccanismo simile semplicemente perché quello attuale, senza verifica, non è ancora stato abusato, ma la timeline “Autogestione” al momento permetterebbe di farlo facilmente.
Grazie Pongi, sempre sul pezzo e sempre utilissimo. D’accordo su tutto. Vorrei, se riuscirò ad essere ad hackmeeting, fare un workshop su come sviluppare mastodon.
Neanche io sono un programmatore Ruby e la parte javascript l’ho presa a calci.
Per quanto riguarda il peso, in realta non pesiamo nulla. Quello che fa l’applicazione è una query sui toot gia’ in database (che sono stati gia’ storati immagino dai meccanismi dell’activityPub) e li mostra in timeline.
Quindi, in realtà, l’autorizzazione ha poco senso sulle risorse, puo’ invece avere molto senso per motivi “politici”.
Grazie a te e l’altr* degli sbatti. Se querate solo il db locale e non pescate dall’endpoint dell’api, ho il dubbio che in realtà l’attuale timeline “Autogestione” non riporti tutti i toot pubblici delle istanze che “guarda”, ma solo quelli degli account seguiti da qualcun* su Bida.
Se ci pensi rimangono valide tutte pe regole alla base dell’istanza e del protocollo in questo modo.
Vero, ma pescare tutti i toot pubblici dagli API endpoint invece che solo quelli già presenti nel db andrebbe contro le regole alla base dell’istanza o del protocollo? Non lo so, ma credo di no: quei toot sono pubblici. E potrebbe forse essere comunque sostenibile: i toot degli account ancora non noti non finirebbero comunque nel db prima che qualcuno ci interagisse fattivamente, credo.
Il rispetto dei blocchi interistanza (che resta sempre un po’ tanto virtuale, almeno con le istanze che non hanno disabilitato l’anteprima pubblica) si può mantenere, mi pare, anche pescando dall’API endpoint.
Ciao belli, intanto iniziativa fighissima!
Sulla questione query su api esterne / query su db locale son d’accordo col punto di vista di @pong: se ci sono api che espongono pubblicamente i toot di queste istanze sarebbe bello poterne usufruire (questo al netto delle questioni su autorizzazioni “politiche”/ di cortesia e soprattutto di quelle sull’eventuale peso in termini di risorse sulle altre istanze).
Anche perchè, con la configurazione attuale ,Autogestione sarebbe “solo” un sottoinsieme della timeline federata; sfruttando le api delle altre istanze avremmo la possibilità di leggere/scoprire post e utenti effettivamente nuovi (cosa di cui sento la mancanza di brutto).
Poi come consigliato lascio scritto anche qui quel che ho tootato, in modo da tener traccia del buggino.
Attivando la timeline da web (da Firefox 91.0.2 su Linux, ma mi puzza di roba che prescinda dal client), c’è il tastino “Show settings” in alto a dx, a fianco del nome della timeline.
Normalmente dovrebbe far saltar fuori un sub-menu per poter pinnare la timeline, ma con questa nuova si spacca giù tutto, restituendo un:
Due to a bug in our code or a browser compatibility issue, this page could not be displayed correctly.
Try refreshing the page. If that does not help, you may still be able to use Mastodon through a different browser or native app.
Qui lo stacktrace che regala la pagina di errore:
TypeError: n is undefined
l</t.prototype.render@https://mastodon.bida.im/packs/js/common-b868bdf8b8c4ca0c9de3.js:2:1190697
Bi@https://mastodon.bida.im/packs/js/common-b868bdf8b8c4ca0c9de3.js:2:1016673
qi@https://mastodon.bida.im/packs/js/common-b868bdf8b8c4ca0c9de3.js:2:1016468
ks@https://mastodon.bida.im/packs/js/common-b868bdf8b8c4ca0c9de3.js:2:1052082
vu@https://mastodon.bida.im/packs/js/common-b868bdf8b8c4ca0c9de3.js:2:1043525
mu@https://mastodon.bida.im/packs/js/common-b868bdf8b8c4ca0c9de3.js:2:1043448
su@https://mastodon.bida.im/packs/js/common-b868bdf8b8c4ca0c9de3.js:2:1040478
$o/<@https://mastodon.bida.im/packs/js/common-b868bdf8b8c4ca0c9de3.js:2:992119
t.unstable_runWithPriority@https://mastodon.bida.im/packs/js/common-b868bdf8b8c4ca0c9de3.js:2:1067177
Qo@https://mastodon.bida.im/packs/js/common-b868bdf8b8c4ca0c9de3.js:2:991828
$o@https://mastodon.bida.im/packs/js/common-b868bdf8b8c4ca0c9de3.js:2:992066
Yo@https://mastodon.bida.im/packs/js/common-b868bdf8b8c4ca0c9de3.js:2:991999
L@https://mastodon.bida.im/packs/js/common-b868bdf8b8c4ca0c9de3.js:2:1060955
Yt@https://mastodon.bida.im/packs/js/common-b868bdf8b8c4ca0c9de3.js:2:969320
l</t.prototype.render (webpack:///node_modules/twitter-text/dist/regexp/validGTLD.js:19:54)
zh (webpack:///node_modules/react-dom/cjs/react-dom.production.min.js:3949:15)
cg (webpack:///node_modules/react-dom/cjs/react-dom.production.min.js:3931:22)
si (webpack:///node_modules/react-dom/cjs/react-dom.production.min.js:6180:164)
f.setProperty (webpack:///node_modules/react-dom/cjs/react-dom.production.min.js:5526:12)
f.setProperty (webpack:///node_modules/react-dom/cjs/react-dom.production.min.js:5521:14)
c.parentNode.insertBefore (webpack:///node_modules/react-dom/cjs/react-dom.production.min.js:5352:112)
dc (webpack:///node_modules/react-dom/cjs/react-dom.production.min.js:2245:17)
gk (webpack:///node_modules/react-dom/cjs/react-dom.production.min.js:7138:66)
extractEvents (webpack:///node_modules/react-dom/cjs/react-dom.production.min.js:2231:53)
tc (webpack:///node_modules/react-dom/cjs/react-dom.production.min.js:2241:24)
tc (webpack:///node_modules/react-dom/cjs/react-dom.production.min.js:2237:12)
Yg (webpack:///node_modules/react-dom/cjs/react-dom.production.min.js:6731:53)
dc (webpack:///node_modules/react-dom/cjs/react-dom.production.min.js:792:34)
grazie per il contributo @tommy Sul discorso “meccanismi timeline” io personalmente non sono cosi convinto. Sarei piu’ per fare un “Autogestione bot” che scopre i “nostri” account, piuttosto che creare un nuovo protocollo (perche’ in realta’ state proponendo quello).
Per quanto riguarda questo ultimo aggiornamento:
prossimo rilascio:
cercheremo di correggere il baco segnalato da @tommy
Bello anche l’ultimo aggiornamento e anche l’icona non mi spiace 
E alla fine, anche se penso che querare l’API endpoint “…/timelines/public” non creerebbe necessariamente un nuovo protocollo[1], la soluzione attuale “querare il db locale”, insieme a un “Autogestione bot” che scopre i “nostri” account, sarebbe comunque meglio (più facile da implementare senza toccare troppe altre cose di Mastodon).
[1] Nota tediosa, inutile e inopportuna: già Fedilab permette di vedere le locali di istanze diverse da quella su cui si è loggati proprio pescando dall’API endpoint “…/timelines/public”, e sicuramente, essendo solo un client, lo fa senza creare un nuovo protocollo. Però boh forse mi sfugge qualcosa.
@pong probabilmente ho detto una stupidaggine. Il discovery non è implementato nel protocollo Activitypub.
È da ragionarci o più semplicemente da buttare giù il codice.
Per me molte cose sono ancora oscure.
Per me anche di più, sicuramente
Buttare giù il codice partendo dalla mia zero conoscenza di Ruby… boh provo a cominciare a guardare il codice di mastodon da github, ma non garantisco niente di niente eh!
Ma la vostra versione modificata posso vederla da qualche parte?
Vorremmo farla vedere ad hackmeeting ma per te si può fare un eccezione
Vedo di mandartela via email
Che giorno la fate la presentazione ad hackmeeting? Se riesco vengo. Comunque se riesci a mandarmela in anteprima son contento
Ci siamo inseriti sabato ore 12, spazio Zampirone
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ə.
Poi mi è venuto in mente che allo script attuale potrei aggiungere la raccolta degli account de far seguire ai bot anche dagli endpoint delle timeline locali, oltre che dagli endpoint delle directory dei profili, magari prossimamente ci lavoro