Planet Jabber

The High Frequency Industry Association (HFIA) provides an “industry driven forum for the interactive exchange of technical and information in the area of High Frequency Communications.” Physical meetings of the group usually take place twice a year and in September 2014 Portsmouth was the location for the latest of these meetings. This is the first of two blog posts covering our attendance at this meeting.

As Isode has an interest in applications for constrained bandwidth communications, we often attend and occasionally present at these meetings. This year we had two presentations to share with the attendees.

Isode CEO, Steve Kille, gave a talk focusing on Isode’s proposed extensions to STANAG 5066 to improve performance of applications running over wideband HF links. The first was an update to a talk Isode gave at the February HFIA meeting, this time including hard measurements showing that Isode’s extensions (known as LFSN, Long Frame Sequence Number) result in significant performance gains.

This was followed by a live demonstration of the extensions in action, enabling co-existence of bulk and time critical applications over narrow-band and wide-band HF. The applications used were Multi-User Chat and Real-Time Military Forms (both using the XMPP protocol) and military email messaging.

PDF copies of the slide sets used during both phases of this talk can be found by following the links below:

1. Update to and Measurement of the proposed STANAG 5066 extensions to improve ARQ performance
2. Demonstration of ‘bulk’ and ‘time critical’ applications co-existing over HF and WBHF and using the proposed new STANAG 5066 extensions

Two whitepapers on the Isode website (Interconnecting XMPP and IRC and Deploying IRC, Federated MUC and XMPP Guards) show how Isode’s M-Link XMPP Server can be connected to and used in conjunction with chat services using IRC (Internet Relay Chat) in a range of deployment scenarios.

In order to help our customers and evaluators configure M-Link to act as an XMPP Gateway we’ve published a short configuration note which explains how to connect M-Link XMPP Multi-User Chatrooms to IRC Channels.

You can download the note from the documentation page on the Isode website (here’s the direct link to the PDF).

We’re pleased to announce the availability of Isode’s latest release, R16.3, which can be downloaded now from our website. R16.3 is a major Isode release which adds new capabilities across the entire Isode product range, including:

M-Vault

We’ve introduced a multi-master capability to M-Vault, complementing the single-master approach to replication defined in the X.500 protocols around which M-Vault was developed. M-Vault is the first directory to offer both multi-master and X.500.

M-Link

M-Link gains a new Archive Server for archive of all messages (including 1:1 chat, MUC and PubSub). XMPP clients can access archives using Message Archive Management (MAM) as defined in XEP-0313. M-Link also gains three new web applications:

1. Message Archive Management, allowing browser-based access to information in the archive.
2. Statistics, a lightweight monitoring alternative to the M-Link Console GUI.
3. Forms Discovery and Publishing, for end-user publishing and display of FDP forms.

M-Switch

We’ve added gateway support for text based organisational message protocols, which we’re collectively describing as “ACP127”. The first release of this capability supports ACP127 and DOI 103S, a popular US variant, and enables conversion with STANAG 4406 (compliant to STANAG 4406 Annex D) and SMTP (following the MMHS over SMTP extensions).

In addition we’ve made extensive improvements to MConsole and M-Link Console to support the new M-Switch and M-Link family capabilities. For a full run-down of new capabilities in R16.3, please see the Product Release page. We’ll be publishing further blog posts over the coming weeks focusing on some of the new R16.3 capabilities.

We have two small changes to our evaluation guide series to announce (with many more coming soon).

Our core XMPP Messaging Evaluation Guide, using our M-Link XMPP server and M-Vault LDAP directory, now includes a section on adding a Security Policy to your XMPP service. In this new section we show you how to add a the policy to your service and clearances to your users. You can additionally apply label based controls to multi-user chat, domains and peer services (all of which and more is covered in the M-Link Admin Guide).

The Security Policy we use in the evaluation guide is one of the demonstration policies we ship with M-Link but, if you want to create your own, you can now get started with the new SPIF Editor Evaluation Guide. A SPIF (Security Policy Information File) is a file representation of a Security Policy, in other words the definition of which labels are valid and how to check them against clearances. This new evaluation guide will show you how to create your own basic SPIF using the Isode SPIF editor tool.

Those of you keeping an eye on the Swift or Isode Twitter accounts will have noticed that a beta release of the new Swift 4.0 is now available for download from the Swift website .

Swift 4.0 includes a number of important functional changes compared to Swift 3.0 as well as a significant change to the look and feel of the product.

The main changes are listed in the changelog but there are two big changes that you’ll notice immediately on launching this Swift beta.

Better Chat Monitoring

Swift already makes it very easy to monitor events in multiple chat rooms through the use of keyword highlighting rules. In response to requests from a number of users we’ve supplemented this with the addition of a “trellis” layout option, allowing multiple chats and rooms to be tiled instead of being exclusively displayed as tabs within a single window.

This new option (Change Layout from the View menu) allows the user to define the number and arrangement of tiles to be displayed simultaneously and then move chats or rooms into an appropriate position. The trellis layout option and the existing tabbed layout option can be flexibly combined.

New Chat Design

We’ve introduced a new, cleaner chat design which we believe will enable users (especially in MUC rooms) to keep better track of their own contributions to conversations allows for better display of message receipts and better indication of unread messages.

The Swift 4.0 beta is available for Windows, MAC OS X, Ubuntu & Debian Linux. Please email (swift@swift.im) or tweet @swift_im any feedback you have to help us further improve Swift.

React’s standard flow is to start with an empty HTML template from the server, and populate the DOM entirely on the client. Letting React pre-render the initial HTML for your app on the server before the client takes over has some advantages, though: it lets slower (mobile) clients load your app much faster, and it’s good for SEO for search engines that don’t support JavaScript. Since you have to run React on the server to do this, you need a JavaScript-able backend, which is why such Universal (a.k.a. Isomorphic) apps are mostly built with Node.js backends. However, you can create universal React apps with other languages too, including Swift. In this post, I’ll walk through an example of a universal React app using Swift’s Vapor web framework.

Continue reading post

We get a lot of requests on howto use the MatriX XMPP SDK with Google Firebase Cloud Messaging.

The following are the settings for your XmppClient object

• The XMPP domain is: gcm.googleapis.com
• The hostname is: fcm-xmpp.googleapis.com
• It looks like there are no SRV records in place, this is why you need to set the hostname manual and disable SRV record lookups
• Firebase does not support XMPP’s StartTls feature and requires to initiate a TLS connection. This is how we have done it in the old days when the protocol still was called Jabber. The OldStyleSsl property takes care of this in MatriX’s XmppClient.
• Firebase is using a non standard XMPP port, because no SRV records are in place we have to set port 5236 manual in the code
• the username is your Firebase Sender Id and the password is your server key. You find them in the Firebase portal under Settings => Cloud Messagging
• the contact list and presence feature is not require. So we can disable it by setting AutoRoster and AutoPresence to false

XmppClient xmppClient = new XmppClient
{
    XmppDomain          = "gcm.googleapis.com",
    Hostname            = "fcm-xmpp.googleapis.com",
    Port                = 5236,
    ResolveSrvRecords   = false,
    OldStyleSsl         = true,
    Username            = "YOUR_FIREBASE_SENDER_ID",
    Password            = "YOUR_FIREBASE_SERVER_KEY",
    AutoRoster          = false,
    AutoPresence        = false
};

xmppClient.Open();

You can find a basic example also here in our GIT repository:
https://gitlab.com/matrix-xmpp/samples/tree/master/csharp/FirebaseClient

See also:
https://firebase.google.com/docs/cloud-messaging/server#implementing-the-xmpp-connection-server-protocol

The MatriX XMPP SDK is also available for the .NET Core now.
You can get it from NuGet here: https://www.nuget.org/packages/MatriX.NetCore/

It passed all our internal tests and QA, but its still marked as a pre-release until we collected some more feedback from users.

Don’t hesitate to contact us directly, or use our forums for any questions related to the .NET Core version.

We are happy to introduce our new ejabberd release, ejabberd 16.09. As usual it includes many bug fixes and improvements. But most of all, it includes excellent student work done for Google Summer of Code program.

More specifically, this release adds the following major features:

• Support for Elixir configuration file. It means it is possible to configure ejabberd using an Elixir script file instead of ejabberd YAML format.
• Support XEP-0355 – Namespace Delegation
  This allows to use an external entity to manage some of the server features. This XEP is working with Privileged Entity (XEP-0356).
• Support XEP-0356 – Privileged Entity
  This allows a component or any entity to have a “privileged” status. As a result, it can manage an entity roster on its behalf, send or receive stanzas in the name of the server. The main goal of XEP-0356 is to create an external, server agnostic, PEP service.

Thanks to Anna Mukharram and Gabriel Gatu for their contributions.

Namespace Delegation and Privileged Entity

Thanks to Anna Mukharram, it’s now possible to delegate features to a component with a privileged status, allowing components to get access to some ejabberd’s internal data and to perform some actions. This allows developing advanced components that were previously not possible to create with XEP-0114 – Jabber Component Protocol.

On a typical setup, you’ll use both XEP-0355 and XEP-0356. To do so, you need to add mod_delegation to your modules section in ejabberd’s configuration, and delegate namespace to a component by adding a component in your listener section. You may also grant some access to this component. Here is an example of such configuration:

listen:
  ...
  -
    port: 8888
    module: ejabberd_service
    hosts:
      "sat-pubsub.example.org":
        password: "secret"
    delegations:
      "urn:xmpp:mam:1":
        filtering: ["node"]
      "http://jabber.org/protocol/pubsub":
        filtering: []
  ...

In the example above, a component serving sat-pubsub.example.org will receive all pubsub requests and all MAM requests with the node filtering attribute presented in a query packet. The component is also allowed to get the roster of every user of the server and send messages on behalf of the server.

Compliance with Salut à Toi project components have been tested: We can now run SàT components directly on top of ejabberd.

Please, let us know if you write components for XMPP using this new feature :)

Ejabberd configuration in Elixir

Thanks Gabriel Gatu, you now have choice when it comes to configure ejabberd. While YAML configuration file is the default way to configure ejabberd, it’s now possible to write configuration as an Elixir script which will be evaluated. The most notable benefit is the ability to add some logic and get unlimited number of possibilities for a dynamic configuration.

Here is an example of such configuration: ejabberd.exs

It also gives opportunity to apply a custom function for a given hook to customize ejabberd behavior without need to write your own ejabberd module. The following example adds an entry in the log when a user is registered:

hook :register_user, [host: "localhost"], fn(user, server) ->
   info("User registered: #{user} on #{server}")
end

Elixir configuration files are expected to have .exs extensions.

Check config/ejabberd.exs for a complete default configuration, and give it a try !

This is a work in progress, and you can expect more features soon. For example, you cannot yet define different module or listener configurations for different domains, but this is something we are aware of and that is on our roadmap.

Changes

This is a selection of the most important changes:

New XMPP Extension support

• Support for XEP-0355 – Namespace Delegation
• Support for XEP-0356 – Privileged Entity

Elixir support

• Support for Elixir-based configuration files

MUC/Sub

• Add a new request to list MUC room subscribers
• Link MUC subscription to bare JID
• New commands unsubscribe_room and unsubscribe_room for MUC subscriptions management through API
• Fix nick-to-jid mapping for MUC subscribers
• Fix subscribed rooms list retrieval
• Fix message routing from subscribers
• Do not update muc_online_users table on MUC/Sub operations

MUC

• Support multiple JIDs in room invitations
• Create room on configuration request as per XEP-0045, 10.1.3

PubSub

• Add SQL support for microblogging node plugin
• Fix publish with subscriber publish model and SQL backend
• node_mb: Call node_pep instead of node_hometree

Stream Management

• New Stream Management option: ack_timeout
• Fix Stream Management feature for the websocket connections
• Cancel timer when waiting for resumption

MAM and Offline

• Don’t store messages of type “headline”
• Simplify “assume_mam_usage” option
• Honor hint for any non-“error” message
• Store announcements for offline users

Database

• Session backend: fix clean Redis table
• mod_shared_roster: Support SQL backend

ejabberdctcl admin tool

• ejabberdctl: do not force access rules check on register command
• ejabberdctl: do not force command line to pass a credential
• New commands unsubscribe_room and unsubscribe_room for MUC subscriptions management
• New command create_room_with_opts to create room with custom config

ejabberd API

• New commands unsubscribe_room and unsubscribe_room for MUC subscriptions management
• New command create_room_with_opts to create room with custom config
• Add X-Admin and basic auth header to CORS allowed headers in http_api
• Properly process OPTIONS header in http_api for all paths
• Expand parsing of JSON input to be able to handle update_roster command
• Provide proper args_desc in oauth_issue_token command

Developer features: ejabberd Hooks

• Add hooks c2s_session_pending, c2s_session_resumed, store_offline_message, store_mam_message
• Add CSI user’s JID argument to csi_filter_stanza and csi_flush_queue hooks
• Add functions to get/set some c2s #state elements from external modules
• mod_client_state: Let other modules filter stanzas
• rework c2s API to simplify push modules integration

Installers

• Fix several issues on Windows installer

Feedback

As usual, the release is tagged in the Git source code repository on Github.

The source package and binary installers are available at ProcessOne.

If you suspect that you’ve found a bug, please search or fill a bug report on Github.

Welcome ejabberd summer release !

This new release is the culmination of several months of work to improve your experience using ejabberd. It contains as usual a lot of small bug fixes and some enhancements. However, this version contains some new major features:

• MUC/Sub
• Major clean-up and improvement on OAuth ReST API
• Database backend for OAuth tokens
• Better support of Elixir modules
• Full compatibility with Erlang 19
• Modules loading in a dependent order

The biggest improvement in ejabberd 16.08 is a new experimental feature in ejabberd that make group conversations in XMPP work seamlessly with mobile clients: MUC/Sub.

The main issue with XMPP group chat (based on XEP-0045) is that it is bound to user presence. On mobile, presence is almost irrelevant. You are always somewhat loosely reachable, but ofter seen as offline from XMPP point of view. MUC/Sub rely as much as possible on existing MUC specification, while making the smallest possible change that make mobile group conversation client development easy without having to send presence.
See all details in our dedicated MUC/Sub blogpost.

This release also covers needs of the Elixir community: Erlang 19, Elixir 1.2.6, better mix integration. It’s also possible to write Elixir module handled by the contributed module extension of ejabberd. We also tested ejabberd with Elixir 1.3.2 with success, so you can likely upgrade without issues.

Finally, it is worth noting that development team is growing and three new official contributors joined the project: Gabriel, Anna and Thiago. Welcome !

Changes

This is a selection of the most relevant changes:

MUC

• New MUC/Sub support
• Add ‘allow_subscription’ room configuration option for MUC/Sub

OAuth and ReST API

• Add OAUTH SQL backend
• New special scope: ejabberd:admin and ejabberd:user, to more easily grant group of privileges
• Add DB backend support for ejabberd_oauth
• Added ejabberdctl commands to manage OAuth tokens: oauth_issue_token, oauth_list_tokens, oauth_list_scopes, oauth_revoke_token
• Simplified OAuth form: username and password merged into JID field
• User configurable validity duration for tokens on OAuth token generation form
• Add support for sending back missing scope error to API ReST command calls
• Oauth: several minor fixes
• Support oauth password grant type, to generate token programmatically

Elixir support

• Update supported Elixir version to 1.2 and 1.3.
• Support installation of Elixir contributions with external module command line tool.

PubSub

• Fix use of like parameter in sql pubsub’s requests
• Fix node configuration change with sql backends
• Fix send_last_items duplication with multi-plugin setup

MAM

• Always limit result set page size
• Use hooks instead of direct calls

API

• Add support for checking access rules conformance for commands
• Add support for rich error reporting for API
• Add support for sending back missing scope error to API ReST command calls
• Fix handling of complex values as arguments in http_api
• Improve error handling

Other improvements

• External Component Connection Hooks
• Fix compilation issues on R19
• Support for OpenSSL 1.1
• Make access rules in ejabberd_web_admin configurable
• Make modules loading in a dependent order (#1191)
• Make s2s stats commands more robust
• Preserve PID for offline sessions
• Several quoting fixes for PostgreSQL
• Switch supervised workers from temporary to transient

Feedback

As usual, the release is tagged in the Git source code repository on Github.

The source package and binary installers are available at ProcessOne.

If you suspect that you’ve found a bug, please search or fill a bug report on Github.

If you are eager to test out  the new image handling, check out the new beta for OS X  .  I have made this an opt in only feature for now. To get inline image support, go to preferences -> display and check the option for inline images.  While you are testing this, try out drag and drop to the text field and markup (the little arrow in the upper right of the image when you attach it).  Clicking an image in chat will bring up preview and you can use the export button to send that image anywhere you want.  Animated gifs are not animated in the thread (yet) but will be when you click them.

I had a few spare minutes today, so I decided to finish support for inline images in chat in the OS X client. Most of this will come to the iOS client as well. It does not yet support the privacy setting to disable checking the HTTP head of every link to identify an image  but beyond that it is mostly done.  I also added support to OS X’s quick look as well as markup for images that can now be dragged into the text field before uploading. 

Hi to you,

It's time for a blog post on Cagou development.
Cagou is the new desktop/Android frontend for "Salut à Toi" (SàT), the full-featured social network based on standards (XMPP) and with a strong emphasis on ethics.

This frontend is using the very nice Kivy framework, and is already usable on desktop.

Let's see a video on the current state:

As you can see, the interface can be divided easily. This idea is inspired by the excellent Blender interface, and make it easy to adapt to a small or big screen by choosing the number of widgets accordingly.
Instead of being a discreet software that you'll use only when you want to answer to somebody, Cagou is an application which should be used full-screen, with a layout suiting the current needs.

Other important point: the contact list is not the central element (as it is usually in instant messaging software). You can access it by selecting the widget, or put it on the side to simulate traditional layout, but it is not visible by default and you can spend a whole session without using it.

About notifications, it will be slighly different on desktop and on platforms with their own notification system (like Android). In the later case, the native way will be used.
On desktop, a specific header is used. 2 cagou icons (thanks to Muchoslava for its contributions) can appear: one on the left for notes (i.e. short messages which will automatically disappear), and one of the right for more important notifications, needing attention from the user.
A click on the left icon will show the last 10 notes, and one the right one show the next important notification.

This was made to avoid popups: they are displayed only after an interaction of user, and will not appear all of a sudden while you are writting a message.

Thanks to the architecture of SàT, menus are already available with a couple of useful actions.

There are several ways to start a chat: you can click on an item in the contact list, or enter a jid (XMPP identifier) in a chat widget.
Discussions are not closed when you switch widget, and they can be later accessed by swiping the current one (see video below).

There have been a lot of work done and the interface starts to be really usable. Concerning the desktop the greatest part is already finished, the most important remaining thing is to adapt interface to features (e.g. displaying of delivery reciept) and to make new widgets.

The other big thing to cope with would be displaying of HTML content and of course the Android port. An Ubuntu touch port is an eventuality.

And for those who wonder: Cagou will as well benefit from end-to-end encryption (for now OTR, but OpenPGP is planned for next release, OMEMO is considerated), and other SàT features

The project is still in active progress, but it is really demanding. If you can contribue in any way – code, distributions packages, tests, graphics, translations, etc. – please contact us by any mean shown on our website.

Last but not least, we reminds all of the Aziruka contributors of the crowdfunding campaign, that they can claim their counterpart if not done yet (or request it later).

See you soon :-)

One of the most useful features of Pushpin is the ability to combine a request for historical data with a request to listen for updates. For example, an HTTP streaming request can respond immediately with some initial data before converting into a pubsub subscription. As of version 1.12.0, this ability is made even more powerful:

1. Stream hold responses (Grip-Hold: stream) from the origin server can now have a response body of unlimited size. This works by streaming the body from the origin server to the client before processing the GRIP instruction headers. Note that this only works for stream holds. For response holds, the response body is still limited to 100,000 bytes.
2. Responses from the origin server may contain a next link using the Grip-Link header, to tell Pushpin to make a request to a specified URL after the current request to the origin finishes, and to leave the request with the client open while doing this. The response body of any such subsequent request is appended to the ongoing response to the client. This enables the server to reply with a large response to the client by serving a bunch of smaller chunks to Pushpin, and it also allows the server to defer the preparation of GRIP hold instructions until a later request in the session.

...

A new bugfix version has just been released to Maven Central with the following issues resolved:

• Fix reconnection issue, when using multiple connection methods per session.
• Improve and fix stanza acknowledging and Stream Management
  • Add Delayed Delivery (XEP-0203) extension to stanzas, which are resent automatically later (when reconnected again)
  • Always resent all unacknowledged stanzas after login, not only after stream resumption.
  • Highlight StreamManagement’s request / answer pairs in VisualDebugger.
  • Update XEP-0198 Stream Management to version 1.5 (respect the ‘h’ attribute in the failed element)
• Wait for the roster response before sending initial presence during login, to prevent receiving presence information from yet unknown contacts.
• Make sure asynchronous method calls do not block (affected only few methods for avatars and entity capabilities)
• Use the hostname instead of the domain for SASL clients (i.e. use the Sasl.createSaslClient API correctly as per the documentation, may affect DIGEST-MD5 authentication).
• Call SaslClient.dispose() when SASL authentication has completed.
• Include the requesting IQ in NoResponseException, when doing IQ queries.
• XEP-0184: Add the sender of a receipt to the MessageDeliveryEvent.
• Allow event consumption for outbound stanzas, which prevents the stanza to be sent.
• Make stream feature negotiation more stable.
• Minor graphical fixes in VisualDebugger.
• Add API to include the hash and mime type in File Transfer offers.
• Add API to create a chat session with a thread id.
• Immediately complete (IQ-)queries if sending failed and don’t wait on the timeout.

In this video, Mickaël Rémond summarises important principles developers need to be aware of when building their own modern XMPP messaging platform.

The video was recorded at ejabberd Advanced Erlang Workshop in Paris.

You can watch the full talk online:

You can also download the slides: Designing a modern XMPP service with ejabberd.

Ever since I read XKCD 936, I’ve been a big fan of the Diceware approach for picking strong passwords, where you randomly pick words from a list to create a memorable passphrase. Sometimes, I need to generate Diceware passwords in Dutch for friends and relatives. Unfortunately, the Dutch word list from the Diceware page contains many uncommon words, non-existent words, duplicate words (yikes!), numbers, and characters (as the example ijler 100 leperd akolei kolkje on that page proves), which diminishes the memorability and usability of the generated passwords. I therefore created my own, improved lists, which you can try out directly from your browser on my password generator. The list consists of the most common Dutch words, and has an added benefit that it only contains words that don’t weaken security when leaving out spaces between words. This post discusses the details how I composed this list. The process and links can be used as a guide to generate Diceware lists for other languages.

Continue reading post

Another tricky thing I always struggle with: Get MongooseIM compiled on OS X (since they removed openssl). So if you have openssl installed via homebrew just do

diff --git a/apps/ejabberd/rebar.config b/apps/ejabberd/rebar.config
index c693471..4e5ff1f 100644
--- a/apps/ejabberd/rebar.config
+++ b/apps/ejabberd/rebar.config
@@ -8,8 +8,15 @@
 {require_otp_vsn, "R?1[678]"}.

 {port_specs,
- [{".*", "priv/lib/tls_drv.so", ["c_src/tls_drv.c"], [{env, [{"LDFLAGS", "$LDFLAGS -lssl"}]}]},
-  {".*", "priv/lib/ejabberd_zlib_drv.so", ["c_src/ejabberd_zlib_drv.c"], [{env, [{"LDFLAGS", "$LDFLAGS -lz"}]}]}]}.
+ [{".*", "priv/lib/tls_drv.so", ["c_src/tls_drv.c"], [{env, [{".*apple-darwin.*", "CFLAGS", "$CFLAGS -I/usr/local/opt/openssl/include"},
+                                                             {".*apple-darwin.*", "LDFLAGS", "$LDFLAGS -L/usr/local/opt/openssl/lib"},
+                                                             {"LDFLAGS", "$LDFLAGS -lssl"}]}]},
+  {".*", "priv/lib/ejabberd_zlib_drv.so", ["c_src/ejabberd_zlib_drv.c"], [{env, [{"LDFLAGS", "$LDFLAGS -lz"}]}]},
+  {".*", "priv/lib/sha_drv.so", ["c_src/sha_drv.c"], [{env, [{".*apple-darwin.*", "CFLAGS", "$CFLAGS -I/usr/local/opt/openssl/include"},
+                                                             {".*apple-darwin.*", "LDFLAGS", "$LDFLAGS -L/usr/local/opt/openssl/lib"},
+                                                             {"LDFLAGS", "$LDFLAGS -lcrypto"}]}]},
+  {".*", "priv/lib/xml.so", ["c_src/xml.c"], []},
+  {".*", "priv/lib/expat_erl.so", ["c_src/expat_erl.c"], [{env, [{"LDFLAGS", "$LDFLAGS -lexpat"}]}]}]}.

 {xref_checks, [undefined_function_calls,
                undefined_functions,

For those who are interested in the collaborative effort to have a standard modern encryption scheme on the major mobile and desktop clients. You can see where things are for Monal and Chatsecure at the github issue.

 

 

Now that the app is mostly done I’ve put in some nicer images in TV portal.  IT also supports viewing scheduled recordings now. Going to keep testing (aka watch tv) to see what bugs arise but this is mostly done at this point. Please contact me at info@monal.im if you would like to help test this.