Description: Serverless collaborative real-time editing using LibreOffice Community Please enable LibreOffice Community edition to be used collaboratively and in real-time without the need to set up and host a server, i.e. serverless, nor use a cloud-server (which really means you are storing all your information on someone else’s computer). [Jami](https://jami.net/) is: * a client and also a server; and * an application with a one-click install. Jami runs on Windows, macOS, GNU/Linux, iOS, Android, AndroidTV so seems like a great fit for LibreOffice Technology which uses the same core on all platforms. Jami uses Distributed Hash Tables so that all client are servers and with their swarm technology all participants are kept in synchronisation, even if there are intermittent connections. Please also see issue https://git.jami.net/savoirfairelinux/jami-project/-/issues/1010 on the Jami issue tracker. What do you think of Jami and LibreOffice? Thank you Postscript: You might also like to visit https://www.remotehq.com/ Steps to Reproduce: Please enable LibreOffice Community edition to be used collaboratively and in real-time without the need to set up and host a server, i.e. serverless, nor use a cloud-server (which really means you are storing all your information on someone else’s computer). Actual Results: No instructions on how this is currently possible. Expected Results: Use LibreOffice Community edition collaboratively and in real-time with other users with [Jami](https://jami.net/). Reproducible: Always User Profile Reset: No Additional Info: https://jami.net/ https://jami.biz/ https://git.jami.net/savoirfairelinux https://review.jami.net/ https://dl.jami.net/ https://www.transifex.com/savoirfairelinux/jami https://www.transifex.com/savoirfairelinux/jams-jami-account-management-server/ https://www.transifex.com/savoirfairelinux/jami-website/ https://www.youtube.com/channel/UCIe47cCt_ovwKb2Nfr4nBlw/ https://forum.jami.net/ https://git.jami.net/savoirfairelinux/ring-project/-/wikis/features/All-features-by-client
I would prefer Retroshare because I am a contributor to it https://github.com/RetroShare/RetroShare
(In reply to Buovjaga from comment #1) > I would prefer Retroshare because I am a contributor to it > https://github.com/RetroShare/RetroShare Hmm, I see you referenced my comment in https://github.com/RetroShare/RetroShare/issues/2494 However, my point was that instead of Jami, I would prefer Retroshare. Objectively, though, this request should be rejected. If Jami wants to use LibreOffice, they are free to do so. There is also a request for real-time and offline collaboration: bug 133984.
P2P LibreOffice https://the.webm.ink/a-vision-for-libreoffice Peer-to-peer collaboration with LibreOffice https://design.blog.documentfoundation.org/2024/07/17/peer-to-peer-collaboration-with-libreoffice/ From the https://jami.net/ website: * Jami is completely peer-to-peer and doesn't require a server for relaying data between users. * Jami is a GNU project backed by the Free Software Foundation and licensed under GNU GPLv3 or later. Can this issue please be re-opened? Thank you
(In reply to Buovjaga from comment #1) > I would prefer Retroshare because I am a contributor to it > https://github.com/RetroShare/RetroShare Thank you for your comments. Please read “Jami distributed network” [1] and see “Fig. 1 – Centralized, Decentralized and Distributed Networks”. Any peer-to-peer LibreOffice solution should also use a distributed network for connectivity. Jami uses a *distributed* network for connectivity. A LibreOffice issue has been created at “Bug 145252 - Serverless collaborative real-time editing using LibreOffice Community edition with [Jami](https://jami.net/)” [2]. Unfortunately, the status was changed to RESOLVED WONTFIX due to a preference to RetroShare. RetroShare has a design flaw as it is unfortunately *decentralized*, not *distributed*. It would be beneficial if any LibreOffice collaborative editor solution would utilize a distributed network connectivity paradigm. Additionally, the DHTNet library [3] is designed to establish secure peer-to-peer connections using public-key authentication. Can the status of this issue please be changed to NEW? Thank you [1] https://docs.jami.net/en_US/user/jami-distributed-network.html [2] https://bugs.documentfoundation.org/show_bug.cgi?id=145252 [3] https://git.jami.net/savoirfairelinux/dhtnet
(In reply to Óvári from comment #4) > (In reply to Buovjaga from comment #1) > > I would prefer Retroshare because I am a contributor to it > > https://github.com/RetroShare/RetroShare > Thank you for your comments. > > Please read “Jami distributed network” [1] and see “Fig. 1 – Centralized, > Decentralized and Distributed Networks”. Any peer-to-peer LibreOffice > solution should also use a distributed network for connectivity. Jami uses a > *distributed* network for connectivity. > > A LibreOffice issue has been created at “Bug 145252 - Serverless > collaborative real-time editing using LibreOffice Community edition with > [Jami](https://jami.net/)” [2]. Unfortunately, the status was changed to > RESOLVED WONTFIX due to a preference to RetroShare. RetroShare has a design > flaw as it is unfortunately *decentralized*, not *distributed*. I closed this not because of my preference, but because I saw this as out of scope for LibreOffice, regardless of which third party software would be used. Your claim about RetroShare not being distributed is false. It works in the same way as Jami, leveraging DHT to set up peer connections. It does not need servers. In any case, it is unclear to me how this proposal would work technically and what would be the benefit over implementing a similar solution natively in LibreOffice.
Shouldn't a feature request be phrased solution- and technology agnostic? If you really want to push Jami, which is as good to me as Matrix or any other protocol (although I made the last IP Call years ago and use Matrix every day), you should make clear why collaborative real-time editing needs to be like this. Duplicate of bug 133984, IMO.
> Duplicate of bug 133984, IMO I agree that being prescriptive over which technology to use is premature, but this feature request adds the important requirement for the collaboration to be effectively serverless. I have a hunch that for IPv4 some kind of connection enabler (like STUN) will prove necessary, but being serverless is fundamental and that is not duplicative. So I would not close as a duplicate.
Created attachment 195522 [details] Fig. 1 – Centralized, Decentralized and Distributed Networks “Fig. 1 – Centralized, Decentralized and Distributed Networks” from https://docs.jami.net/en_US/user/jami-distributed-network.html