View Issue Details

IDProjectCategoryView StatusLast Update
0017578ScribusPlug-inspublic2025-07-15 20:14
Reportersch Assigned To 
PrioritylowSeverityfeatureReproducibilityN/A
Status newResolutionopen 
Summary0017578: XMPP Whiteboard
DescriptionGood day.

I advise to add XMPP capabilities for Scribus, in order to facilitate the functionality of collaboration and teaching.

This is discussed constatnly over XMPP, yet, due to the lack of focus, this feature is not at its full potential, yet it is implementable nevertheless, and all the needed XEP (XMPP extensions) are already set.

* https://wiki.xmpp.org/web/index.php?search=whiteboard&title=Special%3ASearch&fulltext=Search
* https://wiki.xmpp.org/web/Psi_Whiteboarding
* http://www.deepdarc.com/2006/03/01/pandion-whiteboard/

Perhaps developers of Inkscape and The GIMP would want to participate in creating this feature.

I suppose, that the best fashion would be with a client daemon.

https://sourceforge.net/projects/wxxcd/

=== BEGIN ARTICLE ===

XMPP client daemon

By Robert Bugg Quattlebaum Jr.

There are many XMPP clients out there for just about every platform imaginable. This is often cited as one of the strengths of XMPP, but it does have serious drawbacks; namely end-user confusion and (for open-source projects) duplicated developer effort. I am starting to think that the approach that nearly all XMPP clients take is sub-optimal.

One of the primary reasons people are hesitant to adopt ‘yet another instant messaging network’ is that no single XMPP client does everything that they want. In fact, many people will find themselves using multiple clients for this reason. I know I do. Why switch when none of the XMPP clients out there have all of the features which you use with your legacy service?

I do not believe that there will ever be a do-it-all XMPP client—and if there were, I do not know if I would want to use it. The word “Bloated” comes to mind. Instead, I think the solution is to explicitly not create a do-it-all client, but to create a bare-bones XMPP service that would provide XMPP connectivity to programs which support it. The idea being that it is hard to write a full-featured client, but it is significantly easier to write a program which just provides one service or function.

When we go to set up a new program that uses the internet, we do not have to explicitly provide all of the log-in details for your ISP. You are either already connected to the internet or not, and all of your programs (in general) use the same internet connection. I think that this is the model we should start considering for XMPP. Have a program for instant messaging and roster management, have a program for whiteboards, Have a program for group chat, but they all use the same connection and API.

What I propose is that, on a desktop system, the individual XMPP connections themselves should not be handled by the XMPP client at all–they should be handled by some sort of XMPP daemon that would establish a single connection to their XMPP server upon logging into the computer.

Apple’s iChat already does something similar to this. The iChat program itself does not connect to any chat service directly–iChatAgent does. Programs which are designed to use the presence information for your contacts (like Address Book and Apple Mail) will still be able to report correct presence information even when iChat is closed*.

There are certainly a lot of things that would need to be taken into consideration for such a setup (such as security and API standardization), but I think that perhaps that will be the topic of another post on the subject.

=== END ARTICLE ===

gemini://woodpeckersnest.space/~schapps/journal/2006-05-21-xmpp-client-daemon.gmi

https://portal.mozz.us/gemini/woodpeckersnest.space/~schapps/journal/2006-05-21-xmpp-client-daemon.gmi
Additional InformationSee also https://discuss.pixls.us/t/xmpp-whiteboard-for-collaboration-and-teaching/51178
Tags#waiting
PatchNo

Activities

sch

2025-07-13 07:13

reporter  

pic-735-medium.png (64,404 bytes)   
pic-735-medium.png (64,404 bytes)   
xcd-lib.jpg (348,354 bytes)   
xcd-lib.jpg (348,354 bytes)   
xcd-ex.jpg (21,230 bytes)   
xcd-ex.jpg (21,230 bytes)   

sch

2025-07-13 08:01

reporter   ~0052882

I have posted an article with a reference to potential projects.

https://portal.mozz.us/gemini/woodpeckersnest.space/~schapps/journal/2024-08-27-whiteboard-over-xmpp-for-productive-software.gmi

gemini://woodpeckersnest.space/~schapps/journal/2024-08-27-whiteboard-over-xmpp-for-productive-software.gmi

ale

2025-07-15 18:18

manager   ~0052891

Please provide a Scribus specific concept.
Sadly, you also will probably also need to provide manpower to work on it.
(Just make sure that you coordinate with the team on how to manage the changes)

For your information, several years ago an IRC interface to Scribus has been created.
The result was really interesting, but not really something one want to use in production.

sch

2025-07-15 18:59

reporter   ~0052893

> Please provide a Scribus specific concept.

I do not know exactly how, as of yet.

There is an XEP specification which is titled XEP-xxxx: Shared XML Editing

> This specification defines a protocol that enables two or more endpoints to collaboratively edit an XML object. The protocol is intended for use mainly over the Extensible Messaging and Presence Protocol (XMPP), either by existing instant messaging clients or by specialized editing clients. However, the protocol could also be used over a direct TCP connection rather than over XMPP.

This XEP might be useflu for the purpose of collaborative editing of documents with Scribus.

XMPP utilizes technology which is refered to as PubSub (XEP-0060) which is utilized to store and synchronize data; it is a stable standard, and it would probably be the base to utilize Scribus with the XMPP technology.

sch

2025-07-15 19:01

reporter   ~0052894

Sorry.

I forgot to refer to post a link to XEP-xxxx: Shared XML Editing

https://xmpp.org/extensions/inbox/sxe.html

The status is currently ProtoXEP, and it might be that once a software such as Scribus would implement it, then it would be further examined and then approved.

ale

2025-07-15 20:14

manager   ~0052898

As wrote above, it is not realistic to expect Scribus to implement any Whiteboard feature based on XMPP.
The resources for it are simply not there.

If you think you can provide the implementation, you're welcome to dig into it and make a proposal of how it might work and check with the team how good are the chances ,that it will get integrated into Scribus. Most of all, you will need to check if it can be reviewed in a sane time frame.
You will probably need both to validate the concept and then the get patches to be reviewed, once they are ready.

If you can't provide an implementation, I'm not sure it's useful to keep this ticket opened: the chances that somebody will read it and start working on it are close to zero.

Issue History

Date Modified Username Field Change
2025-07-13 07:13 sch New Issue
2025-07-13 07:13 sch File Added: pic-735-medium.png
2025-07-13 07:13 sch File Added: xcd-lib.jpg
2025-07-13 07:13 sch File Added: xcd-ex.jpg
2025-07-13 08:01 sch Note Added: 0052882
2025-07-15 18:18 ale Note Added: 0052891
2025-07-15 18:19 ale Tag Attached: #waiting
2025-07-15 18:59 sch Note Added: 0052893
2025-07-15 19:01 sch Note Added: 0052894
2025-07-15 19:16 jghali Priority high => low
2025-07-15 20:14 ale Note Added: 0052898