Planet Jabber

January 18, 2020

Monal IM

Mam and Rethinking the UI

I had about 5 hours on the train today. There wasn’t a ton to do while going along the east coast on a snowy winter day so I had some time to work on Monal again. Version 4.3 is in development. The first order of business was to fix an old bug with paging through MAM messages. Things work a lot better now and the user experience, network and battery use should be greatly improved.

After that I thought about the UI a little bit. When I originally made Monal, it was the early days of iOS. I was making an app for iOS 2 and I assumed most users were coming form Gim (Pidgin) and Adium. The UI and the terms I used reflected that. Contacts were called buddies. There was a sense of going offline/online etc. Today most new users come from iMessage or WhatsApp. The Monal UI however has not changed in 10 years this means having to regularly explain the UI to others or say, ‘Thats not a bug, it’s a feature’. So I am adjusting the UI to make it closer to other modern apps. This should seem familiar not only to people who use iMessage and WhatsApp but Conversations users too. I am also updating all of the icons in the app. The icon line thickness and spacing have been changed to match iOS 12 and 13 which will be the targeted os version going forward. The new icons should be 3x for modern displays and match other icons in iOS. The input bar should interactively dismiss with the keyboard and reduce a lot of flickering and jumping in the chat. The most notable change is the loss of the tab bar at the bottom. Don’t worry though, all existing screens will still be in the app. They are just moved around I am focusing attention on the two screens that matter the most. The Chat and the messages. Part of this is also an effort to fix the group chat UI, which I tacked on but even I admit doesn’t make a ton of sense.

by Anu at January 18, 2020 22:20

Prosodical Thoughts

Prosody 0.11.4 released

We are pleased to announce a new minor release from our stable branch. This release contains a number of bug fixes and a couple of performance improvements. A summary of changes in this release: Fixes and improvements core.rostermanager: Improve performance by caching rosters of offline #1233 mod_pep: Handling subscriptions more efficiently #1372 Minor changes util.interpolation: Support unescaped variables with more modifiers #1452 MUC: Mark source of historic messages correctly #1416 mod_auth_internal_hashed: Pass on errors #1477 mod_mam, mod_muc_mam: Improve logging of failures #1478, #1480, #1481 mod_muc, mod_muc_mam: Reschedule message expiry in case of failure mod_mam: Add flag to session when it performs a MAM query prosodyctl check: Warn about conflict between mod_pep and mod_pep_simple prosodyctl check: Warn about conflict between mod_vcard and mod_vcard_legacy #1469 core.

by The Prosody Team at January 18, 2020 14:13

January 15, 2020

ProcessOne

go-xmpp v0.4.0

A new version of the go-xmpp library, which can be used to write XMPP clients or components in Go, has been released. It’s available on GitHub.

You can find the full changelog here : CHANGELOG
Some noteworthy features are the support of three new extensions :
– XEP-0060: Publish-Subscribe
– XEP-0050 : Ad-Hoc Commands
– XEP-0004: Data Forms
for both component and client.
Callbacks for error managment were also added to the client and component.

New Extensions

PubSub

Let’s create a very simple client that is both owner of a node, and subscribed to it.
This example assumes that you have a locally running jabber server listening on port 5222, like ejabberd.
First, let’s create the client. We need to provide a user JID, our identity, then the address of the server we wish to connect to.
Let’s also get a little ahead and put the node name and the service name in our constants :

const (
  domain = "mycomponent.localhost"
  address = "localhost:8888"
  nodeName = "example_node"
  serviceName = "pubsub.localhost"
)

Now, we need to fill a Config struct, that will be passed to the NewClient method :

    config := xmpp.Config{
        TransportConfiguration: xmpp.TransportConfiguration{
            Address: serverAddress,
        },
        Jid:        userJID,
        Credential: xmpp.Password("pass123"), // For the sake brievety
        Insecure: true,
    }

To process publications, we need to setup a route to catch messages and print them on screen :

    router := xmpp.NewRouter()
    router.NewRoute().Packet("message"). // Packet type to go through this route
        HandlerFunc(func(s xmpp.Sender, p stanza.Packet) {
            // Make the packet readable and print it
      data, _ := xml.Marshal(p)
            fmt.Println("Received a publication ! => \n" + string(data)) 
        })

Now, let’s make the client ! (see next feature’s description for an explanation on the func(err error) argument)

    client, err := xmpp.NewClient(config, router, func(err error){  fmt.Println(err)})

Now we can connect :

err := c.Connect()

Now that our client is live, let’s make it create a node on the service, using the previousely defined ocnstants :

  // Build the request
    rqCreate, err := stanza.NewCreateNode(serviceName, nodeName)
  // Send it
  ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
    ch, err := client.SendIQ(ctx, rqCreate)

Now we just have to wait for our response:

select {
  case iqResponse := <-ch:
    // Got response from server
    fmt.Print(iqResponse.Payload)
  case <-time.After(100 * time.Millisecond):
    cancel()
    panic("No iq response was received in time")
}

The node is created ! Let us subscribe to it before we publish :

  // Create a subscribe request
  rqSubscribe, err := stanza.NewSubRq(serviceName, stanza.SubInfo{
        Node: nodeName,
        Jid:  userJID,
    })
  // Send it
  pubRespCh, _ := client.SendIQ(ctx, rqSubscribe)

And now, we can publish to that node. The publish model is very generic and can be a bit verbose, but it provides great flexibility.
Let’s say we want to publish this item :

<item id="62B5B8B3AB34">
    <entry xmlns="http://www.w3.org/2005/Atom">
        <title xmlns="http://www.w3.org/2005/Atom">My pub item title</title>
        <summary xmlns="http://www.w3.org/2005/Atom">My pub item content summary</summary>
        <link href="http://denmark.lit/2003/12/13/atom03" rel="alternate" type="text/html" xmlns="http://www.w3.org/2005/Atom"/>
        <id xmlns="http://www.w3.org/2005/Atom">My pub item content ID</id>
        <published xmlns="http://www.w3.org/2005/Atom">2003-12-13T18:30:02Z</published>
        <updated xmlns="http://www.w3.org/2005/Atom">2003-12-13T18:30:02Z</updated>
    </entry>
</item>

This is how we would need to build the request :

pub, err := stanza.NewPublishItemRq(serviceName, nodeName, "", stanza.Item{
        Publisher: "testuser2",
        Any: &stanza.Node{
            XMLName: xml.Name{
                Space: "http://www.w3.org/2005/Atom",
                Local: "entry",
            },
            Nodes: []stanza.Node{
                {
                    XMLName: xml.Name{Space: "", Local: "title"},
                    Attrs:   nil,
                    Content: "My pub item title",
                    Nodes:   nil,
                },
                {
                    XMLName: xml.Name{Space: "", Local: "summary"},
                    Attrs:   nil,
                    Content: "My pub item content summary",
                    Nodes:   nil,
                },
                {
                    XMLName: xml.Name{Space: "", Local: "link"},
                    Attrs: []xml.Attr{
                        {
                            Name:  xml.Name{Space: "", Local: "rel"},
                            Value: "alternate",
                        },
                        {
                            Name:  xml.Name{Space: "", Local: "type"},
                            Value: "text/html",
                        },
                        {
                            Name:  xml.Name{Space: "", Local: "href"},
                            Value: "http://denmark.lit/2003/12/13/atom03",
                        },
                    },
                },
                {
                    XMLName: xml.Name{Space: "", Local: "id"},
                    Attrs:   nil,
                    Content: "My pub item content ID",
                    Nodes:   nil,
                },
                {
                    XMLName: xml.Name{Space: "", Local: "published"},
                    Attrs:   nil,
                    Content: "2003-12-13T18:30:02Z",
                    Nodes:   nil,
                },
                {
                    XMLName: xml.Name{Space: "", Local: "updated"},
                    Attrs:   nil,
                    Content: "2003-12-13T18:30:02Z",
                    Nodes:   nil,
                },
            },
        },
    })

Then we can send it !

client.SendIQ(ctx, pub)

As we are subscribed to it, the route that we setup earlier will catch a message from the server that contains this publication and print it on screen.
You can find another use of this extension in our xmpp_jukebox example.

Full example

The full program that :
– runs a client
– connects it to a XMPP server
– creates a node, subscribes to it
– publishes to it
– prints the notification from it
is available in our library repository, with a few extras.

XEP-0050 : Ad-Hoc Commands

Using the example above, let’s say we already have a connected client.
To request all pending subscriptions requests for all nodes on a PubSub service, we would just use :

subR, err := stanza.NewGetPendingSubRequests(serviceName)
subRCh, err := client.SendIQ(ctx, subR)

Now we just need to listen to the channel (subRCh) to get the server response.
This request uses the XEP-0050 under the hood, as specifed by XEP-0060 : 8.7 Process Pending Subscription Requests.
Support for XEP-0050 is currently provided without helper functions.

XEP-0004: Data Forms

Support of this extension was added partly to cover the 8.2 Configure a Node section of XEP-0060.
In this process, the client must send a request like :

<iq type='get'
    from='hamlet@denmark.lit/elsinore'
    to='pubsub.shakespeare.lit'
    id='config1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub#owner'>
    <configure node='princely_musings'/>
  </pubsub>
</iq>

to which the server responds with a form that should be returned with the new configuration values for the node.
To request that form, we would need to use :

confRq, err := stanza.NewConfigureNode(serviceName, nodeName)
confReqCh, err := client.SendIQ(ctx, confRq)

Then, catch the response from the server and extract the configuration items that you wish to update :

var fields map[string]Field
select {
    case confForm:=<-confReqCh:
        fields, err = confForm.GetFormFields()
    case <-time.After(100 * time.Millisecond):
        cancel()
        log.Fatal("No iq response was received in time")
}

Edit fields to your liking :

 fields["pubsub#max_payload_size"].ValuesList[0] = "200000"
 fields["pubsub#deliver_notifications"].ValuesList[0] = "1"

and send them back to the service :

submitConf, err := stanza.NewFormSubmissionOwner(serviceName,
            nodeName,
            []*stanza.Field{
                fields["pubsub#max_payload_size"],
                fields["pubsub#notification_type"],
            })
client.SendIQ(ctx, submitConf)

Error callbacks

Overview

The “NewClient” function changed signature from :

func NewClient(config Config, r *Router) (c *Client, err error)

to :

func NewClient(config Config, r *Router, errorHandler func(error)) (c *Client, err error)

Meaning you can now provide an errorHandler function, that will be called, currently, when :
– A new session fails to start
– Stanzas cannot be read properly
– A stream error is recieved
– There is a problem with the underlying connexion

Simple example

Here’s an example of how to use the handler. This very simple handler just prints the error that arises :


import ( "gosrc.io/xmpp" "log" ) func main() { // Create the error handler errHandler := func(err error) { fmt.Println(e) } // Create a client var client *xmpp.Client clientCfg := xmpp.Config{ TransportConfiguration: xmpp.TransportConfiguration{ Address: "serverAddress", }, Jid: "myJid", Credential: xmpp.Password("myPassword"), Insecure: true} router := xmpp.NewRouter() if client, err = xmpp.NewClient(clientCfg, router, errHandler); err != nil { log.Panicln(fmt.Sprintf("Could not create a new client : %s", err)) } // Connect your client client.Connect() }

That’s it !

by Remi Corniere at January 15, 2020 09:33

January 14, 2020

The XMPP Standards Foundation

Happy new XMPP year! 14 Jan 2020

Happy new XMPP year!

Welcome to the XMPP newsletter covering the month of December 2019. Sorry, we are late...

Contribute to the community effort, which process is fully documented.

Articles

Whatsapp, Matrix or XMPP (german) - The German Federal Ministry of the Interior is looking for a messenger for the federal authorities while the German Federal Police is experimenting with XMPP. They are using an Open Source Messenger "MOKA" based on Conversations (german).

Fabian Sauter known as COM8 (and developer of UWPX) has finalised his Bachelor Thesis on "Smart Building Control with XMPP for IoT". Congratulations! The development will be continued with the goal of an official XEP.

Anoxinon e.V who intend to inform and improve the situation about privacy and free software as well run a XMPP Server are looking for new board members.

Paul Schaub has written two pieces: Pitfalls for OMEMO Implementations – Part 1: Inactive Devices Re: The Ecosystem is Moving as an answer to Moxie Marlinspike's talk at 36C3 (Moxie is the creator of Signal)

The Ecosystem is Moving

Alex Gnauck wrote about Simpler code in handlers using pattern matching in MatriX.

During the 36C3 in December 2019, a bunch of people finalized the idea to form a SIG dedicated to end-to-end encryption.

Newsletter translations

Software releases

Servers

The Ignite Realtime community has released:

Clients and applications

Anu Pokharel the developer of Monal has made significant changes to its MUC implementation which improves the situation for iOS (4.1 and 4.2 and 4.2 final beta) and macOS (2.5 beta 1 2.5 beta 2) users. Furthermore there has been many bug fixes, including HTTP upload, and the end of iOS9 support.

Monal iOS

Gajim has posted their Development News for December 2019: old message dialog system, compact tooltip when hovering a group chat in Gajim’s contact list, new assistant for password change and account removal, HTTP File Upload now work asynchronously with the ‘libsoup’ library, bug fixes, plugin updates, and changes in python-nbxmpp.

Tigase has released BeagleIM 3.4 and Siskin IM 5.4: BeagleIM 3.4 allows you to set MUC room avatar, simplifies MUC room settings, and bug fixes, while SiskinIM 5.4 adds support for setting MUC room avatar.

Movim 0.16.1 has been released: you can now share posts to your connected chatrooms, communities layout was redesigned, all the messages that you sent in the one to one discussions can now be edited, the videoconferencing feature was heavily refactored, and bugs fixed.

Development versions of Profanity 0.8.0 have been released with consistent color generated nicks (XEP-0392) and a trackbar so you see where you left off reading!

Goffi has published the SàT progress note 2019-W51: infinite scroll is now implemented in Cagou, Kivy community extensions used by SàT are now installable like any other Python dependency, e2e encryption with OMEMO, and more.

Libraries

gloox 1.0.23 released as a maintenance version.

GSoC

Google Summer of Code 2020 has been announced, some XMPP projects have already shown interest to mentor students.

Extensions and specifications

New

XEP-0426: Character counting in message bodies

Version 0.1.0 of XEP-0426 (Character counting in message bodies) has been released.

Abstract: This document describes how to correctly count characters in message bodies. This is required when referencing a position in the body.

Changelog: Promote to Experimental as per Council decision. (mb)

URL: https://xmpp.org/extensions/xep-0426.html

Proposed

Character counting in message bodies

Title: Character counting in message bodies Abstract: This document describes how to correctly count characters in message bodies. This is required when referencing a position in the body.

URL: https://xmpp.org/extensions/inbox/charcount.html

User-defined Data Transfer

Title: User-defined Data Transfer Abstract: This specification proposes a simple mechanism by which applications can transfer data safely, without needing additional protocol design work. It is intended to provide a protocol that is trivial to implement and can be driven with a simple API.

URL: https://xmpp.org/extensions/inbox/udt.html

MAM Fastening Collation

Title: MAM Fastening Collation Abstract: This specification proposes a mechanism by which MAM results containing fastenings can be collated effectively.

URL: https://xmpp.org/extensions/inbox/mamfc.html

Fallback Indication

Title: Fallback Indication Abstract: This specification proposes a mechanism by which message bodies can be marked as being purely for fallback purposes, and therefore to be ignored by intermediaries and anything that understands the remainder of the message.

URL: https://xmpp.org/extensions/inbox/fallback.html

Special Interests Group End to End Encryption

Title: Special Interests Group End to End Encryption Abstract: This document proposes the formation of a Special Interest Group (SIG) within the XSF devoted to the development of end-to-end encryption within the context of XMPP.

URL: https://xmpp.org/extensions/inbox/sige2ee.html

Updated

  • Version 0.13.2 of XEP-0280 (Message Carbons) has been released.
  • Version 0.1.2 of XEP-0284 (Shared XML Editing) has been released.
  • Version 0.2.1 of XEP-0328 (JID Preparation and Validation Service) has been released.
  • Version 0.1.2 of XEP-0422 (Message Fastening) has been released.

Thanks all!

This XMPP Newsletter is produced collaboratively by the community.

Thanks to Wurstsalat, Echolon, Guus, MDosch for their help in creating it!

Please share the news on "social networks":

  • Twitter: https://twitter.com/xmpp
  • Mastodon: https://fosstodon.org/@xmpp/
  • LinkedIn: https://www.linkedin.com/company/xmpp-standards-foundation/
  • Facebook: https://www.facebook.com/jabber/
  • Reddit: https://www.reddit.com/r/xmpp/

License

This newsletter is published under CC by-sa license: https://creativecommons.org/licenses/by-sa/4.0/

by nyco at January 14, 2020 15:00

Peter Saint-Andre

Zamyatin's WE

In 1921, Yevgeny Zamyatin finished writing WE, the Ur-text for most dystopian novels since then (Anthem, 1984, Brave New World, etc.). In 1924, Zamyatin's novel, not yet (in fact never) published in the Soviet Union, was first brought to the world by E.P. Dutton and Company of New York in an English translation by Gregory Zilboorg. Because 95 years have passed since then, Dr. Zilboorg's translation is finally in the public domain - and I have just republished it online at my website for public-domain books, the Monadnock Valley Press....

January 14, 2020 00:00

January 11, 2020

Ignite Realtime Blog

XML Debugger Openfire plugin 1.7.3 released

@gdt wrote:

The Ignite Realtime community is happy to announce the release of version 1.7.3 of the XML Debugger plugin for Openfire!

This update brings has some minor improvements enabled by the release of Openfire 4.5.0.

Your instance of Openfire should automatically display the availability of the update. Alternatively, you can download the new release of the plugin at the XML Debugger plugin’s archive page

For other release announcements and news follow us on Twitter

Posts: 1

Participants: 1

Read full topic

by @gdt Greg Thomas at January 11, 2020 14:53

January 10, 2020

Ignite Realtime Blog

Openfire 4.5.0 is Released

@akrherz wrote:

Happy 2020 everyone! The Ignite Realtime Community is thrilled to announce the promotion of Openfire version 4.5.0. This is a feature and bug fix release with a number of Jira issues closed denoted in the changelog. We are thankful for the issues found by community users during a beta testing period of this release. If you find any problems with this release, please let us know in the community forums or drop by our web support groupchat.

So what’s in this new release? First, you will notice a new login screen on the administration console like so:
ss

Manassé Ngudia did the excellent work to move the admin console to use the Bootstrap library for a responsive design. With this foundation, we hope to move more parts of the admin console to a responsive design and thus render more favorably on mobile.

@guus and @gdt did heroic work, as always, to squash a number of bugs and greatly improve LDAP support. If you have had trouble in the past with Openfire + LDAP, please consider testing this release out and let us know how it goes!

You can find Openfire release artifacts on the download page and with the following sha1sums:

b4d8d77701d6524a4d26c4e8a6cba82f6e5d9d68  openfire-4.5.0-1.i686.rpm
01b583d27ea8d644376588e7226be0ad93d8d728  openfire-4.5.0-1.noarch.rpm
6bc54cf3de57e7359143ab8f6ff015b191c4e898  openfire-4.5.0-1.x86_64.rpm
4e1bd74d0140178936dbb39f076b9817d2bfe945  openfire_4.5.0_all.deb
36a0ee7d4cc44d18524c5540bcba5af6e133fcc2  openfire_4_5_0_bundledJRE.exe
959441b2cd18b62861e14d4fea705ae57f8f6361  openfire_4_5_0_bundledJRE_x64.exe
fe9cebfb37eb126416aed3438b9aa28b796a987c  openfire_4_5_0.dmg
c4c900dbb4607a1f1eed8cce2e18fa4b2509bf52  openfire_4_5_0.exe
c4cf10939a9b573c3eee4637a7b8f38f3b4305b9  openfire_4_5_0.tar.gz
ceeb49bd51e6ae555e3dadf193b1ed2da811f959  openfire_4_5_0_x64.exe
da0050d284089331241ca023d40d2c382e37bfd9  openfire_4_5_0.zip
df4e0905ab52b0b1d4fea344ee4efe0ed119674d  openfire_src_4_5_0.tar.gz
85ee3714a05db13e1ad2967c6e6fde0c1d52269f  openfire_src_4_5_0.zip

With regards to future development plans, the master github branch has been marched toward a version 4.6.0 snapshot with a 4.5 branch created to signify an intention to produce followup bug fix releases of version 4.5.0 released today. At this time, there is no plan for a future 4.4.x series release.

We always could use more folks pitching in and helping out with documentation, testing and development! Thanks for your interest and usage of Openfire!

Posts: 2

Participants: 2

Read full topic

by @akrherz daryl herzmann at January 10, 2020 21:35

ProcessOne

Towards Lean Computing: Integrating Energy Consumption in Application Design

In the quest for better energy efficiency, the applications themselves are often overlooked. Our industry likes to pretend that all technologies are equivalent and has forgotten that the choice of programming languages, frameworks and architecture have a major impact on energy consumption.

The observation

Today we are all aware of the environmental impact of the objects, tools, devices we use. We all know that when we use our car, this usage will have a “carbon” impact. A whole industry is working to reduce the energy impact of the appliances we use. Our environmental awareness is leading us to moderate our use, by using appliances that consume less energy, or depend on a mix with more renewable energies. Finally, we even consider alternatives, such as replacing the car with a public transit, or cycling.

Taking into account the carbon footprint of our actions is more evident in the transport field. In the IT sector, we are only at the beginning, but our massive use of computing power and data turned the Internet into a major energy drain.

In 2017, Greenpeace considered Internet electric consumption to represent 7% of the world’s electricity consumption. The report is based on 2016 data. It is very likely that we are well beyond that point today. The growth in data traffic exceeds the advances in energy efficiency of network equipment. The “Low Tech Magazine” explains the problem very well: About Low Tech Magazine.

In other words, it means that all the world’s IT departments, phones, data centers, etc. emit more carbon than air transport, for example.

Keeping Internet infrastructure and usage under control

The awareness is growing, but the solutions being explored focus on only two lines of action, forgetting a third but fundamental one.

The first line of action on the energy consumption of the Internet is geared at infrastructure. The energy consumption of the infrastructure is dealt with at two levels:

  1. Reducing energy consumption in data centers. One example is OVH’s work on hydraulic cooling systems, replacing both the fans in the servers and the air conditioning in the data centres.
  2. The source of electric supply. An effort is being made by large groups such as Facebook, or Google to buy renewable electricity, i.e. electricity produced from renewable energy.

The second line of action to reduce the energy impact is usage limitation. From a user’s point of view, we have all seen awareness-raising campaigns recommending that people decrease their use of e-mail or even reduce the resolution of videos consumed to save bandwidth and electricity. This is an important step forward, but we must now go beyond it, to reduce the energy impact of everyday use.

Designing lightweight and efficient applications

Cloud computing has changed the way applications are designed. It’s an industry, with most of the major players now being business infrastructure providers. Cloud players offer increasingly sophisticated services and have simplified the use of online capabilities.

So much so that it is common today to design architecture that can scale-up automatically. It is even commonly accepted that human time is the most expensive and valuable resource. Consequently, it is better to put more and bigger servers to run one’s service than to spend time optimizing it. The environmental cost of time-to-market pressure is real. Cloud computing has made it too easy to leverage ever-increasing resources.

In this race to consume more and more, our industry has forgotten that this attitude is a major contributor to greenhouse gas emissions. This attitude is the IT equivalent of intensive agriculture. We need a new approach.

A third line of action: Measure and optimize

Another line of action to reduce the impact of the Internet on the planet is to rediscover optimization know-how, to be well aware of the impact of architecture decisions on our applications.

Many parameters have to be taken into account and can have a real impact on the environment:

  1. The type of architecture. Some architectures are more efficient than others. Intensive use of middleware and microservices can have a negative impact on the energy balance of a service.
  2. The panel of technologies. We have to be realistic, some technologies are convenient for development, but very energy consuming. For example, at ProcessOne, we have taken over the management of a messaging service on our infrastructure. The application was previously running on 30 servers. We now operate it on 4 servers of the same size. The choice of implementation technology makes a huge difference (i.e. Erlang, Elixir, Go).
  3. The set of features. Big data, the massive mining of data, is a great promise of wealth creation. However, the business case does not not always exist and storing and processing huge volumes of data just in case you may need it doesn’t seem rational. You have to think ahead about what you want to analyze and why. This approach is not really compatible with the General Data Protection Regulations (GDPR).

Conclusion

At the end of the day, companies have an important responsibility in the energy consumption of the Internet. They cannot be done with it by just shifting the burden to infrastructure providers and users. They have to take their share of the responsibility.

If you want to know how to address the problem, ProcessOne can certainly help you, by working on the whole process, and by helping you benchmark your application to monitor its performance.

So, are you ready to tackle the challenge with me and reducing the energy footprint of your applications?

by Mickaël Rémond at January 10, 2020 14:27

January 09, 2020

ProcessOne

go-xmpp 0.3.0

A new version of the go-xmpp library, which can be used to write XMPP clients or components in Go, as been released. It’s available on GitHub.

Upon new features, it adds a websocket transport. For this reason, the minimum go version to use it is now 1.13. It also adds a SendIQ method, to send iq stanza and receive the response asynchronously on a channel.
On the component side, it fixes a SIGSEGV in xmpp_component (#126) and adds more tests for the Component code.

A small example

Writing an XMPP component

Speaking of components, here is a simple example on how to create a simple one. As a reminder, components are external services that can communicate with an XMPP service using the Jabber Component Protocol as described in XEP-0114.

A component has its own XMPP domain and must know the server address and service port:

     const (
        domain  = "mycomponent.localhost"
        address = "localhost:8888"
    )

The options needed when creating a new component are defined as follow (secret must match the one define in the server config):

    opts := xmpp.ComponentOptions{
        TransportConfiguration: xmpp.TransportConfiguration{
            Address: address,
            Domain:  domain,
        },
        Domain:   domain,
        Secret:   "secret",
    }

To actually create the simplest component, just create a default route, and pass it to NewComponent, as well as the above options:

    router := xmpp.NewRouter()
    c, err := xmpp.NewComponent(opts, router)

Connect establishes the XMPP connection to the server, and authenticates with it:

      err := c.Connect()

Now we can try to send a disco iq to the server:

       iqReq := stanza.NewIQ(stanza.Attrs{Type: stanza.IQTypeGet,
        From: domain,
        To:   "localhost",
        Id:   "my-iq1"})
    disco := iqReq.DiscoInfo()
    iqReq.Payload = disco

In order to get the response asynchronously, the sendIq will return a channel where we expect to receive the result iq. We also need to pass it a context to set a timeout:

    ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
    res, _ := c.SendIQ(ctx, iqReq)

Now we just have to wait for our response:

    select {
    case iqResponse := <-res:
        // Got response from server
        fmt.Print(iqResponse.Payload)
    case <-time.After(100 * time.Millisecond):
        cancel()
        panic("No iq response was received in time")
    }

Full example

The full program that runs a component, connects it to a XMMP server and perform a disco on it to display the result is thus as is:

package main

import (
    "context"
    "fmt"
    "time"

    xmpp "github.com/FluuxIO/go-xmpp"
    "gosrc.io/xmpp/stanza"
)

const (
    domain  = "mycomponent.localhost"
    address = "build.vpn.p1:8888"
)

// Init and return a component
func makeComponent() *xmpp.Component {
    const (
        domain  = "mycomponent.localhost"
        address = "build.vpn.p1:8888"
    )
    opts := xmpp.ComponentOptions{
        TransportConfiguration: xmpp.TransportConfiguration{
            Address: address,
            Domain:  domain,
        },
        Domain: domain,
        Secret: "secret",
    }
    router := xmpp.NewRouter()
    c, err := xmpp.NewComponent(opts, router)
    if err != nil {
        panic(err)
    }
    return c
}

func main() {
    c := makeComponent()

    // Connect Component to the server
    fmt.Printf("Connecting to %v\n", address)
    err := c.Connect()
    if err != nil {
        panic(err)
    }

    // make a disco iq
    iqReq := stanza.NewIQ(stanza.Attrs{Type: stanza.IQTypeGet,
        From: domain,
        To:   "localhost",
        Id:   "my-iq1"})
    disco := iqReq.DiscoInfo()
    iqReq.Payload = disco

    // res is the channel used to receive the result iq
    ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
    res, _ := c.SendIQ(ctx, iqReq)

    select {
    case iqResponse := <-res:
        // Got response from server
        fmt.Print(iqResponse.Payload)
    case <-time.After(100 * time.Millisecond):
        cancel()
        panic("No iq response was received in time")
    }
}

by Jérôme Sautret at January 09, 2020 12:45

January 08, 2020

Kaidan

Kaidan for the Masses: Our Upcoming 9-seconds-registration

What’s XMPP’s biggest problem? - Accessibility!

Sure, it is accessible for the people who are really interested in XMPP or want to be more secure, but the normal user doesn’t want to study XMPP before they know what to do.

That’s why we work on an easy-to-use registration, which makes all decisions for a new user, but still ensures the highest possible security and decentralization. This means that even the password is randomly generated (it is changeable later on). In the end it only takes a few clicks to get to your new account, which is hosted by an automatically chosen public server which supports all of Kaidan’s features.

The user may choose to use the suggested server, username and password or to use own values. So, now switching from your old messenger to Kaidan (or other XMPP-based clients) is much easier. Therefore, you can invite your friends to XMPP and instantly start chatting with them.

Our aim is to make XMPP more accessible for everyone.

This is our first step towards that goal.

So, here is a quick look at the new registration that will come in Kaidan 0.5.0:

At first, you’re asked whether you already own an account or want to create a new one. If you have an own account, you can log in manually or by scanning a QR code which contains your credentials. After that, the user is asked whether the (automatic) “9-seconds-registration” should be used or the manual registration.

If you choose the automatic registration, in most cases you only need to solve a CAPTCHA and you’re done.

If you choose the manual registration, you can enter a display name and choose a server which is also randomly pre-selected. If it is possible, the server is selected depending on your system’s country settings. In the next step, Kaidan generates a username for you by alternating vowels and consonants but you are free to choose an own one.

The next step is choosing a password. If you don’t enter a password yourself, Kaidan will generate a secure one for you. It is changeable at any time. Depending on the server, the last step might be to enter further information or to solve a CAPTCHA. And then you can start chatting! If you only want to chat like with the dominating chat services and don’t care about the server, username or password, your choice is the automatic registration. It takes only nine seconds to start chatting. If you want to choose an own server, username or password like you can do with most XMPP clients, the manual registration is for you. No matter which way you choose, you will be ready for chatting without any hassle.

The registration is fast and simple, perfect for new users!

If an account is not used anymore, it can be deleted from the client and server too.

The presented features are not part of Kaidan yet, but will come with the new Kaidan 0.5.0.

All choices are depicted by cool cliparts, making it clearer what happens when you press any button. Special thanks to MBB, who made those cliparts.

January 08, 2020 18:00

Kaidan for the Masses: Our Upcoming 9-seconds-registration

What’s XMPP’s biggest problem? - Accessibility!

Sure, it is accessible for the people who are really interested in XMPP or want to be more secure, but the normal user doesn’t want to study XMPP before they know what to do.

That’s why we work on an easy-to-use registration, which makes all decisions for a new user, but still ensures the highest possible security and decentralization. This means that even the password is randomly generated (it is changeable later on). In the end it only takes a few clicks to get to your new account, which is hosted by an automatically chosen public server which supports all of Kaidan’s features.

The user may choose to use the suggested server, username and password or to use own values. So, now switching from your old messenger to Kaidan (or other XMPP-based clients) is much easier. Therefore, you can invite your friends to XMPP and instantly start chatting with them.

Our aim is to make XMPP more accessible for everyone.

This is our first step towards that goal.

So, here is a quick look at the new registration that will come in Kaidan 0.5.0:

At first, you’re asked whether you already own an account or want to create a new one. If you have an own account, you can login manually or by scanning a QR code which contains your credentials. After that, the user is asked whether the (automatic) “9-seconds-registration” should be used or the manual registration.

If you choose the automatic registration, in most cases you only need to solve a CAPTCHA and you’re done.

If you choose the manual registration, you can enter a display name and choose a server which is also randomly pre-selected. If it is possible, the server is selected depending on your system’s country settings. In the next step, Kaidan generates a username for you by alternating vowels and consonants but you are free to choose an own one.

The next step is choosing a password. If you don’t enter a password yourself, Kaidan will generate a secure one for you. It is changeable at any time. Depending on the server, the last step might be to enter further information or to solve a CAPTCHA. And then you can start chatting! If you only want to chat like with the dominating chat services and don’t care about the server, username or password, your choice is the automatic registration. It takes only nine seconds to start chatting. If you want to choose an own server, username or password like you can do with most XMPP clients, the manual registration is for you. No matter which way you choose, you will be ready for chatting without any hassle.

The registration is fast and simple, perfect for new users!

If an account is not used anymore, it can be deleted from the client and server too.

The presented features are not part of Kaidan yet, but will come with the new Kaidan 0.5.0.

All choices are depicted by cool cliparts, making it clearer what happens when you press any button. Special thanks to MBB, who made those cliparts.

January 08, 2020 18:00

Monal IM

OMEMO is broken in general across the ecosystem :(

I along with a lot of other people have tried to test OMEMO and we’ve all spent some time trying to figure out what is going on with OMEMO on multiple clients and compatibility. I think I know at least one reason why clients on different platforms can’t talk to each other. If you look at my earlier blog post I mentioned fixing an issue with the wrong size initialization vector in my AES-GCM code. I was using 16 instead of the standard 12 bytes. I used conversations to test compatibility and this is an issue/bug in conversations. Conversations can read 16 or 12 but sends the incorrect 16. This is apparently because Chatsecure had/has a bug where it is using 16. This results in the following issues:

  1. If someone is implementing OMEMO and doesn’t know to replicate this bug, it will not work. It is not documented or written down anywhere.
  2. If you are using a library that provides GCM and does not use the 16 byte iv. For example, Apple’s CryptoKit in ios13. OMEMO will not work with conversations or chat secure.

At the moment Monal for iOS and Mac will be updated to make 12 byte ivs. It will still be able to receive 16 byte ivs. This means monal will be able to send/receive to Conversations. It may not be able to communicate with chat secure or other clients that have replicated the bug depending on how it was implemented. Monal for catalyst uses apple’s Cryptokit and will be able to send to conversations but not receive. I have also observed that Beagle sends 16 byte but will accept 12 bytes like Conversations.

In a nutshell, if you are testing OMEMO compatibility across the ecosystem with different clients and platforms, don’t do it. It’s a waste of time until this is resolved by every client.

by Anu at January 08, 2020 16:36

OMEMO fixes, catalyst and France

Some updates for OMEMO coming. First, I noticed a bug there I was using an initialization vector of 16 bytes instead of 12 bytes. While a lot of clients seems to tolerate this, the extra 4 bytes may explain some of the cases where Monal worked with some clients but not others. Since this is an encryption related bug I should clarify, I am not aware of any security issue with this it is just inefficient and not the suggested size. I am hoping this improves compatibility. Flapping bugs like this are really hard to diagnose and fix because unlike a lot of other things, it doesn’t always fail.

Second, I have OMEMO working with Apple’s native AES-GCM libraries. This removes the dependency on OpenSSL and I have OEMEO working in mac catalyst bulds as well now (try the latest build form the link on the side).

Finally, the pending removal of openssl will allow me to return to the French app store in the future.

by Anu at January 08, 2020 04:57

January 07, 2020

Gajim

Development News December 2019

This is the third post of a news series about Gajim’s development. In these posts I (wurstsalat) will try to summarize a month of development around Gajim. Sometimes these posts will also cover python-nbxmpp and XMPP in general. December’s development brought improvements to HTTP file transfers, contact list tooltips, and more. Feel free to join gajim@conference.gajim.org to discuss with us.

January 07, 2020 00:00

January 06, 2020

Jérôme Poisson

SàT progress note 2020-W01

Hello and Happy New Year, this is the first progress note of the year.

Last weeks have seen work on OMEMO, and SàT has now a full OMEMO implementation (one2one, files with aesgcm scheme, and MUC encryption). One2one e2e OMEMO encryption was already available since 0.7, and I've talked about file encryption last time. The work on MUC has been quite straightforward, it was basically about handling the workflow differently (checking that we have a room JID and not a user JID, checking that we can retrieve real JIDs from Room, and retrieving room occupant JIDs). On Cagou, I've added the encryption button, and I've had to filter encryption algorithms available for MUC (where OTR is excluded, while it's available for one2one chat).

Once trying on Android, I've realised that OMEMO was not working as expected. After investigation I've found the issues (bad version and the Protobuf Python binding was not installed correctly), and I've proposed 2 small fixes to python-for-android's omemo and protobuff_cpp recipes, which are now merged upstream.

Once that working, I've decided to work a bit on Cagou usability. On Android, there is now a notification sound in addition to the vibration (you can activate/deactivate them in settings).

I've refactored the way platform specific behaviours are handled, and this is used, among other things, to manage URIs opening. Thanks to that, I can now handle the geo: URI scheme in a platform specific way: while by default it's opened in browser, on Android it's opening the application picking menu, so you can display the location in your map/navigation application.
That's pretty neat as you can now, using a map/navigation application + Android data sharing mechanism, send or get a location with SàT (and this may be end to end encrypted).

Continuing with Cagou UX improvements, I've added a small red "plug" icon when the user is not connected to the server. I was not sure how I can show that a user is disconnected without surcharging the interface, and I've found this solution acceptable (the icon is visible only when you're disconnected).

Now I'm working on chat room selection, i.e. how to open a chat room in Cagou.

by goffi at January 06, 2020 18:32

January 05, 2020

Monal IM

Catalyst and iOS 4.2.2

There is a new catalyst build up and 4.2.2 for iOS should be on TestFlight in a day or so.

by Anu at January 05, 2020 19:38

January 04, 2020

Monal IM

Monal iOS 4.2.1 released

Including many other fixes this has a fix for The http upload issues people saw as well as further improvements to muc

by Anu at January 04, 2020 13:40

January 03, 2020

Monal IM

iOS 10 and 11

I dropped iOS 9 support in the latest updates. Looking at the actual usage stats there are actually only 5 users using iOS 9,10,11 combined. Given all iOS 11 devices run iOS 12, and almost all iOS 10 devices ran 11, this makes sense. I am looking at only supporting iOS 12 and 13 in the next release. The primary benefit of this is it reduces the amount of testing needed as well as simplifies the code immensely resulting in fewer bugs and faster testing.

A lot of perfectly usable devices has support dropped by ios13 and iOS 12 updates still happen so those will likely stay around for a while (like iOS 9 did )

by Anu at January 03, 2020 14:10

Catalyst UI fixes

Another new catalyst build is up. There is a UI element to adjust the background now. I am also increasing/ adjusting some fonts for readability.

by Anu at January 03, 2020 12:13

January 02, 2020

Monal IM

iOS, Mac and Catalyst builds

Happy new year. We have three new builds with the latest fixes. New iOs build on TestFlight, a new Mac Catalyst build and a new Mac build. Catalyst doesnt have OMEMO yet but will soon. If you use Catalina please try the catalyst build and let me know how it is. Other than being more fuctional due to its origins in the iPad app, the catalyst build uses the hardened runtime and is notarized.

by Anu at January 02, 2020 18:28

Ignite Realtime Blog

Hazelcast Openfire plugin 2.5.0 released

@gdt wrote:

In anticipation of the forthcoming Openfire version 4.5.0, the Ignite Realtime community is happy to announce the immediate release of version 2.5.0 of the Hazelcast plugin for Openfire!

The Hazelcast plugin adds support for running multiple redundant Openfire servers together in a cluster.

This update is necessary to maintain compatibility with Openfire 4.5.0, and also provides several bug fixes and improvements.

NOTE: Openfire 4.5.0 (including the current beta or a recent SNAPSHOT) is required for this plugin to work. Do not attempt to upgrade to this version of the plugin unless you are running Openfire 4.5.0.

If you are running Openfire 4.5.0, your instance of Openfire should automatically display the availability of the update in the next few hours. Alternatively, you can download the new release of the plugin at the Hazelcast plugin archive page .

For other release announcements and news follow us on Twitter .

Posts: 1

Participants: 1

Read full topic

by @gdt Greg Thomas at January 02, 2020 18:00

January 01, 2020

Peter Saint-Andre

Jo Walton's Thessaly Trilogy

Fresh from a re-reading of Plato's dialogues, recently I dove into Jo Walton's Thessaly trilogy (The Just City, The Philosopher Kings, and Necessity), a speculative epic set in a society consistent with Plato's Republic. It's an enjoyable, thought-provoking blend of science fiction, ancient Greek myth, and Platonic philosophy. Although I recommended Walton's trilogy if you like philosophical novels, I do take issue with several aspects of her story....

January 01, 2020 00:00

December 31, 2019

Peter Saint-Andre

2019 Readings

Here are the ~110 books I had a chance to read in 2019, divided into a few categories. Most of these are related to my project of writing an epitome of Aristotle's ethics (and most of the rest are related to my project of writing a novel about Pyrrho, the founder of ancient Greek skepticism)....

December 31, 2019 00:00

December 30, 2019

Alexander Gnauck

Simpler code in handlers using pattern matching

The pattern matching feature which came with c# 7 can be very useful when writing XMPP stanza handlers with MatriX.

The MatriX vNext handlers are using predicates to filter and match stanzas. Sometimes the predicates can get very complex and would require a lot of type casts without pattern matching. So pattern matching makes you code much more readable, but also faster at runtime because we can save some casts of objects.

Here is a small code snippet of a stanza handler which is responsible for XMPP roster pushes.

Code without pattern matching

public class RosterHandler : XmppStanzaHandler
{
    public RosterHandler()
    {
        // handle roster pushed
        Handle(
            el =>
                el.OfType<Iq>()
                && el.Cast<Iq>().Query.OfType<Roster>()
                && (el.Cast<Iq>().Type == IqType.Result || el.Cast<Iq>().Type == IqType.Set),

            async (context, xmppXElement) =>
            {
                // do something with the stanza
            });
    }
}

Code with pattern matching

The sample below used also the **IsAnyOf** extension method which was added to MatriX recently
// With pattern matching
public class RosterHandler : XmppStanzaHandler
{
    public RosterHandler()
    {
        // handle roster pushes
        Handle(
            el =>
                el is Iq iq                
                && iq.Query is Roster
                && iq.Type.IsAnyOf(IqType.Result, IqType.Set),
            async (context, xmppXElement) =>
            {
                // do something with the stanza
            });
    }
}
of course you can use XPath or other technologies fore more complex stanza filtering in MatriX. I personally just prefer predicates becuase they are strongly typed and also fast.

by gnauck at December 30, 2019 17:43

December 29, 2019

Paul Schaub

Re: The Ecosystem is Moving

Moxie Marlinspike, the creator of Signal gave a talk at 36C3 on Saturday titled “The ecosystem is moving”.

The Fahrplan description of that talk reads as follows:

Considerations for distributed and decentralized technologies from the perspective of a product that many would like to see decentralize.

Amongst an environment of enthusiasm for blockchain-based technologies, efforts to decentralize the internet, and tremendous investment in distributed systems, there has been relatively little product movement in this area from the mobile and consumer internet spaces.

This is an exploration of challenges for distributed technologies, as well as some considerations for what they do and don’t provide, from the perspective of someone working on user-focused mobile communication. This also includes a look at how Signal addresses some of the same problems that decentralized and distributed technologies hope to solve.

https://fahrplan.events.ccc.de/congress/2019/Fahrplan/events/11086.html

Basically the talk is a reiteration of some arguments from a blog post with the same title he posted back in 2016.

In his presentation, Marlinspike basically states that federated systems have the issue of being frozen in time while centralized systems are flexible and easy to change.

As an example, Marlinspike names HTTP/1.1, which was released in 1999 and on which we are stuck on ever since. While it is true that a huge part of the internet is currently running on HTTP 1.0 and 1.1, one has to consider that its successor HTTP/2.0 was only released in 2015. 4 / 5 years are not a long time to update the entirety of the internet, especially if you consider the fact that the big browser vendors announced to only make their browsers work with HTTP/2.0 sites when they are TLS encrypted.

Marlinspike then goes on listing 4 expectations that advocates of federated systems have, namely privacy, censorship resistance, availability and control. This is pretty accurate and matches my personal expectations pretty well. He then argues, that Signal as a centralized application can fulfill those expectations as well, if not better than a decentralized system.

Privacy

Privacy is often expected to be provided by the means of data ownership, says Marlinspike. As an example he mentions email. He argues that even though he is self-hosting his emails, “each and every mail has GMail at the other end”.

I agree with this observation and think that this is a real problem. But the answer to this problem would logically be that we need to increase our efforts to change that by reducing the number of GMail accounts and increasing the number of self-hosted email servers, right? This is not really an argument for centralization, where each and every message is guaranteed to have the same service at the other end.

I also agree with his opinion that a more effective tool to gain privacy is good encryption. He obviously brings the point that email encryption is unusable, (hinting to PGP probably), totally ignoring modern approaches to email encryption like autocrypt.

Censorship resistance

Federated systems are censorship resistant. At least that is the expectation that advocates of federated systems have. Every time a server gets blocked, the user just simply switches to another server. The issue that Marlinspike points out is, that every time this happens, the user loses his entire social graph. While this is an issue, there are solutions to this problem, one being nomadic identities. If some server goes down the user simply migrates to another server, taking his contacts with him. Hubzilla does this for example. There are also import/export features present in most services nowadays thanks to the GDPR. XMPP offers such a solution using XEP-0277.

But lets take a look at how Signal circumvents censorship according to Marlinspike. He proudly presents Domain Fronting as the solution. With domain fronting, the client connects to some big service which is costly to block for a censor and uses that as a proxy to connect to the actual server. While this appears to be a very elegant solution, Marlinspike conceals the fact that Google and Amazon pretty quickly intervened and stopped Signal from using their domains.

With Google Cloud and AWS out of the picture, it seems that domain fronting as a censorship circumvention technique is now largely non-viable in the countries where Signal had enabled this feature.

https://signal.org/blog/looking-back-on-the-front/

Notice that above quote was posted by Marlinspike himself more than one and a half years ago. Why exactly he brings this as an argument remains a mystery to me.

Update: Apparently Signal still successfully uses Domain Fronting, just with content delivery networks other than Google and Amazon.

And even if domain fronting was an effective way to circumvent censorship, it could also be applied to federated servers as well, adding an additional layer of protection instead of solely relying on it.

But what if the censor is not a foreign nation, but instead the nation where your servers are located? What if the US decides to shutdown signal.org for some reason? No amount of domain fronting can protect you from police raiding your server center. Police confiscating each and every server of a federated system (or even a considerable fraction of it) on the other hand is unlikely.

Availability

This brings us nicely to the next point on the agenda, availability.

If you have a centralized service than you want to move that centralized service into two different data centers. And the way you did that was by splitting the data up between those data centers and you just halved your availability, because the mean time between failures goes up since you have two different data centers which means that it is more likely to have an outage in one of those data centers in any given moment.

Moxie Marlinspike in his 36c3 talk “The Ecosystem is Moving”

For some reason Marlinspike confuses a decentralized system with a centralized, but distributed system. It even reads “Centralized Service” on his slides… Decentralization does not equal distribution.

A federated system would obviously not be fault free, as servers naturally tend to go down, but an outage only causes a small fraction of the network to collapse, contrary to a total outage of centralized systems. There even are techniques to minimize the loss of functionality further, for example distributed chat rooms in the matrix protocol.

Control

The advocates argument of control says that if a service provider behaves undesirably, you simply switch to another service provider. Marlinspike rightfully asks the question how it then can be that many people still use Yahoo as their mail provider. Indeed that is a good question. I guess the only answer I can come up with is that most people probably don’t care enough about their email to make the switch. To be honest, email is kind of boring anyways 😉

XMPP

Next Marlinspike talks about XMPP. He (rightfully) notes that due to XMPPs extensibility there is a morass of XEPs and that those don’t really feel consistent.

The XMPP community already recognized the problem that comes with having that many XEPs and tries to solve this issue by introducing so called compliance suites. These are annually published documents that contain a list of XEPs that are considered vitally important for clients or servers. These suites act as maps that point a way through the XEP jungle.

Next Marlinspike states that the XMPP protocol still fails to be a suitable option for mobile devices. This statement is plain wrong and was already debunked in a blog post by Daniel Gultsch back in 2016. Gultsch develops an XMPP client for Android which is totally usable and generally has lower battery consumption than Signal has. Conversations implements all of the XEPs listed in the compliance suites to be required for mobile clients. This shows that implementing a decent mobile client for a federated system can be done and there is a recipe for it.

What Marlinspike could have pointed out instead is that the XMPP community struggles to come up with a decent iOS client. That would have been a fair argument, but spreading FUD about the XMPP protocol as a whole is unfair and dishonest.

Luckily the audience of the talk didn’t fully buy into Marlinspikes weaker arguments as demonstrated by some entertaining questions during the QA afterwards.

What Marlinspike is right about though is that developing a federated system is harder than doing a centralized service. You as the developer have control over the whole system and subsequently over the users. However this is actually the reason why we, the community of decentralized systems and federated protocols do what we do. In the words of J.F. Kennedy, we do these things…

…not because they are easy, but because they are hard…

… or simply because they are right.

by vanitasvitae at December 29, 2019 21:07