Attualmente ho un argomento su un sito, che vorrei avere anche su un altro sito. Sebbene potrei collegarlo, quello che vorrei davvero è la possibilità di modificarlo su entrambi i siti e che le modifiche vengano riflesse su entrambi. Questo mi evita di avere una versione dell’argomento che è notevolmente obsoleta, e invece mantiene entrambi gli argomenti costantemente aggiornati. Fornisce anche un modo per decentralizzare le informazioni dal mio sito.
Alcune idee sulla funzionalità
Come punto di partenza, un sito rimarrebbe come host/proprietario dell’argomento, e l’altro/gli altri lo rispecchierebbero essenzialmente. Andando oltre, mi chiedo persino se un argomento possa in qualche modo essere ereditato da un argomento speculare se l’originale viene eliminato.
L’argomento dovrebbe mantenere la possibilità di essere nascosto, chiuso, ecc. sui siti speculari.
Le risposte non dovrebbero essere sincronizzate: ogni sito ha una base di utenti diversa, quindi non riesco a capire come potrebbe funzionare la sincronizzazione delle risposte.
Capisco che l’implementazione di una tale funzionalità è tutt’altro che banale, ma mi chiedo se sia mai stata presa in considerazione e quali risultati/esperimenti esistano già?
Potresti fornire maggiori informazioni a riguardo? Dal mio punto di vista, questo ridurrebbe i contenuti duplicati.
Il backup non è l’obiettivo, piuttosto creare un unico punto di verità per argomenti che avrebbero senso su più di un sito.
Per fare un esempio concreto, sto pensando di cambiare il mio visto. Ho un argomento nel mio Discourse privato che è fondamentalmente una checklist di ciò che deve essere fatto. Tuttavia, anche i miei amici potrebbero trovarlo utile, quindi creo lo stesso argomento sul nostro Discourse condiviso. Il problema è che devo sincronizzare le informazioni di entrambi gli argomenti separatamente invece di aggiornarne semplicemente uno. Ciò significa che spesso uno degli argomenti manca di informazioni chiave.
Immagino che questo potrebbe persino essere possibile con una semplice chiave API per l’altro sito? Forse qualcosa come un pulsante/sezione nell’editor in cui è possibile creare un elenco di chiavi API e URL per l’argomento di destinazione. Quando apporti modifiche a un argomento di origine, puoi fare clic su qualcosa come “invia modifiche ai cloni di questo argomento”. Tutto ciò che farebbe sarebbe inviare l’aggiornamento agli argomenti su altre istanze.
Metti le informazioni in un unico posto dove tutti possano vederle. Un link è il modo per farlo.
Ma hai informazioni segrete che vuoi rendere disponibili altrove. Quella è un’altra cosa. È del tutto possibile con un plugin. È il tipo di problema in cui la soluzione forzata richiede 10 volte più lavoro del problema effettivo. (Spesso passo ore ad automatizzare un compito che deve essere eseguito solo una volta, per esempio.)
Ma dovresti metterlo in un posto dove sia disponibile solo all’utente che l’ha pubblicato. O renderlo a livello di sito?
Di nuovo, devono essere per utente e nel serializzatore solo per l’utente corrente (o forse memorizzarlo nel profilo utente?). E avresti bisogno di una qualche struttura dati per mappare le chiavi API ai diversi siti. Sembra qualcosa che penserei di poter fare in 2-5 ore.
Quindi, da qualche parte devi memorizzare l’URL per gli altri siti che dovrebbero avere questo argomento. Anche come creare quel post potrebbe essere complicato; il modo più semplice è crearlo manualmente e includere l’URL di quell’argomento nel sito sorgente. Potresti probabilmente memorizzarlo nel post grezzo in qualche tipo di BBcode o qualcosa di simile. Ciò ti consentirebbe di creare un componente che creerebbe il pulsante e il link per ciascuno di essi e quindi avresti codice Rails che metterebbe in coda un’attività che tenterebbe di inviarla al/ai sito/i. Ma i siti riceventi non avrebbero bisogno di codice: potresti usare l’API per inviare una modifica al post.
Sembra il tipo di cosa che penserei di poter fare in 5-10 ore, ma probabilmente ne richiederà il doppio. Se questo ti diverte, allora potrebbe essere un bel progetto.
Questo potrebbe essere fatto anche tramite una piccola app esterna che ascolterebbe un webhook inviato alle modifiche sul tuo sito di origine, e quindi utilizzerebbe l’API per pubblicare sul sito mirror.
Un plugin potrebbe aggiungere un campo argomento personalizzato per l’URL della fonte del documento primario. (Suppongo che avrebbe anche bisogno di campi per un nome utente remoto e una chiave API se il documento principale deve essere nascosto, come credo sia il tuo caso, ma quella parte potrebbe aspettare. O forse potrebbero risiedere in un campo personalizzato dell’utente. Spetterebbe a chiunque abbia generato la chiave assicurarsi che la chiave API abbia privilegi di sola lettura).
Quando crei un argomento, inseriresti qualcosa come “remoto: https://meta.discourse.org/t/synchronising-crossposting-topics-across-different-discourse-sites/263269” e, quando l’argomento viene creato, Discourse estrarrebbe il testo grezzo dell’argomento remoto, lo inserirebbe in raw come modifica e istanzierebbe il topic_custom_field con l’URL remoto, aggiungendo forse un “copiato da url” in cima.
A questo punto, hai copiato l’argomento remoto localmente e ne hai una registrazione.
Potrebbe quindi esserci un pulsante “controlla sorgente” che estrarrebbe l’argomento remoto e salverebbe l’updated_at dell’argomento remoto e forse anche il raw in altri campi personalizzati (un job potrebbe anche farlo periodicamente, risparmiando un po’ di UX). Potresti quindi avere un pulsante di aggiornamento che sostituirebbe il raw esistente con quello remoto come modifica.
Se il sito principale è pubblico, allora questa parte è davvero facile. L’aggiunta di una chiave API per estrarre da un sito privato complica le cose, la gestione di un set di chiavi API su più siti, la complica ulteriormente. Se la sorgente originale dovesse essere sostituita, potresti forse farlo con il task rake di rimappatura, o aggiungere la possibilità di modificare il campo personalizzato con l’URL remoto quando ne avessi bisogno.
Questa parte viene fornita gratuitamente, poiché questa soluzione prevede che i siti secondari estraggano i dati dal sito primario.
Giusto. E ci può essere un link al sito sorgente, in modo che le persone possano andare alla sorgente per vedere quei commenti, o forse persino incorporarli tramite Embed comments from Discourse in your single page app.
Se hai un budget per questo, non esitare a contattarmi.
È da un po’ che ci penso, anche se solo di recente ha fatto progressi. Purtroppo la sincronizzazione da Discourse a Discourse ha perso valore per me (erano solo una manciata di argomenti), ma ciò che ha acquisito valore è stato il desiderio di sincronizzare file markdown da altre piattaforme in generale.
Il nostro caso d’uso dominante in azienda era avere i readme e le wiki dei progetti Gitlab disponibili all’interno di Discourse (per feedback e ricerca), ma con il file Gitlab che rimaneva l’unica fonte di verità. La mia mancanza di conoscenza di Ruby ha portato a uno script Python che è decisamente eccessivo nella sua implementazione, ma soddisfacente nella sua funzionalità. La prima versione decente fa anche parte di ciò che hai delineato. Alcune funzionalità:
contiene il link alla sorgente originale (file in gitlab)
contiene il link alla revisione specifica (commit # gitlab)
gestisce immagini e URL di immagini
scarica immagini dal repository Gitlab
le carica su Discourse
sostituisce l’URL originale dell’immagine con l’URL breve dell’upload
aggiunge un tag “synced_with_gitlab” in modo che sia facile trovarli tutti
Ha funzionato più o meno allo stesso modo anche con GitHub. Entrambi hanno più o meno lo stesso sapore di markdown, rendendolo piuttosto elegante.
Mi piacerebbe renderlo open source, ma dovrò vedere cosa dice l’ufficio legale. Inoltre, è ancora un po’ un pasticcio di Python “hacky”. L’intenzione è di convertirlo in un plugin Ruby a un certo punto, ma dovrò vedere se riesco a trovare il tempo necessario.
Vero. Ci sto riprovando con questo progetto e attualmente sto valutando la creazione di un DB con:
Una tabella per piattaforma (tabella Discourse, tabella Gitlab, ecc.) per tenere conto delle possibili sfumature
Ogni tabella di piattaforma che supporta webhook e polling tramite chiave API
Crittografia del DB o della chiave API – attualmente penso che sia meglio crittografare l’intero DB e interfacciarsi con esso tramite lo script e una passphrase
Sembra una pazzia e un’eccessiva ingegnerizzazione? Una parte di me vuole costruire una soluzione adeguata per questo, il che significherebbe tenere conto di entrambe le possibilità: webhook e polling.
Inoltre, sarei molto grato per suggerimenti su come mantenere sicuro il contenuto del DB. Il pensiero attuale è di crittografare il db con una passphrase che deve essere fornita come argomento all’avvio dello script, ad esempio:
discourse-sync run password123
Giusto per dare un po’ di ispirazione, il webhook può essere super veloce:
Questi erano due argomenti su due istanze diverse. L’argomento a sinistra è l’argomento di origine, l’argomento a destra è quello di destinazione
Per quanto ne valga la pena, anche a me è venuta in mente questa idea diverse volte. Non sono sicuro che abbiamo ancora un argomento dedicato a questo qui, ma in caso contrario, dovremmo!
Teoricamente sono d’accordo, purtroppo il mondo aziendale complica le cose:
i webhook non sono possibili in azienda a causa delle policy IT (siamo ospitati esternamente all’azienda da CDCK + non possiamo consentire il port forwarding verso l’esterno senza un processo pesante) - quindi la versione API è un must
I webhook sono eleganti, belli e perfettamente ragionevoli per tutti gli altri, quindi ha senso accomodarli anche
Quindi ho realizzato una versione approssimativa di questo tempo fa, funziona benissimo ma non è estensibile. Cattiva progettazione da parte mia: stavo esplorando l’idea di usare un topic con una tabella markdown come input. Ottimo finché non ci sono più di 30 voci, poi diventa un casino.
Parte del caso d’uso da discourse a discourse che vedo è: un unico punto di verità per la documentazione (Meta) si sincronizza ai rispettivi post in altre istanze. Ciò significa che se il team cambia Core e aggiorna la documentazione utente Meta, ho una versione aggiornata di quella documentazione nella mia istanza nativamente per tutti gli utenti da trovare.
Per la V2 ho in programma un database SQLlite come input come sopra, e probabilmente scriverò in Rust questa volta invece che in Python
Di seguito uno schizzo approssimativo.
graph TB
A[terminal] -- ~\u003ediscourse-sync run $PASSWORD --\u003e B[Rust Script]
B -- SQLCipher:Decrypt DB using Password --\u003e C[( sqlite: sources-and-targets')]
C -- 'Discourse' Table Data --\u003e B
B -.-\u003e D{Decision on Type}
D -- Webhook --\u003e E[Listen for Webhook Info]
D -- Polling --\u003e F[Polling API]
E --\u003e G[Receive New Information]
F --\u003e G
G --\u003e H[Parse and Process Data]
H --\u003e I[POST\n tgt_domain, tgt_usr, tgt_key, post_id]
I --'raw' and images--\u003e J[ Target Post ]
subgraph Rust Script Operations
B
D
E
F
G
H
I
end
Sarei molto felice di ricevere feedback e suggerimenti su questo
Sì, questo è ora effettivamente supportato dal plugin ActivityPub. Siamo molto vicini all’utilizzarlo internamente per sincronizzare la documentazione tra meta e un’istanza interna, è nella mia lista di cose da fare per la prossima settimana, infatti.
Si applica anche alle istanze private, nella versione attuale del plugin AP, le istanze private possono seguire categorie in istanze Discourse pubbliche e quindi ricevere attività pubblicate da tali istanze. (Ma il contenuto nell’istanza privata non viene pubblicato, quindi è una sincronizzazione unidirezionale, solo da pubblico a privato.)
Quindi sembra che ActivityPub possa funzionare nel modo seguente:
Pubblico -- Pubblico
Pubblico -- Privato
Privato -- Pubblico
Privato -- Privato
Questo è certamente utile in molti casi, come la trasmissione di documentazione da Meta. Sfortunatamente, questo non soddisfa ancora uno dei miei casi d’uso, che è pubblicare da un’istanza privata a un’altra istanza privata. Da quello che ho capito, ho ragione nel pensare che il plugin ActivityPub difficilmente supporterà questi casi d’uso in futuro? Mi sembra che ActivityPub sia stato progettato pensando al pubblico-pubblico.
@Tris20 Interessante! Grazie per aver condiviso i tuoi pensieri e alcuni dettagli su questo.
Quello che hai descritto è (uno dei) problemi che ActivityPub è stato creato per risolvere. Non voglio smorzare troppo il tuo entusiasmo, ma ad essere onesti, dovrai affrontare una vasta gamma di sfide nel tentativo di realizzare questo nel modo in cui lo stai descrivendo. Non ti darò un resoconto esaustivo di ogni sfida che dovrai superare, ma per darti un’idea, il plugin ActivityPub ha già quasi 700 test rspec e dopo un anno di sviluppo ha solo recentemente supportato la sincronizzazione completa da topic a topic.
Non c’è alcuna limitazione intrinseca che io possa vedere nel supportare la pubblicazione da privato a pubblico e da privato a privato tramite ActivityPub. La questione riguarda la garanzia che le preoccupazioni relative all’accesso e alla sicurezza siano soddisfatte quando si lavora con istanze private.
Se potessi fare un suggerimento. Forse pensa a come puoi costruire sul lavoro che il plugin ActivityPub (e ActivityPub come standard) ha già fatto a questo riguardo. Esiste infatti una soluzione al problema della sincronizzazione dei contenuti da Discourse a Discourse che funziona attualmente. Non copre ancora il tuo caso d’uso, ma risolve la maggior parte dei problemi che dovrai risolvere per soddisfare le tue esigenze.
Forse potresti riflettere su come potrebbe funzionare una sincronizzazione privato-privato nel plugin, cioè come potrebbero essere affrontate le questioni di accesso e sicurezza? Poi forse tu ed io potremmo persino lavorare insieme a una PR per aggiungerla come funzionalità. Forse raggiungerai un punto in cui sentirai che non è davvero possibile ottenere ciò che vuoi ottenere nel contesto del plugin (o di ActivityPub come standard), ma il lavoro che avresti fatto per raggiungere quel punto sarebbe effettivamente lo stesso lavoro che dovresti fare per una soluzione indipendente, quindi non sarebbe vano.
Ci sono molte persone intelligenti nel mondo di ActivityPub, e non mi sorprenderei se questo tipo di problema (cioè la pubblicazione privata) sia stato considerato in modo approfondito in precedenza. Un posto dove potresti trovare qualche opera precedente su questo è SocialHub, il principale forum della community di ActivityPub (Discourse ovviamente) che ora utilizza il plugin Discourse ActivityPub
Pubblico
Pubblico