Solo una nota: al momento ci troviamo in questa fase
5 Mi Piace
Questo sembra fantastico!
Recentemente ho configurato un server Discourse per la nostra cooperativa CoSocial che gestisce un server Mastodon. Ho finito per configurare il plugin OAuth2 in modo da accettare solo accessi dal nostro server Mastodon → https://members.cosocial.ca (installazione nuova e piuttosto semplice, solo “prova di OAuth”).
La mia domanda / richiesta di funzionalità è che sia possibile integrare / unire gli attori di Mastodon negli account Discourse, in modo che quando gli account su Mastodon rispondono, possano essere collegati / di proprietà dell’account Discourse associato.
Come Lemmy Non Fa Questo
Ho documentato come Lemmy non fa questo: puoi interagire tramite Mastodon e viene creato un account in Lemmy per quell’account Mastodon, ma non puoi effettivamente accedere e utilizzare le funzionalità di prima classe di Lemmy con il tuo account Mastodon.
4 Mi Piace
È in programma…
Ed è già in coda per la revisione
3 Mi Piace
Ottimo. Sembra che i miei utenti del plugin Discourse OAuth dovranno “confermare di nuovo” per interagire con questo plugin AP.
Penso che vada benissimo in questa fase, voglio solo segnalare il server OAuth come un ulteriore aspetto, purché non sia in conflitto. La cosa “desiderabile” sarebbe “se OAuth con server Mastodon, allora collega automaticamente l’identità dell’attore AP”. Totalmente futuro e anche unico per questo tipo di configurazione!
(E mi scuso per non aver aperto la pagina per guardare quella parte! Ottimo!)
1 Mi Piace
La PR che aggiunge questo set di funzionalità è stata ora unita.
Come notato sopra da Angus, la prossima cosa è la verifica dell’utente tramite token OAuth.
2 Mi Piace
I problemi che ho riscontrato in precedenza con il markdown grezzo che veniva visualizzato sembrano interessare anche meta. Sto seguendo @feature@meta.discourse.org e alcune ore fa è stato creato questo post che è stato federato da quell’attore:
Questo mi è apparso su Mastodon con un glitch in questo modo:
In Elk, ha questo aspetto; un po’ meglio:
Ho appena iniziato a seguire @feature@meta.discourse.org sul mio account Mastodon puro per testare questo, ma ovviamente è troppo tardi per vedere questo post particolare lì. 
Quindi il markdown incorporato che ho visto in precedenza dalla mia installazione non era un database difettoso, o se lo era, era un problema del database condiviso con meta e quindi probabilmente non associato ai miei test.
2 Mi Piace
Sì, posso riprodurlo, vedo un output simile in un’istanza Mastodon e in Ivory (app per iOS).
2 Mi Piace
Non sono sicuro che questo stia funzionando correttamente. Il plugin è abilitato e ho creato un argomento in una categoria con ActivityPub abilitato, ma non vedo il badge accanto ai post (e il mio tentativo di seguire l’attore ActivityPub della categoria sembra essere fallito, dato che si comporta come un server che necessita di approvazione manuale da parte di un utente).
Ho appena notato che lo stesso problema sembrava verificarsi anche con Feature su Meta.
1 Mi Piace
Sarebbe fantastico capire l’obiettivo finale delle restrizioni, senza preoccuparsi dello stato intermedio.
Ad esempio, credo di aver visto un riferimento in una PR secondo cui il cambio di proprietario dei post sarà bloccato se il plugin è abilitato. Come amministratore, devo usare quella funzione in rare occasioni (ad esempio, quando cambio il moderatore di una categoria, rendo il nuovo moderatore principale della categoria proprietario della categoria relativa al post “appiccicoso”). Spero che alla fine, questo si traduca in un’eliminazione e una ripubblicazione, o anche solo ignorato, piuttosto che bloccare il cambio di proprietà.
Mi chiedo anche riguardo allo spostamento di post tra categorie. Devo farlo abbastanza frequentemente, specialmente quando i nuovi utenti pubblicano nella categoria sbagliata. Mi aspetterei ingenuamente che ciò si traduca in un attore di categoria che rimuove il suo “boost” e il nuovo attore di categoria che aggiunge un “boost”, ma non l’eliminazione del post sottostante, in modo tale che se qualcun altro avesse visto e “boostato” un post, il suo “boost” non scomparirebbe solo perché il “boost” dell’attore di categoria è scomparso.
In generale, sarebbe davvero utile sapere cosa vi aspettate che venga disabilitato quando questo plugin verrà aggiunto, dopo che lo sviluppo delle funzionalità attualmente specificate sarà completato, indipendentemente dalle restrizioni attualmente in vigore.
1 Mi Piace
@hello-smile6 Vedo la stessa cosa con il plugin aggiornato oggi:
Non vedo alcuna configurazione, quindi presumo sia un bug.
2 Mi Piace
Grazie per l’ulteriore segnalazione. Ci sto lavorando.
Grazie per la segnalazione, ci stiamo lavorando.
Apprezzo il tuo punto di vista, tuttavia
-
Mentre il plugin è in fase di sviluppo attivo, tentare di spiegare le cose in questo modo sarebbe improduttivo poiché la spiegazione potrebbe cambiare.
-
Ci sono un bel po’ di scenari diversi e casi limite che il plugin già gestisce, per me spiegarli tutti narrativamente in questa fase richiederebbe troppo tempo (cioè, fare essenzialmente questo lungo post un certo numero di volte). Ci sono già oltre 400 specifiche diverse per il plugin.
-
Ciononostante, le restrizioni sono spesso spiegate narrativamente nei commenti sui PR e sui commit, che credo tu stia già leggendo.
Questo è stato discusso in modo approfondito sul PR
Ho limitato il cambio di proprietari dei post e la creazione di wiki per i post, anche per gli amministratori, negli argomenti AP. Questo perché i post AP remoti devono mantenere la fedeltà con l’originale e entrambe le azioni possono potenzialmente rompere quella fedeltà.
Potrebbe esserci un modo per far funzionare la federazione sia con i wiki che con il cambio di proprietari dei post, tuttavia suggerisco di aggiungerlo come “funzionalità” in un PR futuro poiché dovrà comportare la moltiplicazione o il cambio dell’attore associato a un oggetto che viene federato su più piattaforme. Penso che non saremo mai in grado di consentire il cambio di proprietari dei post importati da AP (note), poiché l’associazione attore/oggetto non è di proprietà di Discourse, ma del luogo in cui il contenuto è stato creato. Per fare un’analogia illustrativa, in questo contesto, l’eliminazione di un post associato a una nota importata è meno una “eliminazione” in sé, che una scelta di non mostrare una Nota.
Ci sono un bel po’ di scenari diversi che coinvolgono lo spostamento dei post. Gestirò quello specifico che hai menzionato per ora, ovvero lo spostamento di un post tra due categorie diverse abilitate ad ActivityPub.
Stai presumendo che l’unica volta in cui un post viene spostato tra categorie sia quando il post viene inizialmente pubblicato nella categoria sbagliata, e lo spostamento avviene poco dopo la creazione del post. Cosa succede se, 4 mesi dopo che un post è stato creato, sposti quel post in un’altra categoria perché vuoi consolidare una certa raccolta di post in un nuovo argomento in una categoria diversa? Avrebbe senso inviare un “Annulla” per il boost originale in quello scenario?
Questo dipende se stiamo parlando della configurazione del Primo Post o della configurazione del Topic Completo. Per la prima aggiungeremo un pulsante per il primo post da pubblicare manualmente per gestire specificamente lo scenario di spostamento di categoria. Per quest’ultima, aggiungere automaticamente un boost potrebbe avere senso, ci penserò ancora un po’.
Capisco il tuo punto di vista, tuttavia ho già condiviso molti dettagli sullo stato finale nella specifica della Fase 2 sopra. Oltre a quella specifica, e mettendola nel modo più gentile possibile, ci sono troppi casi d’uso e scenari per discuterli tutti in dettaglio con te, e poi anche con il team di Discourse.org, mentre ci lavoro 
Aggiornerò l’OP con una panoramica generale del comportamento previsto una volta completata la Fase 2.
1 Mi Piace
Non sono in grado di riprodurre questo problema. Ho appena seguito feature@meta.discourse.org da un account Mastodon di prova e non ho riscontrato alcun errore (né in Mastodon né in Discourse).
1 Mi Piace
Potrebbe essere correlato all’istanza da cui l’ho seguito, questa istanza fa qualcosa di insolito?
Oh cielo, nel mio tentativo di porre una domanda chiara, sono sembrato chiedere molto lavoro. Mi scuso per aver comunicato male. Apprezzo la risposta ponderata.
Questo era ciò che intendevo chiedere, non aggiornamenti dettagliati continui in questo thread. Il mio “dopo” in “dopo che lo sviluppo della funzionalità attualmente specificata è completo” intendeva applicarsi a quando la chiarificazione sarebbe stata utile, non intendeva chiedere di descrivere ora lo stato futuro. La mia domanda era formulata in modo ambiguo. Mi dispiace!
Questo è ciò che volevo davvero capire: l’obiettivo finale, in linea di massima, è limitare Discourse solo a ciò che supporta l’ActivityPub canonico, o è quello di federare da un’esperienza Discourse nativa illimitata al fediverso su base best-effort? La mia esperienza passata con le integrazioni di Discourse mi aveva portato ad aspettarmi il best-effort; ora capisco che il vostro piano è perseguire invece la fedeltà, a scapito della funzionalità di Discourse, e non solo come misura temporanea durante lo sviluppo.
Non lo sto presumendo. Perché quattro mesi farebbero la differenza qui? È appena entrato in una categoria federata, perché non dovrebbe causare il boost della categoria federante? Io, almeno, mi sarei ingenuamente aspettato che accadesse. Vedo spesso persone che boostano post vecchi di molti mesi, quindi non conosco un motivo particolare per cui questo dovrebbe essere diverso.
E sì, penso che avrebbe senso inviare un Annulla per il boost originale. Questo sembra essere comune. (Infatti, Annulla su un boost e poi un nuovo boost sembra essere un meccanismo tipico per “far riemergere” i contenuti; non correlato a questo scopo ma illustrando che Annulla su boost è comunemente usato e quindi non dovrebbe causare problemi ad altre implementazioni di ActivityPub.)
Vedo la stessa cosa in questo momento per feature@meta.discourse.org da mastodon.cloud che penso stia eseguendo Mastodon standard.
1 Mi Piace
Personalmente, non ci penso in un modo o nell’altro. Discourse.org stabilirà l’agenda generale qui, ma in linea di massima le decisioni vengono prese in base a come funziona e a ciò che è pratico. Se esiste un modo sensato e sostenibile per consentire le modifiche all’autore su tutti i post, indipendentemente dalla provenienza, allora ottimo.
Concentrandosi solo sull’annullamento della promozione originale, quell’Annulla specifico non sembra servire a uno scopo? È anche discutibilmente un po’ sorprendente in alcuni scenari, come ha cercato di mostrare il mio esempio. L’intenzione dello spostamento della categoria potrebbe non essere quella di annullare (Undo) la “discoverability” originale del contenuto. Potrebbe essere quella di cambiare l’organizzazione del contenuto in seguito per un motivo diverso.
Per dirla in un altro modo, applicare un’inversione automatica dell’Annuncio originale su un cambio di categoria in Discourse funziona in alcuni scenari, ma non in altri. E anche negli scenari in cui sembra avere più senso, l’Annuncio originale non sta realmente causando alcun danno. Quindi, perseguendo i principi del minor danno e della minima sorpresa, sembra più sensato lasciare l’Annuncio originale al suo posto. Mi scuso se mi sfugge qualcosa.
Per pensarci da un’altra angolazione, non credo sia giusto pensare alle attività di Annuncio di un Attore di Categoria come sinonimo del ruolo tassonomico delle Categorie stesse. Un Annuncio è il modo in cui un attore di categoria condivide contenuti con i suoi follower, ma non è una tassonomia in sé. È un modo per scoprire contenuti all’interno del Fediverso. Non credo che debba esserci una relazione 1:1 tra le categorie e le attività di Annuncio degli attori di categoria.
3 Mi Piace
Ah. Allora è davvero una domanda per il team. 
Ha senso anche questo. Sono d’accordo, non c’è molto valore nel revocare il boost.
Quindi è un segnale a innesco di bordo; significherebbe “un post è appena entrato in questa categoria, o perché è stato scritto o perché è stato spostato nella categoria”. Questo è concettualmente semplice.
Penserei quindi di cambiare la paternità di un post in modo simile. Sarebbe il nuovo attore a creare una nuova attività per il post del nuovo autore, e non c’è particolare necessità di fare nulla con la vecchia attività creata sotto il vecchio autore, perché il vecchio autore non scriverebbe modifiche e non dovrebbe essere accreditato per tali nuove modifiche. Non hanno effettivamente eliminato il loro post su Discourse, quindi l’eliminazione dell’attività dell’autore originale non rifletterebbe necessariamente una verità di base. Ma ciò che era stato pubblicato in precedenza dall’attore del vecchio autore sarebbe ciò che avevano scritto, e non ci sarebbe motivo di eliminare tali post. E se qualcuno seguisse il link a Discourse vedrebbe il contenuto e la paternità attuali, con (date sufficienti autorizzazioni) la visualizzazione della cronologia delle modifiche.
La stessa logica si applica ai wiki. Appaiono su Discourse sotto una paternità singola ma permettendo ad altri di scrivere. Gli aggiornamenti di altri autori non sono ampiamente attribuiti (a meno che non si disponga di autorizzazioni sufficienti per leggere la cronologia). Non è in realtà particolarmente significativo se tale attribuzione viene visualizzata da un avatar nella vista web all’interno di Discourse o da un attore activitypub associato a un’attività; il risultato finale è un’attribuzione presentata al lettore umano all’altra estremità di una pipeline di rendering o di un’altra.
1 Mi Piace
Hm, non sono sicuro di essere d’accordo. Il risultato finale di questo sarà due Note identiche nel Fediverso, scritte da Attori diversi, entrambe visibili su più piattaforme. Per una persona nuova che si avvicina a quel contenuto per la prima volta, vedrà lo stesso contenuto scritto da persone diverse. Al contrario, quando cambi un autore in Discourse, riscrivi essenzialmente la storia; per una persona nuova che si avvicina al contenuto per la prima volta, vedi solo il nuovo autore. C’è una differenza, non credi?
Non sono sicuro di capire completamente. Stai dicendo che tutte le modifiche al post del wiki, da parte di qualsiasi utente, dovrebbero essere trattate come normali attività di Aggiornamento attribuite all’Attore originale (cioè, la persona che l’ha pubblicato)?
Nota che questo è l’oggetto di questa PR, accompagnato da note esplicative.
4 Mi Piace