@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" (xmpp.org/extensions/xep-0163.h, "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 (xmpp.org/extensions/xep-0384.h) 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.

@celia Could you expand on this? Does it happen always? Which other clients do you use? Which server do you use?

Could you report the issue on github.com/tigase/beagle-im/ with examples / steps to reproduce?

@debacle @Menel While system packages can be useful, sometimes they get outdated leading to bad experience. Though, we are aware of that and keep it in mind :-)

Tigase software (both server as well as java libraries and clients) does not use log4j library thus is NOT affected by recently discovered log4j vulnerability (CVE-2021-44228).

@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).

@thirdbird Thank you for the kind words! If you have suggestions we are always open to them :-)

Tigase boosted

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 and clients have been released with A LOT of new features and ton of fixes. Details available on release pages: BeagleIM (github.com/tigase/beagle-im/re) and SiskinIM (github.com/tigase/siskin-im/re). Available from AppStores and via Brew.

Tigase boosted

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.


#storkim #tigase #xmpp #android

@PublicNuisance We can recommend (our) client (siskin.im/) - fully FOSS, with OMEMO, push and Audio/Video calls.

And if you have any issues we welcome reports and suggestions how to improve: github.com/tigase/siskin-im

@phryk You can grab logos from the sources: github.com/tigase/beagle-im/tr (IMG_0720_1024.png is the main file) and github.com/tigase/siskin-im/tr (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 (xmpp.org/extensions/xep-0001.h)

@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".

New beta releases of and clients - most notable feature is sharing location.

Show older
Mastodon for Tech Folks

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!