mastodon - Link to source
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.
#xmpp #activitypub
in reply to Wolf480pl

mastodon - Link to source

Daniel Gultsch

@wolf480pl yes I think that is a huge part of the problem. It is very easy to completely underestimate the complexity of Instant Messaging. Sending a message from A to B seems like something every software developer can write before lunch and people don’t see how it can and will rapidly escalate from there.

But I don’t know how do communicate that to other people.

@Wolf480pl
in reply to Daniel Gultsch

mastodon - Link to source

Daniel Gultsch

I consider this a failure on our part but I don’t really know what to do about it. Most arguments against #XMPP don’t hold if you’re building from scratch anyway:

• #Conversations_im looks very outdated: OK, but you are developing your own clients anyway.

• XMPP doesn’t have an SDK: Neither does your #ActivityPub or email stack

• OMEMO is insecure and I would prefer #MLS: Yes, let’s work on that together and you’ll still benefit from XMPP’s 100+ solved IM problems.

#xmpp #activitypub #MLS #conversations_im

Štěpán Škorpil reshared this.

in reply to Daniel Gultsch

mastodon - Link to source

Debacle

IMHO, the point of both Delta and the new ActivityPub based chat (does it have a name yet?) is prevalence, at least in a certain part of society.

I remember, that Delta proponents said, that "you can reach everyone, who has an email address."

Now it is: "You can reach everyone, who has a fediverse account."

In the end, it is not that easy, e.g. because email users might not have autocrypt in their client, and it will take a while until there is #MLS in e.g. #mastodonEl.

#MLS #mastodonel
in reply to Daniel Gultsch

mastodon - Link to source

Johannes Brakensiek

The big plus of #DeltaChat is that the infrastructure is already there. Infrastructure is a big part of the problem. And obviously using mail for that is only for people born before 2000.

Second is branding: When people hear #XMPP they hear 20 years of failure of implementing robust solutions both server-side and client-side. People just don't know that after 20 years there now are server and client solutions really working.

#xmpp #deltachat
This entry was edited (4 days ago)
in reply to Johannes Brakensiek

mastodon - Link to source

Delta Chat (39c3)

#XMPP is still a thriving ecosystem with lots of good FOSS developers doing interesting things.

XMPP is also used under the hood in tons of products needing instant messaging even if they are not advertised as XMPP clients, or do not federate.

Anyway, XMPP and #matrix all share a strong focus on protocols, but there is a big difference: chatmail.at does not expose protocols to client developers, just a Rust SDK.


Chatmail

Chatmail provides FOSS infrastructure for interoperable, secure, speedy and reliable end-to-end encrypted messaging. Check out clients as Arcane Chat, Bots or Delta Chat today!
chatmail.at
#xmpp #matrix
This entry was edited (1 day ago)
in reply to Delta Chat (39c3)

mastodon - Link to source

pixelschubsi

It's funny how the thing you came up with where DeltaChat is different, is that it presents itself a Rust SDK rather than a protocol to client developers.

@daniel literally wrote about this "I don't like existing SDKs" topic above.

What remains is that before you created the SDK on top of a protocol that wasn't XMPP, it didn't exist either. Had you created the SDK on top of XMPP, it would still use a better protocol for the job and you would still have the SDK you just promoted.

@Daniel Gultsch
This entry was edited (3 days ago)
in reply to pixelschubsi

mastodon - Link to source

pixelschubsi

@delta I understand there is a sunken cost situation now: You invested a lot of time and resources to build on top of a sub-optimal protocol. So it would be a wasted effort to migrate everything to XMPP and thus I'm not expecting you to admit XMPP would've been the wiser choice over IMAP+Submission (for C2S) and SMTP (for S2S).
@Delta Chat (39c3)
in reply to pixelschubsi

mastodon - Link to source

Delta Chat (39c3)

@pixelschubsi It's probably true that abstractly, Delta could have used XMPP as an underlying protocol instead of email, or IRCv3 :) But the reality of how projects evolve is much more complex than just this protocol detail. In any case, things are how they are now. Delta could evolve to have XMPP transports, or some XMPP folks do a friendly fork of all Delta UIs and glue it to xmpp-backends. We'd be supportive of either, but can't do that work ourselves.
@pixelschubsi
in reply to Dragos Pirvu

mastodon - Link to source

Daniel Gultsch

@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.
@The Matrix.org Foundation @Delta Chat (39c3) @Johannes Brakensiek @Dragos Pirvu
in reply to Daniel Gultsch

mastodon - Link to source

amackif

not an expert here, but someone who despises matrix based on user experience.

It's not about the protocol itself. It's a bit about people hating dealing with xpath (me included). Json has one of the three: a value, an array or a dict.

If you want xmpp to be accepted, then you need to provide two things:

1. Sexy client, both web and mobile for user acceptance
2. Nice way to deal with payloads aka SDK for devs

Two more things: single binary deployment for server and e2e encrption

in reply to Daniel Gultsch

mastodon - Link to source

famfo

some things that come to mind is
* crypto with cross signing and proper device management, some clients also implement omemo 8 while the rest doesn't
* more aggressive compliance levels, some clients support for example rich replies, which are nice to have, and stickers which do not have a fallback as far as I know
* a better way to show clients on the xmpp.org website, I don't think that yhe average person will know about what core and IM is
in reply to Daniel Gultsch

mastodon - Link to source

Ulrich Popp

I think it is a bit the same problem like with Linux: Too much freedom: Which distribution? (what is a distribution?) which desktop?
In XMPP: Which client? Does it have OMEMO? Which server? How to register?
Whatsapp: This app, Your number, give us all rights to fuck you up, okay, finished.
Telegram more or less the same
Signal also only one app.
More freedom means more possibilites means more complicated and more confusion for first time users.
in reply to Daniel Gultsch

mastodon - Link to source

Dawn Ahukanna

Q1.Is there a spec?Found this- xmpp.org/about/technology-over…. Why is this not included in w3c with the other OSI layer-7 application protocols?
Q2. How do I use it? People using the tech (tool) don’t choose between OSI layer-7 application protocols, they choose tool that does a job/outcome they need done I.e. I want to send a “text message” to someone, whose contact details I have. I don’t want to be insulted or abused by strangers using or producers of tool.
Q3. SDK? No. Code something.

An Overview of XMPP | XMPP - The universal messaging standard

XMPP is the Extensible Messaging and Presence Protocol, a set of open technologies for instant messaging, presence, multi-party chat, voice and video calls, collaboration, lightweight middleware, content syndication, and generalized routing of XML …
xmpp.org
in reply to Tris

mastodon - Link to source

Daniel Gultsch

@tris two things: I already said in my follow up post that if someone wants to build their own clients on top of XMPP and prefers MLS over OMEMO, the XMPP community is very open to that. A protocol is much more than just the encryption. They would still benefit from all the other things XMPP has solved.

A lot of what's in that blog post is ill-informed and bordering on disinformation and fear mongering.

@Tris

Daniel Gultsch reshared this.

in reply to Tris

mastodon - Link to source

Daniel Gultsch

@tris there are three actively developed protocols for federated instant messaging (XMPP, Matrix, Deltachat). At least one of them is very open to new developers and new ideas and has a structure in place to collaboratively work on those ideas and bring various stake holders together. With no disrespect to that individual I don't see why there needs to be a forth protocol loosely based on ActivityPub.
@Tris
in reply to Daniel Gultsch

mastodon - Link to source

Daniel Gultsch

@tris Soatak is an expert in cryptography. I’m not. I’m more than happy to stand on the shoulder of giants when it comes to E2EE. That’s why we used the Signal Protocol 10+ years ago for #OMEMO and are now looking towards #MLS. However, good, interoperable protocol design is so much more than just E2EE. And maybe I've learned a thing or two about protocol design in my career that they don’t necessarily know.
#omemo #MLS @Tris
in reply to Daniel Gultsch

mastodon - Link to source

pixelschubsi

I'm also genuinely surprised that people believe that ActivityPub, a protocol even named after its purpose, to publish activities, is a good protocol to pursue private instant messaging. The goals of those two couldn't be more detrimental.

I do see a purpose of being able to reuse your "ActivityPub identities", which actually are just WebFinger identities. Maybe someone should specify how to discover XMPP accounts via WebFinger and push that as a solution for AP messaging?

This entry was edited (1 day ago)
in reply to Daniel Gultsch

nodebb - Link to source

julian

Re: As a community, we often ask ourselves how to attract more users to #XMPP.

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:

  1. Messages can get sent via AP :heavy_check_mark:
  2. 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@gultsch.social @pixelschubsi@troet.cafe

in reply to julian

mastodon - Link to source

Daniel Gultsch

@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.
@pixelschubsi @julian
in reply to Daniel Gultsch

mastodon - Link to source

Tris

I think the idea is to bring E2EE DM in Fediverse. X did bring E2EE in X chat (spoiler: it was disastrous, see: blog.cryptographyengineering.c…). IIRC, @filippo was working on E2EE chat on AT proto (Bluesky).

A bit more on Twitter/X’s new encrypted messaging

Update 6/10: Based on a short conversation with an engineering lead at X, some of the devices used at X are claimed to be using HSMs. See more further below. Matthew Garrett has a nice post about T…
A Few Thoughts on Cryptographic Engineering
@Filippo Valsorda
in reply to Daniel Gultsch

mastodon - Link to source

Tris

github.com/legastero/stanza looks cool. If I get time someday I might or might not make a silly XMPP server implementation in gleam.run/ for fun. Not sure anyone is fan of it. Probably @soph is xD

GitHub - legastero/stanza: Modern XMPP, with a JSON API

Modern XMPP, with a JSON API. Contribute to legastero/stanza development by creating an account on GitHub.
GitHub
@Sophia J. Turner
Unknown parent

mastodon - Link to source

Daniel Gultsch

@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.
@silverpill @pixelschubsi @Tris
in reply to Daniel Gultsch

mastodon - Link to source

cake-duke

One of the issues that I see with XMPP is that everything feels half broken. There's so many clients, they implement a non-overlapping set of features, and it gives the whole thing a broken or unpolished feel. I run Gajim on desktop and Conversations on mobile, and yet once a week or so I see something that makes me go "huh I wonder what happened there". It's a constant mental burden having to try and figure out what the clients are doing that would explain the observations.
⇧