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”.
1 Mi Piace
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.
1 Mi Piace
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)
1 Mi Piace
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:
- alla fine e’ stata inserita questa icona fa-bullhorn: Font Awesome Icons (non e’ definitiva, ma una prova, non me ne volere @pong )
- sono state aggiunte le seguenti istanze nella timeline autogestione:
mastodon.bida.im’,‘mastodon.cisti.org’,‘nebbia.fail’,‘sociale.network’,‘puntarella.party’,‘gancio.cisti.org’,‘lapunta.org’,‘stereodon.social’ - corretti alcuni testi
- posizionata la timeline come suggerito da @pong
prossimo rilascio:
cercheremo di correggere il baco segnalato da @tommy
1 Mi Piace
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.
1 Mi Piace
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
1 Mi Piace
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
1 Mi Piace
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
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 )