anche qui. Non riesco a cambiare il proprietario di un thread. Anche se la categoria NON è federata.
Quelli sono avvisi, non errori. Non significano necessariamente che qualcosa non va, sono lì per darti maggiori informazioni su ciò che sta succedendo. Ci potrebbero essere una serie di ragioni per cui il contenuto dal Fediverso non viene elaborato, molte delle quali riguardano la persona che invia il contenuto. Se non vuoi che appaiano nei tuoi log, disattiva il logging dettagliato per il plugin ActivityPub (activity pub verbose logging)
L’argomento si trova in una categoria ActivityPub o ha un tag ActivityPub?
L’argomento è stato creato in una categoria ActivityPub o con un tag ActivityPub?
Si prega di notare che la modifica del proprietario di un argomento è intenzionalmente disabilitata per gli argomenti ActivityPub. Per quanto riguarda il motivo per cui è così, si prega di vedere sopra:
È una categoria con Activitypub, ma stiamo parlando del proprietario del thread che non è coinvolto con activitypub in quanto è un account diverso.
Penso che dovrebbe esserci comunque un’opzione per consentire di cambiare il proprietario, altrimenti non ha senso che Discourse abbia la finestra di dialogo per cambiare il proprietario.
Inoltre, cambiarlo senza inviare alcun aggiornamento ad activitypub è perfetto per noi.
1 Mi Piace
Capisco che la gente voglia la possibilità di cambiare la proprietà dei post. Il problema da affrontare a questo riguardo è quello che ho delineato sopra, in particolare questo:
Il contenuto che appare sul tuo Discourse proviene da un servizio di cui non sei Amministratore e sul quale, se non fosse per ActivityPub, non avresti alcun controllo. Estendere semplicemente la possibilità di cambiare l’autore di quel contenuto senza un’adeguata considerazione di quel fatto non sarebbe prudente.
Per quanto riguarda il contenuto scritto da utenti del tuo Discourse in un argomento pubblicato tramite ActivityPub, considera cosa dovrebbe succedere se vengono apportate modifiche al contenuto una volta cambiato l’autore del post. Dobbiamo:
- smettere di pubblicare aggiornamenti di ActivityPub; o
- pubblicarli dal “vecchio” Attore (utente); o
- pubblicarli dal “nuovo” Attore (utente).
La pubblicazione di attività di aggiornamento per un Oggetto esistente con un nuovo Attore (cioè 3) funzionerà con Discourse (come ho tentato di fornire un’opzione per questa domanda), ma non funzionerà con altri servizi ActivityPub. Infatti, ho già insistito su questo punto, per questo motivo, nell’ecosistema ActivityPub. Vedi qui:
E ho un PR in sospeso per Mastodon per rendere possibile il punto 3
Per fare un esempio di uno dei problemi qui, considera il caso in cui stai pubblicando contenuti ActivityPub con il tuo account (e il tuo nome e la tua immagine) allegati. Uno dei tuoi “concorrenti” segue i tuoi contenuti. Sul loro server cambiano la proprietà di tutti i post con i tuoi contenuti in modo che siano post loro (con il loro nome e la loro immagine) invece che post tuoi. Questo potrebbe, alquanto comprensibilmente, darti fastidio. Sì, ovviamente questo è possibile comunque con codice personalizzato, ma la domanda è se vuoi integrarlo nelle opzioni predefinite del plugin.
Pensandoci durante la notte, un approccio che potrebbe mitigare un po’ questo problema è se aggiungessimo l’Attore di pubblicazione alla visualizzazione dello stato di ActivityPub:
Sono aperto ad altre idee in quella direzione.
Vero, penso che rimuoverò completamente la modale sugli argomenti ActivityPub finché non risolveremo la questione sottostante qui.
2 Mi Piace
Capisco il problema, nel nostro caso utilizziamo Activitypub con un account per ogni categoria e pubblichiamo quell’aggiornamento.
Quindi, chi è il proprietario del thread non ci interessa molto su Activitypub per i vari casi, per questo motivo dico che dovremmo essere in grado di farlo comunque.
ActivityPub non riguarda solo come utilizzi il tuo forum, ma come il tuo forum interagisce con il resto del fediverso. Inoltre, per integrare qualcosa nel plugin dobbiamo tenere conto anche di altri casi d’uso.
Non voglio dare l’impressione che consentire il cambio di proprietario di un post non sia un problema attivamente considerato, o che non sarà consentito in un futuro aggiornamento. Sono interessato a qualsiasi idea che le persone abbiano per risolvere i problemi sottostanti qui, alcuni dei quali ho delineato sopra.
Affrontando questo esempio, sarebbe ragionevole vietare la modifica della proprietà dei post che sono stati federati, consentendo al contempo agli amministratori di modificare la proprietà dei post originati all’interno di quell’istanza Discourse, indipendentemente dal fatto che siano federati.
Un amministratore può impersonare un utente. Pertanto, un amministratore è in grado, all’interno della piattaforma con le sue attuali funzionalità, di creare contenuti mascherandosi da qualsiasi utente sulla piattaforma. Spero che gli amministratori non abusino di questo potere; io non lo faccio. Tuttavia, quel potere è simile nell’impatto alla capacità di cambiare la proprietà di un post, federato o meno. In generale, “un amministratore può fare qualcosa di nefasto” è già vero in innumerevoli modi.
Sono d’accordo (almeno per quanto capisco 
) che cambiare la proprietà di un post che è stato creato tramite federazione (quindi, non un post dell’argomento?) non abbia molto senso. A differenza del cambio di proprietà dei post creati sul sito, non ricordo di aver visto un caso d’uso articolato.
Mi piace questo non solo dal punto di vista della robustezza contro questo tipo di attacco, ma per rendere la federazione più visibile, rendendo più facile per un visitatore del sito trovare attori da seguire. Come apparirebbe questo per un caso in cui c’è un attore di categoria (e, forse un giorno, un attore di sito?) e un attore di persona? Avresti una lista?
- Pubblicato da
[@category@site](link) - Pubblicato da
[@person@site)(link)
1 Mi Piace
Grazie per la tua utile analisi.
Concordo.
Questa analisi vale solo per i post non federati. La domanda non è se il cambio di proprietario di un post abbia senso per Discourse stesso. La domanda è quali effetti abbia il cambio di proprietà sui contenuti federati. Se cambi la proprietà di un post locale che è stato federato, devi affrontare questa domanda:
Inizierei notando che sia l’opzione 1 che la 2 presentano problemi sostanziali, che posso elaborare se necessario. La risposta potrebbe essere quella che il plugin già supporta, ovvero “3”, tuttavia se seguiamo quella strada accadrà questo (supponendo che il mio attuale PR per Mastodon non venga unito):
- L’argomento viene federato.
- I post dell’argomento appaiono su Mastodon.
- L’amministratore del sito cambia il proprietario del post.
- Il nuovo proprietario del post apporta varie modifiche al post.
- Le modifiche non arrivano su Mastodon (o su qualsiasi altra piattaforma ActivityPub).
E da ciò consegue:
- Qualcuno verrà qui e dirà “le mie modifiche non vengono federate”. Il motivo per cui non sarà immediatamente ovvio perché, per quanto riguarda Discourse, vengono federate.
Il punto chiave è che se adottassimo questo approccio, saremmo la prima piattaforma nel fediverso (per quanto ne so) a farlo. Essere l’unico nodo in un sistema interconnesso di nodi a fare qualcosa non è una cosa desiderabile. Potremmo promuovere un cambiamento a questo riguardo, ma dovremmo essere consapevoli che è ciò che staremmo tentando.
Detto questo, ho già implementato la 3, e sospetto che sarà la risposta definitiva che mi permetterà di rimuovere questa restrizione. Ho ancora qualche speranza che qualcuno possa trovare un approccio leggermente più sfumato, o qualcosa a cui non ho ancora pensato.
Verrebbe elencato solo l’attore attributedTo dell’oggetto, quindi ce ne sarebbe solo uno.
1 Mi Piace
Vedo l’oscenità. Il processo mentale che mi ci ha portato è più o meno questo…
Potrei immaginare ingenuamente qualcosa come il n. 3 con solo un pizzico del n. 2 — per federare anche un aggiornamento generato dal vecchio utente che aggiunge all’ultima versione pubblicata un testo generato dal sistema in alto o in basso, qualcosa di vagamente simile a “per futuri aggiornamenti, segui @newuser@site”.
Quindi avrebbe (di nuovo ingenuamente) senso assegnare un nuovo ID per il post aggiornato sotto il nuovo attributedTo e che viene utilizzato per gli aggiornamenti del nuovo proprietario.
Un caso limite ovvio per me sarebbe il cambio di proprietà al proprietario originale — si ritorna al vecchio ID del post o se ne assegna un altro? Penserei che si ritorni indietro, nel qual caso l’ID del post federato dovrebbe effettivamente essere una chiave per una tupla (utente, post di discourse). Mi aspetto che ciò richieda una migrazione per il supporto con retrocompatibilità.
Tutto ciò come esperimento mentale mi fa apprezzare più chiaramente perché non saresti desideroso di affrettare la tua proposta di modifica a Mastodon! 
Esclusa l’accettazione della tua PR di Mastodon, potrei immaginare di poter contrassegnare i post individuali come non federati, che verrebbero federati come cancellazione se precedentemente federati, e/o potrebbero essere fatti con il plugin installato ma prima che la federazione fosse abilitata, e quindi consentire il cambio di proprietà solo per i post non federati. Tutti i post per i quali voglio poter cambiare proprietà sono post che non sono preziosi da federare, per quanto ne so.
Potrei immaginare che ciò sia prezioso anche se la tua PR di Mastodon venisse accettata e fosse supportato il cambio di proprietà. Non sono sicuro che abbia senso federare i post della categoria, per esempio. Almeno, penso che li escluderei tutti dalla federazione sul mio sito anche se fosse supportato il cambio di proprietà, se avessi la possibilità di escluderli.
Un interessante esperimento mentale, tuttavia non funzionerebbe per alcuni motivi.
- Non segui singoli utenti nell’attività pub di discourse.
- Non puoi cambiare l’ID di un oggetto activity pub esistente (dovresti creare un nuovo oggetto).
- Come dici tu, se la proprietà cambiasse di nuovo, o più volte, finiresti con più oggetti per un post, il che sarebbe ingestibile.
Una cosa che posso fare ora in questa direzione è cambiare la restrizione in base alla pubblicazione del primo post in un argomento locale. Questo aiuterà con alcuni argomenti come dici tu.
1 Mi Piace
Il mio malinteso; pensavo avessi anche creato la possibilità di farlo, oltre agli attori di categoria. (Non è una richiesta di funzionalità, solo un malinteso.)
Questo era ciò che stavo cercando di descrivere, e chiaramente ho fallito. Era inteso come una sorta di reductio ad absurdum in ogni caso. 
Sarebbe meraviglioso! 
1 Mi Piace
Ciao, c’è una limitazione per Lemmy?
Non riesco a seguire: @batepapo@lemmy.eco.br per esempio
In realtà, riesco a seguire. Il pulsante “smetti di seguire” appare anche sotto il profilo, ma quando aggiorno la pagina, tutto scompare.
1 Mi Piace
Ottimo lavoro! Ho una domanda riguardo ai minuti di ritardo nella consegna di ActivityPub. C’è un modo per disabilitare la funzionalità in modo che il post sia visibile subito?
Impostazione 1 min è quasi immediata, ma vorrei pubblicare anche in tempo reale.
1 Mi Piace
@David_Ghost leggi questo
2 Mi Piace
Questa è la prima cosa che ho notato anch’io. Quale sarebbe lo svantaggio di aggiungere il titolo di un nuovo argomento al post distribuito tramite ActivityPub?
[Titolo dell'argomento di Discourse]
[linea vuota]
[Testo dell'argomento di Discourse, come pubblicato ora]
Gli utenti di Lemmy stavano lavorando per aggiungere la compatibilità con Discourse. È nella mia agenda controllare questo aspetto.
Ciò significa che Discourse sta inviando un Follow ma non riceve un Accept da Lemmy.
Attualmente puoi farlo solo utilizzando una variabile d’ambiente (ad esempio, impostata nel tuo file app.yml)
DISCOURSE_ACTIVITY_PUB_DELIVERY_DELAY=0
Il titolo di un argomento viene già pubblicato. È il name della raccolta associata all’argomento.
Questo è il modo in cui la federazione da Discourse a Discourse, o da Discourse a NodeBB, o da Discourse a qualsiasi piattaforma simile a un forum include i titoli degli argomenti. Mastodon non elabora i titoli. Se dovessimo inserire il titolo dell’argomento nel contenuto della Nota come suggerisci, ciò comporterebbe problemi, ad esempio per quando il contenuto viene federato su piattaforme che supportano i titoli.
Fondamentalmente, la limitazione che descrivi è che Mastodon è una piattaforma di microblogging. Abbiamo già aggiunto funzionalità per accomodare ciò, ovvero il markup [note][/note] per consentirti di indirizzare il contenuto che stai federando. Se desideri una corretta federazione simile a un forum, ti suggerirei di federare con altre istanze di Discourse.
Sì, ci sono molte istanze di Mastodon. Ma ci sono anche molte istanze di Discourse. Se un’istanza di Discourse con cui desideri federare non è ancora configurata per farlo, sarei felice di aiutarli a configurarla.
5 Mi Piace
È possibile eliminare gli Actor?
E sarebbe possibile impostare più categorie, in modo che pubblichi tutto ciò che c’è di nuovo in Discourse?
Altrimenti qualcuno dovrà seguire xx handle su Mastodon per ottenere tutti i contenuti da tutte le categorie.
Puoi disabilitare un Actor, il che disabilita tutto ciò che è correlato a quell’actor.
Se elimini la categoria o il tag a cui l’actor è associato, eliminerai l’Actor. Al momento non è possibile eliminare un actor in isolamento. Ti consiglio di disabilitare semplicemente l’Actor.
Questo potrebbe essere possibile in futuro (medio-lungo termine) se aggiungeremo un actor “Applicazione” per un intero Discourse. La federazione di tutto su un Discourse attraverso un singolo Actor sarà probabilmente sempre un caso d’uso di nicchia.
1 Mi Piace
Hm, okay. Forse la mia comprensione delle possibilità è diversa…
Ieri l’ho configurato e ha funzionato bene. Ho eliminato i Post su Discourse, perché l’ho solo testato, ma i post sono ancora online su Mastodon. Quindi ho pensato di poter eliminare l’account per eliminare anche i contenuti da Mastodon.
Se lo disabilito soltanto, il contenuto rimane online su Mastodon.
E se non posso eliminarlo, non potrò usare questo handle con altre categorie in futuro. Potrei voler cambiare alcune categorie in futuro, ma non potrò usarlo con quell’handle che ha xx follower. Quindi dovrò creare un nuovo handle e tutti dovranno seguirlo di nuovo. Non vedo alcun vantaggio nel disabilitare soltanto un handle che non mi serve più.
E: Quando disabilito un handle, anche l’altro viene disabilitato. Quindi posso gestire più handle o nessuno?
Ma è quello che voglio, o sto capendo male? Voglio informare le persone su una rete sociale riguardo alle discussioni sul mio intero discourse e non solo per un tag o una categoria. Quando gestisco una sezione “Notizie”, posso capirlo, ma voglio che tutti partecipino alle discussioni, quindi devo pubblicare tutto e non solo una categoria.