@praveen And the "presence" is not the correct approach because you may request the subscription and send some messages but before your contact manages to accept the request and in that short window the encryption would not work and be very messy. And due to that case specification now says that "open" is the default value for the access rights.
@praveen The configuration of this node is driven completely by the clients thus the first client that configures the node sets the configuration. What's more - it depends on both your and your interlocutor clients and OMEMO pep node configuration (siskin can configure correctly own pep node but the contact may use client with "presence" configuration).
@praveen By default (due to privacy reasons) for PEP access model is set to "presence" (https://xmpp.org/extensions/xep-0163.html#defaults, "Support the "presence" access model and set it to the default."). The client can set it to open for particular node, as it should do in this instance.
Checking it on compliance page could be slightly problematic as it's the client that sets the access model thus in that case it would be the compliance client.
@praveen The presence vs omemo thing is somewhat more complicated -- yes, it can break OMEMO and because of that reason OMEMO specification (https://xmpp.org/extensions/xep-0384.html#usecases-announcing) mandates that the relevant nodes should have 'open' access model but if the PEP node hasn't been configured with that access model then lack of presence would break it. But! Enabling auto-presence just to fix it would cause other inconveniences.
@praveen @nicfab the message during registration states clearly that the correct e-mail is required and will be verified though after the registration without confirmation Siskin would simply disable the account. We did improve on that workflow and next version will give the user better notification what is happening with the account and that it should confirm the registration.
@thirdbird That's an interesting suggestion though this should be handled on the system-level: you lock your account and all apps are locked (and storage is encrypted).
The #XMPP Newsletter for November 2021 is out!
This is the final release for this year! Many thanks to all the contributors!
May you will join us from next year, too?
Enjoy reading! 📰 ☕
New versions of #BeagleIM and #SiskinIM #XMPP clients have been released with A LOT of new features and ton of fixes. Details available on release pages: BeagleIM (https://github.com/tigase/beagle-im/releases/tag/5.0) and SiskinIM (https://github.com/tigase/siskin-im/releases/tag/7.0). Available from AppStores and via Brew.
I have been trying out a few XMPP clients for Android, and Stork IM from Tigase is pretty good so far.
Native Android app. Offers real Android experience, is fast, reliable and offers all the features like chat, group chat, push notifications, voice and video calls. Supports multiple XMPP accounts and is compatible with any XMPP server.
@phryk You can grab logos from the sources: https://github.com/tigase/beagle-im/tree/master/BeagleIM/Assets.xcassets/AppIcon.appiconset (IMG_0720_1024.png is the main file) and https://github.com/tigase/siskin-im/tree/master/SiskinIM/Assets.xcassets/AppIcon.appiconset (IMG_1607.jpg is the main file) for Beagle and Siskin respectively.
Unfortunately there aren't any SVG logo versions.
@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 (https://xmpp.org/extensions/xep-0001.html)
@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." (https://xmpp.org/rfcs/rfc6121.html#rules) so it's part of core specification.
As for "default to plain-text": STARTTLS required is virtually ubiquitos nowadays and is considered "default".
One of the top real-time communication software providers.
We like to make things to scale, in fact we are little bit too obsessed with optimizations.
This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!