As a community, we often ask ourselves how to attract more users to #XMPP.
General Discussion
35
Posts
16
Posters
4
Views
-
@pixelschubsi @tris Yes, agreed. Tremendous value in reusing identities and login credentials. Big skepticism with regards to using AP as a protocol. One can probably kinda make it work… But why? What’s the benefit?
@daniel @pixelschubsi @tris The benefit is in having a single account for all types of online communication.
-
@pixelschubsi @tris Yes, agreed. Tremendous value in reusing identities and login credentials. Big skepticism with regards to using AP as a protocol. One can probably kinda make it work… But why? What’s the benefit?
To preface — I'm in agreement that ActivityPub probably isn't the best protocol to use for instant messaging. There's a lot of FUD still being spread about XMPP and I am outside of most of those discussions. NodeBB only supports AP at current.
That said, there's interest in pursuing AP as a delivery protocol for instant messaging because integrating a separate protocol is a heavy lift for everybody involved. It's a heavy lift if you already support AP, and it's a heavy lift when you support no federating protocols at all. Imagine a site looking to federate... now they have to use AP+XMPP? AP+Delta? etc...
Setting aside all the existing reasons why AP isn't ideal, I will say this... It clears the baseline expectations:
- Messages can get sent via AP :heavy_check_mark:
- Messages can be privately addressed via existing AP addressing mechanisms :heavy_check_mark:
That's it. The rest is icing. Really important icing, but for 99% of conversations, icing.
-
@daniel @pixelschubsi @tris The benefit is in having a single account for all types of online communication.
@silverpill @pixelschubsi @tris you can have a single account (or as I phrased it 'identity and login credentials') across different protocols.
For example your Google account works across multiple protocols. And even in the federated world we have several cases where email address == xmpp address.
So to repeat myself: using the same identity is good. Doesn't mean you are locked into ActivityPub if you want to build instant messaging. -
@julian @daniel I'm looking at it from a different perspective. IMO the Mastodon server (as an example) doesn't need to implement XMPP itself (it could, but it doesn't need to). Just like it doesn't implement HTTP itself.
It could instead rely on existing implementations. Take an existing XMPP server, reverse proxy its websocket endpoint, use the existing Mastodon auth to sign in, and embed an existing XMPP web client in the web frontend.
-
@julian @daniel I'm looking at it from a different perspective. IMO the Mastodon server (as an example) doesn't need to implement XMPP itself (it could, but it doesn't need to). Just like it doesn't implement HTTP itself.
It could instead rely on existing implementations. Take an existing XMPP server, reverse proxy its websocket endpoint, use the existing Mastodon auth to sign in, and embed an existing XMPP web client in the web frontend.
@julian @daniel so in practice it would probably be the other way round: that heavy lifting you're rightfully afraid of has already been done and even the large tail of the remaining 20% (that in reality need 80% of the effort) are largely done.
If we were to agree to go the XMPP route, we could have fully-featuered deployment-ready implementations of instant messaging on top of AP identities in weeks to months. If it's something entirely new on top of AP, it's going to take years.
-
@julian @pixelschubsi I understand the instinct of wanting to reuse the parts you already have. Protocol parsing, identities, profiles etc. However those will very quickly become extremely minor building blocks in the complexity of instant messaging.
It's very easy to underestimate the scope and feature creep of IM. I've seen this happening in other places where people initially think that IM is just passing some messages around. And then users demand more features and then you reinvent XMPP. -
@julian @pixelschubsi I understand the instinct of wanting to reuse the parts you already have. Protocol parsing, identities, profiles etc. However those will very quickly become extremely minor building blocks in the complexity of instant messaging.
It's very easy to underestimate the scope and feature creep of IM. I've seen this happening in other places where people initially think that IM is just passing some messages around. And then users demand more features and then you reinvent XMPP.@daniel@gultsch.social absolutely, the same naive expectations happen often when people think forums are easy to build :smile:
@pixelschubsi@troet.cafe is definitely on to something about re-using an existing XMPP server in order to avoid the heavy lift. The less the maintenance burden for me, the better as far as I'm concerned.
-
As a community, we often ask ourselves how to attract more users to #XMPP. Yet the real tragedy is that people would rather build something entirely new (loosely based on email or #ActivityPub) than consider XMPP. Need end-to-end encryption by default? If compatibility with existing XMPP clients is a secondary concern, you can implement it in your own solution while still benefiting from our two decades of experience in instant messaging.
@daniel I was just checking out the Wikipedia page, thanks for the pointer. … does it work well peer to peer? Identifies seem to be tied to a domain?
-
@daniel I was just checking out the Wikipedia page, thanks for the pointer. … does it work well peer to peer? Identifies seem to be tied to a domain?
@benjohn it's not a peer to peer protocol. It's federated - meaning you can pick a provider - like email or the Fediverse.
-
As a community, we often ask ourselves how to attract more users to #XMPP. Yet the real tragedy is that people would rather build something entirely new (loosely based on email or #ActivityPub) than consider XMPP. Need end-to-end encryption by default? If compatibility with existing XMPP clients is a secondary concern, you can implement it in your own solution while still benefiting from our two decades of experience in instant messaging.
@daniel It would be great if #xmpp community was better represented in various social networks. For example, there's no #conversations_im account in mastodon.
-
@daniel It would be great if #xmpp community was better represented in various social networks. For example, there's no #conversations_im account in mastodon.
@ag1km Well you found my profile. Hi. Welcome. I post a lot on under the hashtag #Conversations_im.
There is also @xmpp
-
@dragospirvu75 @matrix @delta @lazarus The way to achieve interoperability is to stop reinventing the wheel and agree on one standard. Implementing three protocols is completely unfeasible and unnecessary. This worked 20 years ago with MSN, ICQ and AIM when IM protocols had a lot less features and no E2EE. Doesn’t work today.
xmpp is not "one standard" it's an extensible mess and no two people use the same client/server combination, leading to some kind of factorial explosion of mutually incompatible software. there are over five hundred XEPs and any given project has a unique view of which ones are "necessary" and which are "supported" and which are "deprecated" and which ones you should go to jail for even reading.
xmpp has xeps for systems administration, internet of things shit, service discovery, and a million other things that should never have been shoved into a chat protocol, while the xeps that are intended to fix the actual issues that affect users are "deferred" because it's a hell of a lot easier to invent an entire new use case for xmpp than it is to fix any problems with existing xeps.
this, combined with the excessively verbose markup, means that starting from scratch has two incredibly attractive benefits: one, you don't have to learn this tremendous bureaucratic protocol maze, and two, just about any wire format you can think of is going to perform better than xmpp over slow or intermittent network connections, which are the majority of internet connections.
-
xmpp is not "one standard" it's an extensible mess and no two people use the same client/server combination, leading to some kind of factorial explosion of mutually incompatible software. there are over five hundred XEPs and any given project has a unique view of which ones are "necessary" and which are "supported" and which are "deprecated" and which ones you should go to jail for even reading.
xmpp has xeps for systems administration, internet of things shit, service discovery, and a million other things that should never have been shoved into a chat protocol, while the xeps that are intended to fix the actual issues that affect users are "deferred" because it's a hell of a lot easier to invent an entire new use case for xmpp than it is to fix any problems with existing xeps.
this, combined with the excessively verbose markup, means that starting from scratch has two incredibly attractive benefits: one, you don't have to learn this tremendous bureaucratic protocol maze, and two, just about any wire format you can think of is going to perform better than xmpp over slow or intermittent network connections, which are the majority of internet connections.@khm I've been doing this for a decade and you are incorrect.
XMPP works over incredibly slow links to military submarines and even a vanilla Conversations works absolutely fine on high latency low bandwidth 2G connections.
I've you look at the 10 most actively developed clients and servers you can see that their developers are mostly in agreement over what XEPs are currently considered best practices (Source: I know all 10 of them personally)
Gli ultimi otto messaggi ricevuti dalla Federazione
-
Is there interest in starting up a new server? I am incentivized to provide something for this niche (or perhaps not-so-niche) part of the fediverse.
It would be a forum. Running NodeBB. Not Mastodon.
As I understand it, the med-mastodon server shut down without warning. I don't know any other way to reach those users. Please boost for visibility 🙏
-
@julian that's great, I really appreciate it!
-
@ricci@discuss.systems we will implement and ping back when ready. Likely for v4.9.0
-
HI @nighthawk, Surf is an app (currently in beta) that allows you to create topical feeds that include social posts (fediverse, Bluesky, Threads) and RSS, podcasts, YouTube and Flipboard Magazines. You can create an account and log in with your Mastodon or Bluesky handle, and then interact with posts on either platform directly from Surf. If you decide to sign up for the beta, do let us know the email address you used, and we'll try and get you right in!
-
@silverpill @julian @general @dansup Thanks! I added a check for this to my analysis code, and it does seem to be a simple and straightforward solution to nodeinfo in NodeBB
-
@fediverso Please could you message us the email address you applied with and we'll try to get you right in?
-
@surf what is it??
-
@surf ugh! It's been over a year since I applied... 😞
