Ho rilasciato il codice su GitHub, ma al momento direi che la qualità è di livello alfa. Molte cose funzionano, ma al plugin mancano la documentazione e alcune patch aggiuntive (come questa) richieste per Discourse per farlo funzionare.
Cosa è stato implementato finora:
Homeserver discovery – funziona
Channels – funziona
Group Chats – funziona
Direct Chats – funziona
Edits – funziona
Deletions – funziona
Uploads – in programma per il prossimo rilascio
Presence/typing notifications and read receipts – in programma per il prossimo rilascio (se possibile)
Reactions – funziona
Replies – funziona
Text messages (plain and formatted, emojis) – funziona
Ci sarà un argomento più formale che annuncerà il plugin quando raggiungerà la qualità beta. Grazie per il tuo interesse in questo plugin!
Forse una domanda sciocca, ma con questa integrazione, fornirà la crittografia end-to-end su Discourse? O si limiterebbe a copiare ciò che è su Discourse e a inviarlo a Matrix, in modo che un amministratore su Discourse abbia ancora accesso a tutti i messaggi in chiaro inviati nelle chat?
Questo è super eccitante. Ho notato che la pull request collegata è stata completata, ma senza dubbio è un progetto enorme. Sono curioso di sapere come procede il supporto alla chat di Matrix e sono entusiasta per questo.
Per quanto mi riguarda, Discourse è progettato principalmente per essere un forum pubblico. La crittografia E2E è piuttosto controproducente a questo riguardo. Se non ti fidi dell’amministratore dell’istanza Discourse, non vedo alcun motivo per usarlo. La crittografia E2E non impedirebbe all’amministratore di inserire funzionalità dannose nel browser per aggirare la crittografia. Se c’è un alto requisito di segretezza per la comunicazione da uno a molti o da molti a molti, un canale Matrix dedicato è la scelta migliore IMHO.
Sono d’accordo. Immagino che la stragrande maggioranza delle persone che usano Internet non comprenda appieno che una chat privata su una piattaforma è molto spesso visualizzabile da un amministratore. Nel mio caso, come amministratore, probabilmente disabiliterei le chat private su Discourse perché non so se le persone capiranno che posso leggere tutti i loro messaggi 1-1 nonostante quanto io dica loro che posso e poi magari cercherei di reindirizzare le persone che se vogliono contattare direttamente le persone, a farlo tramite Matrix o Signal (sto ancora aspettando i nomi utente in modo che non si debba dare il proprio numero di telefono a tutti).\n\nApprezzo il punto che con Discourse open-source, l’amministratore può semplicemente rompere anche l’E2EE quindi forse non ci si potrebbe fidare comunque.\n\nGrazie per aver risposto~
Molto bello, ma vedo che non ci sono istruzioni di installazione effettive elencate.
Maggiori informazioni su questo plugin e su come installarlo su [Meta](https://meta.discourse.org/t/TODO).
Sei confuso. Questo si collega a Matrix, il che significa che non include alcun tipo di crittografia end-to-end (e2e). Rende semplicemente la chat del forum disponibile anche agli utenti di Matrix.
Questo non ha nulla a che fare con la segretezza. Si tratta semplicemente di chattare con persone che si trovano su Matrix.
Non c’è e2e qui. e2e significherebbe che la crittografia è lato client, prima che raggiunga il server. Possiamo per favore smettere di confondere il supporto di Matrix con l’e2e.
Potremmo risolvere questo problema molto semplicemente includendo tutti gli amministratori nell’elenco dei partecipanti di ogni chat di gruppo (e ovviamente gestendolo dinamicamente quando e se gli amministratori lasciano e si uniscono) ma questa sarebbe una FR separata, ovviamente.
Non so se sto reinventando la ruota, ma sto scrivendo un bridge da Discourse Chat ad altre piattaforme. Su Telegram ho avuto un discreto successo e il bridging funziona molto bene. Successivamente, sto considerando di collegare Discourse Chat a Matrix.
Un po’. Questo thread è iniziato con l’idea di sostituire il protocollo di chat di Discourse con il protocollo Matrix. Qualcosa che sembra molto ragionevole perché sembra essere ben progettato e ha un’adozione crescente. Non so nemmeno perché stiamo parlando di bridge qui. La domanda è perché il protocollo Discourse dovrebbe essere deprecato in futuro o perché no.
E2EE per chat/messaggi privati (dovrebbero essere la stessa cosa IMHO) sarebbe possibile per impostazione predefinita con l’adozione del protocollo Matrix. Nessuna necessità di un protocollo personalizzato.
Qualcuno del team principale di Discourse può fornire informazioni sullo stato attuale delle discussioni sull’“interoperabilità della chat di Discourse con la chat basata su Matrix”? Qui in Europa, abbiamo un certo numero di grandi attori che già utilizzano Matrix come base tecnica per le proprie app di messaggistica:
TI Messenger, futuro messenger tedesco per i servizi sanitari gematik Fachportal
L’adozione di Matrix sta crescendo in tutto il mondo. Credo che un certo “collegamento” della chat di Discourse con l’ecosistema Matrix possa diventare un argomento cruciale per l’utilizzo della piattaforma Discourse nel prossimo futuro (più o meno simile ad ActivityPub per collegare Discourse con Mastodon). Esiste del codice bridge su
ma l’ultima attività risale a 2 anni fa. Quindi, ci sono piani per adottare questo codice o crearne uno nuovo che sia “ufficialmente supportato”?
Per quanto ActivityPub sia utile per collegare discussioni aperte, l’implementazione del protocollo Matrix potrebbe anche essere utilizzata come modo sicuro per collegare categorie non pubbliche tra diversi server Discourse e anche come modo aggiuntivo per inviare notifiche agli utenti.
Abbiamo lavorato con Dan nelle prime esplorazioni che vedi in quel repository per saperne di più sulla fattibilità di rendere la chat interoperabile con matrix.
Sembrava promettente all’epoca, anche se sono emerse alcune sfide che non abbiamo affrontato completamente, la principale è il modo in cui vengono gestiti gli utenti su ciascun sistema.
Anche la chat si è evoluta parecchio da allora e non abbiamo considerato la compatibilità con matrix come un vincolo per i nostri progetti, quindi è possibile che ci siano ulteriori divergenze tra i due sistemi che dovrebbero essere affrontate.
Sarebbe probabilmente necessario qualcuno che sponsorizzi questo lavoro per portarlo avanti e garantire che ci sia un incentivo più forte a mantenere ciò che è stato costruito.
