A messaging service that requires 24/7 internet connection and defaults to plain-text.
It's defective by design, MIM attacks are the least of it's worries


Which messaging services require 24/7 internet connection? Only IRC, right? #Jabber #XMPP does not and never did, AFAIK.

@chrisbodol @wuwei no Service requires 24/7 connectivity.
It really depends on your expectations though. Do you want to receive messages while not being online? Does something store the messages for you while not being connected?

Btw: I run biboumi xmpp<>IRC bridge... So still get all the IRC while I'm offline 😁

@aslmx @chrisbodol
XMPP does not by default bounce you messages if you're offline, kinda like IRC yeah.
Many servers today do that service for you but that's their additional service, not all do it and most who do it don't do it reliably.

@wuwei @aslmx

If a server does not work reliably, I suggest that you contact the admin to fix it. I'm offline a lot, i.e. not connected to the internet all day long, and #Jabber #XMPP just works.

@chrisbodol @aslmx
That means your admin implemented a third-party service to adress that properly.

Nothing wrong with that, I just preffer to have basic stuff like that implemented in my messaging protocol so I don't have to worry about if it's working or not and does my admin provide such service

@wuwei @aslmx @chrisbodol RFC6121 explicitly states that such messages should be stored for offline delivery: "Some delivery rules defined in this section specify the use of "offline storage", i.e., the server's act of storing a message stanza on behalf of the user and then delivering it when the user next becomes available." (xmpp.org/rfcs/rfc6121.html#rul) so it's part of core specification.

As for "default to plain-text": STARTTLS required is virtually ubiquitos nowadays and is considered "default".

@tigase @aslmx @chrisbodol
"If all of the available resources have a negative presence priority then the server SHOULD either (a) store the message offline for later delivery or (b) return a stanza error to the sender, which SHOULD be <service-unavailable/>."

If I got this correct sending just an error code is also ok, might be very wrong.

Also this standard is defining just the extensions to the core protocol, different serves are in different stages of implementing non-core funcionality

@wuwei @aslmx @chrisbodol Yes, it's "OR" conjunction so returning an error is also an option but:
1) you would know if the recipient wouldn't get your message
2) I don't know any server that would do that nowadays.

I don't know where you get that this is "extension" -- this is core protocol but it was split into two parts RFC6120 and RFC6121. Proper extensions are XEPs and are defined in XEP-0001 (xmpp.org/extensions/xep-0001.h)

@tigase @aslmx @chrisbodol

My claim was it does not bounce messages by default through core functions.(There are XEPs that fix this off course)
Through core function it may bounce them or it might not. If something works how I expect it to work or it might not, it means(for me) it doesn't work
1) I don't want an error, I want my messaging system to actually deliver messages
2) I know a few, but yes I don't think it's a large scale problem
Problem is that missing core features like that stack.

Sign in to participate in the conversation

Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.