Support for Serverless Messaging (XEP-0174)

[kdohmann]

I would like to see support for XEP-0174 in libstrophe for establishing a serverless XMPP connection. I am also willing to implement this feature, but since its implementation goes to the basics in connection setup, I would like to discuss this first to avoid double work.

Basically XEP-0174 works like this:

• node A opens a port and exposes its Serverless XMPP capability via mDNS
• node B connects to this port and sends <?xml> and tags
• node A also sends <?xml> and tags
• connection is now already set up and XMPP communication between both nodes can be done

I definitely do not see the mDNS part as a task for libstrophe, I would only concentrate on the connection stuff here. Also, when implementing a listening port, there is not much work anymore to build the foundation of a XMPP server.

My first approach is implementing two new functions:

int xmpp_listen_serverless(xmpp_conn_t * const conn, unsigned short altport, xmpp_conn_handler callback, void * const userdata); for node A and

int xmpp_connect_serverless(xmpp_conn_t * const conn, const char * const altdomain, unsigned short altport, xmpp_conn_handler callback, void * const userdata); for node B.

One of those functions is called instead of xmpp_connect_client(...);. They would return with a connection or a connection failure.

This is easy to implement and would fulfill the requirements for XEP-0174.

The drawback I see at the moment:

• Two new API functions are created. As far as I interpret comments on other changes, API changes should be as minimal as possible.
• The xmpp_listen_serverless(...) function opens the listening port, accepts the connection and closes the listening port. The overhead of not reusing the listening port is the cost for not introducing even more functions. This can be acceptable if you do not expect many connections.
• A XMPP server cannot be build with this.

A different approach would be to some kind of all-in-one xmpp_connect(..) which would get as parameters:

• listening or connecting
• stream features negotiation
• auth parameters
• ...

Any comments on what would be desirable, and what would be accepted upstream?

[pasis]

@kdohmann, look at xmpp_connect_raw() (as example, 39c36a45f38b4a0587ccc79a55735e409cfb524f) and branch https://github.com/strophe/libstrophe/tree/server. Maybe something can be reused or implemented in such a way to have all the features in the future.

I implemented the raw connection to be able to write in-band registration, serverless messages, etc. But the interface became quite ugly and overcomplicated. Maybe you can do better job by implementing serverless communication inside libstrophe instead.

Also it seems that you will need features from a server support. Like features negotiation, establishing TLS, etc. Maybe you can work on full server support in libstrophe too (check the server branch)?

Your request sounds interesting since the next release of libstrophe is going to be a major release.

Regarding accepting to the master, I'm happy to merge the implementation if it will be a good quality and won't break existing functionality.

[pasis]

I guess xmpp_conn_handler callback is not enough for xmpp_listen_serverless(). You will need to accept newly created xmpp_conn_t object, then handle events that are not compatible with XMPP_CONN_CONNECT and similar.

To follow original libstrophe simplicity, I would recommend to implement TLS, features negotiation, authentication inside libstrophe and the server object would generate events like:

• XMPP_SERVER_ACCEPT - here user can inspect parameters of the new conn object and close connection for example.
• XMPP_SERVER_AUTHENTICATED - everything is negotiated and authenticated, user can register handlers, send and receive stanzas.
• etc

[kdohmann]

Thank you for your hint on the server branch. I want to give you a note on what I have done so far. Progress is slower that I want, because my daytime job consumes too much time.

I have a working prototype for serverless messaging. On the other part, the server functionality, I also have some progress. PLAIN authentication also works, TLS is the next step for me.

Most of my server work is done for now outside the library itself, but I think for the next step, TLS, I need to move functionality to the library first.

[pasis]

Thank you for your hint on the server branch. I want to give you a note on what I have done so far. Progress is slower that I want, because my daytime job consumes too much time.

I completely understand what you're talking about! :) Don't worry and take your time.

I have a working prototype for serverless messaging. On the other part, the server functionality, I also have some progress. PLAIN authentication also works, TLS is the next step for me.

Most of my server work is done for now outside the library itself, but I think for the next step, TLS, I need to move functionality to the library first.

If you have the code in some branch - I can take a look and maybe give some hints.

[psjbeisler]

any update on this?

[hhartzer]

This sounds like a great idea! I'm also curious if there's been any movement on this.

[Neustradamus]

Any progress on it?

[sjehuda]

Any progress on it?

Why was this comment marked as spam?

• This feature is crucial;
• It appears that only a handful of XMPP developers are aware of it, and it is a miracle that we have @Neustradamus with us to ecourage it.
• Because people are not aware of it, they refer to their own non-standard implementation. croc, localsend, sharik which on the short and long term is more expensive and lesser sustainable than implementing XEP-0174;
• Implementing XEP-0174 would ensure the continuation of projects that support XEP-0174.

Other critical reasons to support XEP-0174.

1) In case of suspension of operation of telecommunication infrastructure (i.e. "outage"), LAN/Mesh networks with this feature would be essential. 2) Privacy wise for communications of inside a building (e.g. in case you are intelligence, military, or a business company etc. 3) Easy file sharing (see projects mentioned above). 4) Do you have a big very house? Are you an aristocrat? Then XEP-0174 would be for you!

---

Gentlemen, even Profanity awaits for libstrophe to bring forth XEP-0174.

This is critical which makes it a surprise that only @hhartzer and @Neustradamus have commented on this ticket recently.

[jubalh]

Why was this comment marked as spam?

Because it doesn't add any value and all XMPP projects get such pings from him regularly. People have limited time, energy.

Gentlemen, even https://github.com/profanity-im/profanity/issues/635 awaits for libstrophe to bring forth XEP-0174.

We are the same people. So we are aware of Profanity tickets..

This is critical

If this is critical to you then you can contribute the code. Or offer to sponsor the implementation of it.

Opening tickets or saying "I need this!" is not magically creating the conditions necessary for the feature to be implemented.

Privacy wise for communications of inside a building (e.g. in case you are intelligence, military, or a business company etc.

Right! The military and companies around the world that want to get work done for free by volunteers around the world without paying them for it. Love it.

[sjehuda]

I do not endorse the military. I was making a point of the importance of this feature.

[jubalh]

You misunderstand open source. Open source is not here so that people can make demands and expect others to implement it.

We are all working here together to have a project that everybody can use. If someone wants a certain functionality they can implement it and everybody benefits. If a maintainer has time and fun or any other motivation to implement a task then they can do it.

But this issue tracker isn't our personal to do list where people can demand things to be solved for them and then harass us when something isn't implemented.

I was maaking apoint od the importance of this feature.

The importance for you.

[sjehuda]

The importance for you.

Yes. Indeed.

---

I mostly work on Python projects recently.

I will consider making an effort to add this feature to libstrophe, either by helping to add this feature or by receiving instructions from people of this project.

Do not wait for it.