Atom Over XMPP: XMPP (RFC 6120), PubSub (XEP-0060) and Atom (RFC 4287)

[sjehuda]

Greetings!

My name is Schimon and I am a champion of Syndication and XMPP.

For those of you who are not famiiliar, XMPP (previously Jabber) is a messaging system with open standards. XMPP is extensible via XEP.

I will discuss about XEP-0060: Publish-Subscribe.

Almost a couple of decades ago, a discussion arose about incorporating Atom (RFC 4287) with XMPP PubSub, which is really easy because both are XML data.

One of the major benefits of utilizing PubSub is native Push Notifications (yes, that technique was much before HTML5) which do not require HTTP pulling.

That would be a great feature to have selfoss to utilize XMPP PubSub natively!

See a proof of concept I have made to parse PubSub nodes as Atom Syndication Format.

https://datatracker.ietf.org/meeting/66/materials/slides-66-atompub-1.pdf
https://codeberg.org/poezio/slixmpp/issues/3526

Cheers,
Schimon

[jtojnar]

Hi, thanks for the suggestion.

Does not XMPP require persistent connection to listen for incoming messages? That is not generally something regular PHP is well suited for.

What are the benefits compared to WebSub (previously PubSubHubBub)? WebSub is a W3C standard, widely implemented (including Wordpress and Blogger) and apparently uses WebHooks, so it does not require the feed reader to be persistently running.

[jtojnar]

Looks like the IETF draft expired: https://datatracker.ietf.org/doc/draft-saintandre-atompub-notify/

[sjehuda]

Looks like the IETF draft expired: https://datatracker.ietf.org/doc/draft-saintandre-atompub-notify/

Thanks for the link!

The formal implementation is XEP-0472: Pubsub Social Feed (experimental) which is implemented by Libervia, Movim and Slixfeed.

---

selfoss to receive data from XMPP

Atom Over XMPP is incorporating two standards and is implemented very nicely on Movim (XMPP client system based on PHP).

Does not XMPP require persistent connection to listen for incoming messages? That is not generally something regular PHP is well suited for.

1. You can start and close XMPP client for pulling updates from nodes
2. You might be able to keep a persistent login (Single Session Support) with xmpp-php.

Subscribing to nodes and keeping a persistent connection to listen for incoming stanzas is the preferred fashion to realize "pushing" as intended.

What are the benefits compared to WebSub (previously PubSubHubBub)?

I do not know.
To me, XMPP is another source with structured data (Atom Syndication Format) to get news from.
I also rarely use web browser, only Feed Reader and XMPP.
I am also biased towards the "web", "http" and other shenanigans made by big corporations and encouraged by intelligence agencies to invade our privacy.

selfoss to send data to XMPP

Another benefit that selfoss may have is to populate nodes and by that turning selfoss into a publishing software for XMPP.

Storing data on XMPP would be beneficial for people who use XMPP without a feed reader such as selfoss.

People who use XMPP will be able to view news aggregated by selfoss to be viewed from their own clients like Movim and Libervia.

Use case: I want to share news with friends of my groupchat, so I set selfoss to send news items of a given feed or selected feeds to node urn:xmpp:microblog:0 of groupchat xmpp:syndication@conference.movim.eu?join.

[sjehuda]

What are the benefits compared to WebSub (previously PubSubHubBub)?
[...] so it does not require the feed reader to be persistently running.

Please explain.

In XMPP, you get notified when you are connected again, including receiving all messages (private and groupchat) from when you were disconnected.

This is a realization:

00:00 selfoss connects
00:10 selfoss subscribes to Node A
00:20 selfoss disconnects
00:30 Node A sends an update to selfoss
03:30 Node A sends an update to selfoss
06:30 Node A sends an update to selfoss
09:20 selfoss reconnects
09:20 selfoss receives the updates of Node A which were sent to its JID (Jabber ID) at 00:30, 03:30 and 06:30 
09:30 Node A sends an update to selfoss
09:30 selfoss receives the update

Another benefit over HTTP would be this:
Because PubSub nodes have permission management system, the JID used by selfoss would be used as an identifier to allow or deny access to node, instead of setting a password protected HTTP server which requires entering or storing passwords.

[jtojnar]

selfoss to receive data from XMPP

1. You can start and close XMPP client for pulling updates from nodes

Then it would just become pull with more steps.

2. You might be able to keep a persistent login (Single Session Support) with [xmpp-php](https://github.com/pbxapi/xmpp-php).

Unfortunately, the library looks pretty dead and so do other PHP XMPP llibraries.

And from the look of it, it actually does not implement XMPP, only Prebind authentication and REST API of OpenFire XMPP server. (Prebind, from what I managed to find, is an authentication method that allows using tokens for successive authentications instead of username/password.)

Subscribing to nodes and keeping a persistent connection to listen for incoming stanzas is the preferred fashion to realize "pushing" as intended.

Right, that was what I assumed. But classic PHP works by running a fresh instance of PHP script for each HTTP request so there are no long lived app processes. Having a persistent connection would require creating a daemon, e.g. using something like ReactPHP or some other similar framework, which would not work everywhere selfoss aims to work (e.g. shared web hosts). We could fall back to polling when daemon is not available but that adds complexity.

I am also biased towards the "web", "http" and other shenanigans made by big corporations and encouraged by intelligence agencies to invade our privacy.

In the end, we want to support protocol if it benefits our users. That also require for it to be widely deployed. And WebSub appears to be used https://indieweb.org/WebSub

---

I think it would be nice to support reading data from XMPP to allow following services that do not support Web standards (as appears to be the case with Movim) but it sounds like a lot of work so I probably will not implement it unless there is someone actually interested in using it in selfoss.

We would need to find a maintained XMPP library for PHP or write our own.

Apparently, the one used by movim is abandoned and only continues to be developed internally. It is also pretty big, uses a global function for sending messages (which would make it annoying to integrate and test), and uses an incompatible license.

For writing our own, it is not clear what would the minimal set of XEPs we would need to support is.

selfoss to send data to XMPP

Another benefit that selfoss may have is to populate nodes and by that turning selfoss into a publishing software for XMPP.

Again, this is something that would be a lot of work to implement and maintain, and it is not clear anyone would actually benefit from it. XMPP is unfortunately pretty niche nowadays.

Please explain.

In XMPP, you get notified when you are connected again, including receiving all messages (private and groupchat) from when you were disconnected.

Yeah, that would work, even if it not the preferred method, as you mentioned.

Because PubSub nodes have permission management system, the JID used by selfoss would be used as an identifier to allow or deny access to node, instead of setting a password protected HTTP server which requires entering or storing passwords.

I would argue you would still need to store the JID, and there is not much difference between that and a password if the server is using best practices for passwords (strong unique password for each consumer, easy to revoke) but I acknowledge that is not always the case.

[Neustradamus]

To follow this important request :)

[sjehuda]

@Neustradamus I also think that it is important request, yet @jtojnar has good arguments which put me in an embarrassing position.

I think we first have to find a solution for a generic and standalone php library for XMPP, similar in nature to slixmpp which would provide at least a basic set of commonly utilized XEPs.

P.S. Thinking of it and the common use of PHP, an XMPP library for PHP would definitely make an opportunity to showcase a set of sample interactive HTML interfaces.