Greetings to one and all!
My name is Schimon and I am developing software for XMPP.
I have made a feature request to Connect devices with XMPP (and also Ad-Hoc commands!).
Please share your thoughts on this matter.
I think that XMPP support would be a great addition, in addition to the current peer discovery mechanism Syncthing currently offers.
Can you provide an actual benefit to this other than “it works with XMPP”? Also I’ve no idea how this would work in the first place.
Same for me, I cannot imagine at all what “working with XMPP” could mean. Although I know the protocol from the Jabber days and I know how Syncthing works, I can’t see the connection.
Could you please write up some user experience stories, what actions each user in a group wanting to share data will do? And what their objectives are, in which way they are interacting with the XMPP protocol to achieve them?
Also I’ve no idea how this would work in the first place.
XMPP connectivity will provide a mean to connect Syncthing instances with each other.
Can you provide an actual benefit to this other than “it works with XMPP”?
Treating a resource as a synchronization profile. (I deliberately did not use the word “using” because this is not accurate).
In XMPP, a resource is a part of your JID (Jabber ID) account (i.e. XMPP account).
local@domain/resource
A resource of a Jabber ID can be utilized as an ID, which means that when an account is online and has a certain resource, instances - that have already negotiated with that resource - will offer (again) all possible shared rules that each offers to that resource.
I hope I have explained it properly.
A greater benefit would be sharing of files using XEP-0234: Jingle File Transfer (for example) with other XMPP accounts that use an XMPP client which is not Syncthing (i.e. ConverseJS, Conversations, Dino, Gajim, Kaidan, Movim, Psi etc.)
Could you please write up some user experience stories, what actions each user in a group wanting to share data will do?
I refer to private chats, not MUC if that is what you mean by group.
For start, I offer to make an optional use of plain XMPP account because:
/resource).On another project, I intend to write a plugin to synchronize and share Syndication Feeds using XMPP.
I don’t understand this sentence. What do you mean with “connect”? Establish / replace the actual BEP protocol sync connection? Discover other devices, augmenting the existing discovery schemes? Exchange device IDs without having to copy / paste?
Again, a user story would be very useful to get this cleared up.
What is a “synchronization profile”?
I meant a group of people interested in exchanging files between computers. Such as a family sharing holiday pictures. Many other possible examples, pick one! 
What is MUC?
I’ve never heard of the applications you named before, but as long as they can read files, things already work.
Seems like this is a solution to a problem that doesn’t exist, and it’s mostly ideological.
There are many “lets connect everything together” technologies out there, soap included, and none of them took off and are now effectively irrelevant, atleast to me, including xmpp.
Furthermore, xmpp is a protocol made for instant messaging, it’s a federated protocol, there is no peer to peer connectivity, everything goes through a centralised server(s) that someone else controls. I don’t think pushing terabytes of data through an channel made for instant messaging makes any sense.
Establish.
Instead of using a randomly generated ID, the XMPP address be used as ID instead.
Please ignore this phrase. I will raise it if feature be implemented.
Pardon. I did not understand your question. Now I understand, and this is my answer.
Could you please write up some user experience stories, what actions each user in a group wanting to share data will do? And what their objectives are, in which way they are interacting with the XMPP protocol to achieve them?
For instance, if you want to synchronize contents with people you are working with and you are all chatting via XMPP.
XEP-0045: Multi-User Chat
I did not understand this paragraph.
I disagree.
Wrong.
Ex tensible M essaging and P resence P rotocol (XMPP)
XMPP is a messaging protocol.
XMPP is extensible with XEPs.
X — eXtensible
Defined in an open standard and using an open systems approach of development and application, XMPP is designed to be extensible. In other words, it has been designed to grow and accommodate changes.
Source: https://xmpp.org/about/
there is no peer to peer connectivity
Wrong. There are XEPs that define peer to peer connectivity, namely of “Jingle”.
everything goes through a centralised server(s) that someone else controls
Wrong. In case one decides to share files via “XMPP File Transfer Server” he can do so from a node he wishes and is not bound to a specific server. XMPP File Transfer can also be accomplished by peer to peer connectivity. There are several XEPs that define different fashions to transfer files.
Please refer to Sopranica and see how a one Canadaian man who has established a telephoney business, without an intensive advertisement campaign, has indirectly proven that XMPP is even more popular.
Also, I am a lawyer who is engaging in corporate law and white collar criminal law, and most of my clients (from both fields) exclusively use XMPP for communications.
Know this
The so called big “mafias” of Australia, Chile, Japan, New Zealand, Russia, and eastern Europe use XMPP.
Discord, Facebook Chat, GMX, Google Hangouts, Gtalk, ICQ, KiK, Microsoft Skype, MySpace, Signal Messenger, Telegram Messenger*, Viber, VK, WeChat, WhatsApp, Yandex etc. use XMPP.
* TG: We know you are using the PubSub (XEP-0060: Publish-Subscribe) for your so called “channel” interface.
Even 1&1, CIA, FBI, FEMA, NSA, Federal Council (Swiss Confederation), New York City Hall and even more use XMPP.
XMPP is relevent. XMPP is popular.
I often reject clients in case they refuse to make use of XMPP, after I know they are aware of it.
P.S
URL Directory?
AudriusButkevicius, I do not know how did you find this link, and if it was via a corporate URL directory (i.e. “search engine”), then you should know that corporate URL Directories are not automatic as some want us to believe. They censor results, be it due to political concerns or business concerns or what ever other concern.
By the way, did you notice that the promoted videos on YT are those who are featuring the Dooble search engine? If you have a better video, and you are featuring SearxNG, YaCy or another service, then your video will be hidden from result.
Sponsored Propaganda
Since when “Daring Fireball” - which has turned into a publication due to “its markdown instructions” - propagates contents about XMPP, and why a discouraging content?
Did you know that “Daring Fireball” publishes contents upon payments from corporations?
Could it be that “Daring Fireball” was paid by a corporationor intelligence agency to refer to a discouraging article in order to discourage people who use XMPP and consequently potential developers and projects which XMPP could be integrated into.
Could it also be that the intelligence agency which is located just a block away from me (less than 1000 meters) has paid to “Daring Fireball” (probably via a proxy) to promot that article in order to discourage XMPP and indirectly promote its low-quality pesudo-privacy and pesudo-decentralized metadata-disaster protocol?
Yes, it could be.
Here is a nicer article about XMPP.
My post which included important questions in a “postscript” note has been censored (hidden) by Akismet.
I was in the middle of editing it.
Please advise
EDIT: Content has been restored. Thank you Administrator!
I released it from the spam queue and deleted the duplicates, but I can see why Akismet was concerned…
I do not know.
This is what happened.
After I have received “Error 422”, due to attempting to post serveral links, I have encapsulated XMPP | About to preformatted text so I could post the last link of my post.
While I was in the middle of it, Akismet was triggered.
I don’t really see a future where the sync protocol runs over xmpp, whatever that means, but I could see the utility of using it for discovery and authorisation.
could see the utility of using it for discovery and authorisation.
Thank you. This is exactly what I was thinking about.
I still don’t understand the problem that we’re trying to solve here. Existing discovery mechanism works. What is the definition of the problem that this is trying to solve?
I presume, add a “device” jakob@example.com/laptop or whatever instead of my long device ID, and the actual exchange of device IDs happen in the background over that protocol. But that’s just what I imagine could happen, all of the details would be up to someone else, I’m not going to try to implement this. 
I do not want to use the relays Syncthing currently offers.
I want to use an XMPP server instead, be it mine or someone else’s XMPP instance.
Yes, especially that.
I am good with it, as long as we have an understanding of the objective matter.
If you don’t want to use relays don’t use them. You wanting to use xmpp for that is a you problem, not a general problem, hence not certain it needs solving.
If you want “more xmpp” out of syncthing, I think the best way to approach this would be to build a separate application which translates xmpp to syncthing rest calls, or a thing that exposes relay protocol and translates it to xmpp.
That also could be a solution.
I think you should read up a bit on how Syncthing actually works:
Understanding Device IDs — Syncthing documentation (They are tightly coupled to the underlying BEP protocol and its TLS layer, providing not only identification, but also authentication.)
Specifications — Syncthing documentation (Should make sense to you since you’re a developer. Just to give you some details on concrete integration points where XMPP might be “integrated”.)
And in general I agree that the actual problem is under-defined. You seem to be advertising a hammer while searching for a nail, and Syncthing might just have nuts and bolts. That’s why it’s so important to understand the parts involved with Syncthing first. Relaying, discovery, authentication, authorization are all solved in some way currently. It certainly doesn’t make sense to suggest XMPP to augment or replace our relaying capability when it’s not actually a good fit.
So I keep coming back to the “User story”, which it seems is not clearly formulated in your head yet. Like this: “Schimon and André are chatting through their favorite XMPP messenger. Schimon wants to send his new video clip draft, which is too big for email. He doesn’t want to use XMPP’s file transfer capability (why?). So he opens a browser for his Syncthing instance and grabs his device ID, via two clicks (Identification, Copy) and pastes it into the chat conversation. André then needs to …”
Now how does that story change when XMPP is involved on a technical level?
Not even mentioning that André might not have Syncthing installed at all, so the bigger question is how to point him to downloading the right package, install it (does he even have permission to run arbitrary software on his computer?) and get it set up in order to extract his own Device ID.
Or are you actually thinking of a button within Syncthing’s GUI to “Send via XMPP” a single file from a shared folder or “Invite Device via XMPP”?
I’m not at all opposed to your ideas. We just need to be on the same page where you want to be heading, before we can discuss in which way and on what level any technological changes make sense.
I’d rather like to see address exchange via BEP implemented, coupled with Remember previously used / discovered device addresses and retry them · Issue #3474 · syncthing/syncthing · GitHub